Signup protection works best as a sequence, not a single verdict: use CAPTCHA before account creation when the request already looks automated, then apply risk scoring after signals from the attempted signup are available. That placement preserves a clean audit trail and keeps a suspicious attempt from becoming a durable credential. The decision is about bot resistance, not about making every honest person solve a puzzle. Architecture decision record The invariants are straightforward. No account is created before the pre-creation gate passes; every challenge and score is recorded with a correlation ID; retries are idempotent; and a later decision can revoke a session without rewriting history. A score is evidence, not proof. A CAPTCHA is a friction boundary, not an identity check. The failure boundary matters more than the vendor choice. If a bot can create thousands of identities and only gets scored afterward, cleanup becomes a ledger problem: you have to distinguish a real user from an automated account after side effects have happened. If every visitor receives a challenge, conversion suffers and accessibility suffers with it. That boundary is the point. Placement Useful signal Main failure mode Appropriate response Before creation IP reputation, velocity, device hints, challenge result A false positive blocks a legitimate signup Challenge, slow down, or offer an accessible alternate path During creation Verified email or phone, password policy, uniqueness checks Partial records become difficult to reconcile Make the operation idempotent and keep a pending state After signals arrive Session behavior, token reuse, complaint or abuse events A bad account already exists Revoke sessions, rate-limit, and preserve the event history This is an architecture choice with a narrow rule: block before creation when the evidence is cheap and strongly associated with automation; score after creation when the evidence requires behavior that does not exist yet. Should signup CAPTCHA happen before creation, or after risk signals arrive? Before creation is the safer default for a registration request that trips a known abuse threshold. The threshold should be explainable: repeated attempts in a short window, a failed challenge, or a source with a high abuse history. Do not turn a model score into an irreversible deny without an appeal or a second signal. After the request has produced signals, risk scoring can decide what to do with an already-created session: keep it active, require reauthentication, limit sensitive actions, or revoke its refresh token. This is where a behavioral signal is useful. It is too late to prevent the initial row, but it can contain the blast radius. I model those transitions explicitly because an ambiguous boolean is hard to reconcile. The code below returns a decision and a reason that can be stored beside the registration event; a repeated request with the same idempotency key returns the same decision rather than creating another account. package signup type Decision string const ( Allow Decision = "allow" Challenge Decision = "challenge" Deny Decision = "deny" Review Decision = "review" ) type Signals struct { CaptchaPassed bool Velocity int AbuseHistory bool SessionRisk int } type Result struct { Decision Decision Reason string } func BeforeCreation(s Signals) Result { if s.AbuseHistory || s.Velocity > 20 { return Result{Decision: Challenge, Reason: "pre_creation_abuse_signal"} } if !s.CaptchaPassed { return Result{Decision: Challenge, Reason: "captcha_required"} } return Result{Decision: Allow, Reason: "pre_creation_checks_passed"} } func AfterSignals(s Signals) Result { switch { case s.SessionRisk >= 90: return Result{Decision: Deny, Reason: "session_revoke_required"} case s.SessionRisk >= 60: return Result{Decision: Review, Reason: "step_up_authentication"} default: return Result{Decision: Allow, Reason: "post_creation_risk_acceptable"} } } The values in this example are policy inputs, not universal cutoffs. I would keep them in versioned configuration, record the policy version with each event, and test boundary values such as 59, 60, and 90. A 429 response can slow a caller without pretending that rate limiting proves malicious intent; a 401 after revocation tells the client to discard the session. Small distinctions like that prevent operational dashboards from lying. What the rejected option teaches us The rejected design is “score everything after signup.” It has one attractive property: fewer interruptions on the registration form. It is unsuitable when account creation triggers email, trial allocation, API credentials, or any other side effect that an automated actor can multiply. The remediation queue then becomes the primary control, and queues are slower than prevention. The opposite extreme, “CAPTCHA every signup,” is also a poor fit for an accessible, low-abuse audience. Stick with a pre-creation challenge only for requests that meet a documented threshold; let low-risk traffic proceed, while preserving enough telemetry to rescore it later. I'm not sure any static threshold will survive a new attack pattern, so the policy needs review and rollback rather than silent tuning in production. Operating the boundary Audit records should answer who or what made the decision, which signals were present, which policy version ran, and whether a session was revoked later. Store a stable event identifier, not a copy of secrets. OWASP's Authentication Cheat Sheet also emphasizes generic authentication responses and careful account-recovery design; the same discipline applies here because a detailed rejection reason can become an enumeration oracle. Tests should cover retries, concurrent requests, expired challenge tokens, and a revoke that races with refresh. Add property tests for idempotency: submitting the same key twice must not create two identities, and replaying a revocation event must leave the final state unchanged. Observe challenge rate, allow rate, post-creation revocations, and appeal outcomes separately. A single “blocked” metric hides the trade-off. The audit path deserves more design than the challenge widget. For each attempt, I would persist the correlation ID, idempotency key, policy version, normalized signal names, decision, and decision timestamp in an append-only stream; the account service can then materialize a current status while the stream remains the authority for reconciliation. A retry that arrives after a timeout must read the prior result before it evaluates new signals, and a concurrent request must serialize on the idempotency key. When a later behavioral event changes a session from allowed to revoked, append a new event instead of mutating the original signup record. That makes a dispute explainable, lets an operator replay policy changes in a sandbox, and keeps a compliance reviewer from having to infer history from whatever state happens to be live. Secrets and raw challenge answers do not belong in that stream. The practical decision rule is modest: challenge before creation when current evidence points to automation; score after signals arrive when behavior is the evidence; and keep both decisions explainable, replayable, and reversible. That gives bot resistance without turning registration into a maze. References https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html https://www.rfc-editor.org/rfc/rfc9110 https://www.rfc-editor.org/rfc/rfc6749