Passkey Recovery: Review Every Route Back Into the Account

A passkey rollout needs two reviews: how users authenticate, and how someone can obtain the right to authenticate later. A fallback login or recovery flow can grant that right without using the existing passkey. New-credential enrollment is therefore part of the security boundary, not just a settings-screen feature.

FIDO Alliance published its latest Passkey Index on 15 October 2026. Adoption reporting is useful context, but it cannot establish that your recovery paths are safe. This guide gives application teams a route-by-route review worksheet rather than an adoption score. Index

What the passkey ceremony establishes

WebAuthn verification ties an assertion to an expected challenge, origin, RP ID, and registered credential. The server checks the signature and credential-to-account association, along with user presence, plus user verification when required. A successful fingerprint prompt alone is not the server’s verification result. These are parts of the W3C Level 3 verification procedure, not a complete implementation checklist. W3C §7.2

That proof does not answer a different question: was the person who enrolled this credential entitled to attach it to this account? W3C’s registration procedure stores the credential in the selected account after its checks succeed. The application must establish the authorized account context around that ceremony. W3C §7.1

OWASP accordingly recommends recent reauthentication for credential changes, server-side account binding, multiple authenticators, lifecycle notifications, and immediate server-side revocation. It also warns against silently downgrading a failed passkey attempt to weaker authentication. OWASP guidance

Separate two different recovery systems

Credential-provider recovery restores access to the environment that stores or synchronizes a passkey. Application-account recovery restores access to a particular service and may authorize enrollment of a replacement credential. They can interact, but they are not the same operation.

For synced credentials, examine the provider’s account protection, device enrollment, and recovery dependencies. For device-bound credentials, plan how the user will authenticate after losing the authenticator. NCSC’s April 2026 assessment emphasizes secure sync-account recovery, backups for single-device credentials, and device security. Its conclusions concern personal use; they are not an enterprise risk assessment. NCSC analysis

Two devices using the same synchronized credential can help with losing one device. They do not necessarily provide independent recovery if both depend on the same inaccessible provider account. That is a dependency question to verify, not a reason to reject synced passkeys.

Conceptual lifecycle map. Arrows show possible legitimate paths, not an attack demonstration or a claim that every provider works this way.

A hypothetical failure that does not break WebAuthn

Imagine a document service with these product rules:

1. Ordinary login supports passkeys.
2. A recovery email grants a session that can add a new passkey immediately.
3. The new passkey can then authorize document exports.

If an attacker controls that recovery mailbox and the service accepts mailbox access as sufficient recovery evidence, the attacker may enroll a credential they control. A later valid passkey assertion proves control of that newly enrolled credential. It does not repair the earlier ownership decision.

This is a fictional design example, not a finding about a named service. Its prerequisites matter: the mailbox must be compromised or the recovery evidence otherwise satisfied, and the application must grant the described privileges. Additional recovery checks could prevent the sequence.

Our design recommendation is to review the transition from recovery evidence to credential enrollment explicitly. Do not let a generic “logged in” flag erase how the session was established. Where risk warrants it, restrict sensitive actions pending further verification. OWASP recommends additional verification or delay after elevated-risk recovery, plus session rotation and credential review. A delay alone does not establish ownership. OWASP recovery guidance

Use a route worksheet, not a passkey checkbox

For each real route, fill in the following questions with the product’s actual behavior. The examples describe review work, not controls already verified on your service.

Route	Evidence to identify	Decision to record
Normal passkey login	Server verification policy and credential record	Which account and privileges does success establish?
Another login method	Every password, OTP, federation, or support route still available	Can it reach the same account without the passkey?
Credential-provider recovery	Provider policy and the user’s enrolled recovery dependencies	Does it restore the credential, or only provider-account access?
Application recovery	Evidence accepted when normal authenticators are unavailable	Can this session enroll a key or perform high-impact actions?
Adding a passkey	Recent authentication and server-selected account	What prevents a stale session from changing future access?
Removing a credential	Server revocation and remaining access options	Are existing sessions handled separately, and can the user still recover?

A useful review artifact is a small graph: routes on the left, privileges on the right. If two routes converge on the same privilege, compare their evidence requirements. Prioritize the path whose evidence is least appropriate for that privilege, even if few legitimate users take it. This is a qualitative review method, not a calculated compromise probability.

A recovery code can be useful without being phishing-resistant

FIDO’s deployment guidance classifies manually usable recovery codes and OTPs as phishable methods. It does not classify every alternative, such as email magic links, as phishing-resistant. Keeping a recovery option does not automatically make it equivalent to the passkey ceremony. FIDO guidance

NIST SP 800-63B-4 nevertheless recognizes recovery codes as part of account recovery. Section 4.2 distinguishes saved codes, issued codes, recovery contacts, and repeated identity proofing, with requirements dependent on the account’s assurance and identity-proofing context. For accounts that can authenticate at a maximum of AAL2, its alternatives include two recovery codes from different methods, one recovery code plus a bound single-factor authenticator, or repeated identity proofing where applicable. Recovery also requires notification. NIST §4.2

These documents answer different questions: whether a mechanism resists phishing, and how an account may be recovered under a particular assurance framework. Do not label a generic email-reset flow “NIST compliant” from this summary. Nor should a consumer application remove all recovery overnight without an availability plan.

Turn the review into acceptance criteria

Before changing a real deployment, specify expected outcomes for lost-device, unavailable-provider, stale-session, and unauthorized-enrollment cases. Use controlled test accounts and approved procedures. Record both denial of unauthorized changes and successful legitimate recovery; lockouts are a product failure too.

For operational reporting, separate passkey adoption, recovery completion, credential-enrollment events, and confirmed account compromises. A rising passkey-login share says nothing by itself about recovery correctness. Avoid gathering raw authentication responses or secrets merely to populate a dashboard.

The practical release question is: can we explain and verify every route that grants future account access? Keep the protocol checks, recovery evidence, enrollment permission, and resulting privileges visible as separate decisions.

For adjacent operational guidance, see what to remove before sharing a HAR file. Authentication troubleshooting can expose session material even when the login itself uses passkeys.