Passkey Recovery Design: How to Avoid Locking Users Out

Passkeys remove a familiar authentication failure mode: a user enters a reusable password into a convincing imitation of a legitimate website. WebAuthn credentials instead use public-key cryptography bound to a relying party. The difficult question begins when a legitimate user loses access to every device and credential they normally use. A service that makes recovery too difficult locks out customers. A service that makes recovery trivial gives attackers a path around phishing-resistant sign-in.

A recovery policy is therefore part of the authentication system, not an unrelated customer-support feature. The correct design depends on account value, available identity evidence, user population, and the damage an unauthorized reset could cause. This article describes a layered model that keeps ordinary passkey sign-in convenient while giving both users and security teams predictable recovery behavior.

Understand which credential was actually lost

A passkey is a WebAuthn credential; the relying party stores a public key, while a private key is controlled by an authenticator or credential manager. Depending on its configuration, a credential can be tied to one authenticator or eligible to move through a synchronization system. The WebAuthn Level 3 specification distinguishes backup eligibility (BE) from current backup state (BS). These flags describe credential properties reported by an authenticator, not a guarantee that the user will be able to restore their account.

The same apparent lockout can have several causes:

• A physical security key is lost or destroyed.
• A phone is replaced, but its credential manager is unavailable or its sync account cannot be recovered.
• An employee leaves a managed-device fleet and no longer controls the authenticator.
• A user retains the passkey but cannot complete local biometric or device-unlock verification.
• A device is stolen while an attacker may still have an authenticated application session.
• The user cannot remember which passkey provider stores their credential.

These scenarios require different responses. Treating all of them as “forgot password” creates unsafe shortcuts. A lost device does not necessarily mean a lost credential: a synced credential may remain available on another trusted device. Conversely, a cloud backup feature should not be treated as proof of recoverability for any individual user.

Keep enrollment and recovery separate

A user who can still authenticate with an existing passkey should generally add a new passkey through an authenticated account-management flow. This is authenticator binding, rather than full account recovery. The distinction matters because adding a new credential after strong existing authentication offers better evidence of account control than accepting a single link sent to an email address.

The NIST Digital Identity Guidelines, SP 800-63B-4 distinguish authentication, authenticator binding, and account recovery. They describe recovery through saved codes, issued codes, prearranged contacts, and repeated identity proofing, together with relevant controls and assurance requirements. Their detailed requirements apply within the guideline's scope and should not be presented as universal legal obligations for every consumer website.

A useful recovery design makes an explicit policy decision at each boundary: whether the claimant still possesses an enrolled authenticator; whether a backup option was provisioned before the incident; and whether any alternative identity evidence justifies creating a replacement authenticator.

Prevention is easier than emergency recovery

The most effective recovery experience often starts during normal enrollment. After registration, show the user what credential they created, where it may be available, and how they can avoid depending on one device.

Encourage registration of more than one independent way to authenticate. For example, a user may keep a synced credential in a platform credential manager and a separate hardware security key. This is materially different from registering two passkeys that rely on the same compromised recovery account. Independence must be evaluated by failure domain, not by counting credentials in a database.

For workforce systems, consider separate organizational controls: managed hardware keys, documented replacement procedures, secure identity-proofing steps, and break-glass workflows that are audited. An IT administrator's ability to reset a credential is itself a privileged capability and should not bypass identity checks merely because an employee cannot sign in.

Present recovery setup when the user is already authenticated, explain the risks plainly, and allow periodic review. Avoid implying that everyone needs expensive hardware. A consumer service may prioritize a second synced device and protected recovery codes; a high-impact administration system may require stronger, independent credentials and supervised recovery.

Recovery codes: useful, but still bearer secrets

Saved recovery codes provide an escape route that does not depend on the same device as the passkey. They are also secrets: whoever obtains a valid code may be able to initiate account recovery. They should be high-entropy, single-use where appropriate, securely stored on the server, rate-limited during redemption, and revoked after use or replacement.

NIST's account recovery guidance addresses recovery codes and recovery-event notifications. The exact requirements depend on assurance level and recovery method. A service should therefore distinguish a recovery code that alone authorizes new-credential binding from one that provides only part of the necessary evidence.

An illustrative implementation can store only a keyed digest or other suitably protected verifier of each random recovery code, along with status and issuance metadata. On successful presentation, the server atomically marks it consumed and starts a limited recovery session. This is an architectural example, not a claim that a particular hashing scheme is mandated for all services.

Recovery codes should be downloadable or printable through a deliberately designed secure screen, not sent repeatedly through unsecured messaging channels. The user should understand that a screenshot kept beside the device being protected may disappear or be stolen with that device. The system must provide a way to regenerate and invalidate codes following strongly authenticated account access.

Email and SMS are not equivalent to passkeys

Many services already control an email address or mobile number, and those channels can help notify a user or provide one piece of evidence. They do not provide the same properties as phishing-resistant WebAuthn authentication. A message can be forwarded, intercepted, accessed through a compromised mailbox, or socially engineered away from the real subscriber.

NIST's phishing-resistance discussion explains why manually entered one-time outputs are not phishing-resistant. A product that permits any attacker holding a compromised email mailbox to enroll a new passkey has not eliminated account takeover; it has moved the critical boundary into mailbox recovery.

For low-risk consumer accounts, email-based recovery may be a deliberate usability decision. For privileged consoles, payment-administration tools, or accounts containing sensitive customer data, it may be an unacceptable sole factor. Record this as an explicit risk trade-off rather than advertising the entire account lifecycle as phishing-resistant.

Recovery notifications are different from recovery authorization. A notification may say that a recovery attempt started or that an authenticator was replaced, but merely receiving a notification must not be interpreted as proof that the recipient approved the action.

Design an explicit recovery state machine

Model recovery as a sequence of constrained states rather than a single endpoint that creates a credential whenever a token looks valid.

1. Initiated: the claimant identifies the account without learning whether the account exists from the public response.
2. Evidence pending: the service collects approved evidence while enforcing throttling, expiration, and replay protection.
3. Review or cooling-off: higher-risk cases may require a waiting period or a separately authorized human review.
4. Authorized to bind: the server grants a short-lived, one-purpose capability to register a new authenticator.
5. Completed: the new passkey is bound, recovery artifacts are consumed, audit events are written, and relevant sessions or credentials are reviewed.
6. Rejected or expired: the server closes the attempt without modifying authenticators.

The states should be durable and idempotent. A retry after a network timeout must not issue another recovery privilege or register the same replacement twice. Keep recovery transaction identifiers, strict expiration, actor identities, and explicit transitions in a server-side record. If an operation is uncertain, fail closed on enrollment and preserve enough audit context for safe retry.

A schematic transition might look like this:

initiated -> evidence_pending -> authorized_to_bind -> completed
                  |                    |
                  +-> expired/rejected <-+

This diagram is intentionally illustrative; specific products may require additional states for appeal, fraud review, or verification of a second independent channel.

Protect the moment a new passkey is bound

Registration is the point where a recovery process becomes persistent access. The user must still complete a real WebAuthn registration ceremony: the server issues a fresh challenge for the correct relying-party identity, validates the attestation and registration response according to its policy, and stores the resulting public-key credential against the intended account.

Recovery authorization must not be interchangeable with ordinary login access tokens. Bind it to the specific account, purpose, short validity window, and workflow state. Consume it atomically after a successful enrollment. Protect against cross-account confusion, stale browser sessions, multiple concurrent attempts, and token replay.

The WebAuthn specification defines core registration and authentication data structures and checks. It does not define a complete business process for proving that someone who lost every credential is the account owner. That business decision belongs to the service operating the account.

On successful binding, notify existing verified channels, show a comprehensible security activity record, and assess whether old authenticators or sessions should be disabled. Revoking everything automatically can be harmful when the request was legitimate but other devices remain useful. Conversely, leaving a stolen-device session active can undermine recovery. Choose revocation policy according to the threat scenario and account risk.

Customer support is part of the attack surface

When automated checks fail, a human support process can become the weakest authentication channel. Attackers may exploit urgency, convincing biographical facts, forged documents, or the pressure to resolve a locked-out customer quickly. The solution is not to assume every user is malicious; it is to avoid giving individual agents unreviewed authority to replace credentials.

For higher-risk systems, require documented identity-evidence criteria, privileged action logging, separation of duties when justified, escalation paths, and consistency checks against earlier recovery attempts. Train staff to recognize that a legitimate-looking email thread or caller ID is not equivalent to possession of an enrolled authenticator.

A support agent should initiate or approve a controlled workflow, not directly alter credential records in a production database. The system should record which evidence was reviewed, who approved the action, what authenticator changed, and how the user was notified. Limit the collection and retention of identity documents; excessive personal data creates a separate security and privacy risk.

Test legitimate lockouts and hostile recoveries

Recovery reliability is not measured by the passkey registration success rate alone. Test loss of a single device, loss of access to a sync provider, replacement of a managed phone, unreachable email, and the situation in which every prior authenticator is unavailable. Include accessibility requirements for people who cannot complete a particular biometric or manual process.

Then test adversarial behavior: repeated code guesses; reused links; concurrent recovery attempts; email account takeover; recovery initiated after a stolen authenticated session; staff impersonation; and attempts to enroll a credential on the wrong user record.

Useful internal measures include the share of users with an independent backup authenticator, recovery completion and abandonment rates, time spent in each workflow state, disputed credential additions, and confirmed malicious recoveries. These are evaluation dimensions, not universal target values. Track lockouts and account takeovers together: reducing one while silently increasing the other is not progress.

A careful rollout should exercise the new workflow against real support cases in a controlled environment, collect feedback on unclear instructions, and review incident reports before expanding access. Security testing should include the API state transitions and operator tools, not only the user-facing screens.

A practical policy by account risk

For an ordinary consumer account, a reasonable starting point is enrollment of additional passkeys, optional saved recovery codes, clear notification, and a documented recovery route when those options are unavailable. The remaining fallback may involve an email channel if the product consciously accepts that security limitation.

For a business application with sensitive information, require more independence between recovery factors and stronger scrutiny of high-impact operations. An account that can change billing details, export customer records, or manage users should not necessarily have the same reset policy as an account that only stores a reading list.

For highly privileged systems, prioritize independent authenticators, pre-enrolled recovery paths, audited approvals, and stronger identity evidence. In some environments, a full loss of every trusted authenticator should require supervised re-enrollment rather than an immediate remote reset.

These are risk-informed design patterns, not empirical rankings of recovery methods. The relevant decision is which evidence is available after the specific failure being recovered from, and whether an attacker could obtain that evidence more easily than the legitimate user.

Make recovery a first-class security control

A passkey rollout is incomplete until it specifies what happens after device loss, provider failure, account compromise, and inaccessible recovery channels. The architecture should make credential independence visible, provide safe routine enrollment while the user is authenticated, and reserve stronger checks for the exceptional act of replacing lost access.

The governing principle is straightforward: do not allow a weak recovery channel to silently defeat a strong everyday authentication mechanism. Design recovery as a controlled, observable authorization process, then test it as thoroughly as sign-in.