Passkey Account Recovery: Lost Passkeys and Safe Fallbacks

A passkey removes phishing from sign-in, but if the recovery path for a lost passkey is an SMS code, an emailed link or a help desk call, attackers simply go after recovery instead. Every passkey deployment eventually meets the lost phone, the broken security key, the new laptop and the user who says they are locked out. How those moments are handled decides whether the account is really phishing-resistant. This guide covers what happens when a passkey is lost, for synced and device-bound passkeys, the recovery methods NIST SP 800-63B-4 allows, how to design consumer and workforce recovery that does not reintroduce phishable fallbacks, and how to detect recovery abuse. It is written for identity architects, product security teams and service desk leads. Passkey basics and rollout planning are covered in the Passwordless and Passkeys Guide and the Passkey Rollout Guide; this page goes deeper on recovery.

Key takeaways

Recovery is part of the authenticator. An account is only as strong as the weakest way to add a new credential to it, so recovery methods must be designed and assessed with the same rigour as sign-in.
Synced passkeys move the problem to the sync account. Losing a device rarely loses a synced passkey, but whoever can recover the Apple, Google or password manager account can recover the passkeys too.
Multiple credentials beat clever recovery. NIST requires services to allow more than one authenticator per account. A second passkey or security key, registered early, avoids most recovery events altogether.
NIST gives four recovery methods. Saved recovery codes, issued recovery codes, recovery contacts and repeated identity proofing, with combinations required at AAL2 and a notification after every recovery.
Recovery must end in cleanup. Revoke the lost credential, review sessions, notify the user through an independent channel and watch the account for the following days.

What actually happens when a passkey is lost

The answer depends on where the passkey lives. A synced passkey is a copy of a key held in a provider's sync service; a device-bound passkey exists only in one authenticator, such as a hardware security key or a platform authenticator that does not sync. The relying party can see which kind it received: WebAuthn's Backup Eligible (BE) flag says whether a credential can be synced and the Backup State (BS) flag whether it has been. NIST's syncable authenticator appendix allows verifiers to use these flags, while advising agencies not to make acceptance conditional on BS for public-facing applications.

Scenario	Synced passkey	Device-bound passkey
Phone lost, other devices still signed in to the provider	No account recovery needed; passkeys still available on the other devices	Passkey on that device is gone; use another registered authenticator
All devices lost	Recover the provider account on a new device, then passkeys sync back	Gone; account recovery at the relying party is required unless a backup key exists
New phone at refresh	Sign in to the provider on the new phone	Register a new passkey on the new device using the old one, before wiping it
Security key broken	Not applicable	Use the backup key, then register a replacement
Provider account taken over	Attacker may gain every synced passkey	Not affected
User leaves organisation or device compromised	Revoke the credential at the relying party; the copy in the user's sync account cannot be wiped by you	Revoke at the relying party and recover or wipe the device

Provider recovery is outside your control. Apple says iCloud Keychain is end-to-end encrypted, that a new device joins either by being approved from an existing device or through iCloud Keychain recovery, and that escrow recovery requires the Apple Account password, a response to an SMS sent to the registered number and the device passcode, with ten attempts before the escrow record is destroyed. Google says passkeys in Google Password Manager are encrypted end to end and sync across Android devices and Chrome browsers signed into the same Google account, and that Android 14 and later also allow third-party providers. The strength of a synced passkey therefore includes the strength of that provider account's own recovery, which NIST reflects by requiring that access to keys in the sync fabric be protected by AAL2-equivalent MFA.

Recovery methods NIST SP 800-63B-4 recognises

SP 800-63B-4 section 4.2 lists four recovery methods and says a credential service provider shall support one or more of them. They are useful outside government too, because they are precise about what each method proves.

Method	NIST requirements (section 4.2.1)	Phishing exposure	Fits
Saved recovery code	At least 64 bits from an approved random bit generator; stored in the account hashed with an approved one-way function	A user can be tricked into reading it out or typing it into a fake site	Consumer accounts, especially those never identity-proofed
Issued recovery code	At least six decimal digits; validity limited by channel: 10 minutes by SMS or voice, 24 hours by email, 21 days by domestic post (30 abroad); at least two recovery addresses allowed	Exposed to SIM swap and mailbox takeover	A second factor in a recovery combination, not on its own
Recovery contact	Subscriber specifies one or more addresses; annual reminder to review contacts recommended	Depends on the contact's own security	Consumer and family accounts
Repeated identity proofing	Repeat the necessary proofing steps consistent with the original proofing level	Resistant if proofing is strong; exposed to deepfakes if weak	Workforce and regulated accounts that were proofed at onboarding

Section 4.2.2 then sets how methods combine. For an account that was never identity-proofed, recovery requires a saved recovery code. At AAL2, recovery requires two recovery codes obtained by different methods, or one recovery code plus authentication with a single-factor authenticator already bound to the account, or repeated identity proofing if the account was proofed. AAL3 accounts at IAL1 or IAL2 follow the AAL2 rules; at IAL3 a biometric comparison against the characteristic collected during proofing is required. Section 4.2.3 says recovery shall always cause a notification to the subscriber or their designee.

Two further rules matter for passkeys. Section 4.1.2.1 says services shall permit multiple authenticators per account, shall require authentication at the highest AAL currently available when adding one, and shall notify the user through a mechanism independent of the transaction. Section 4.3 says compromised authenticators shall be suspended, invalidated or destroyed. And NIST states that syncable authenticators shall not be used at AAL3, so AAL3 populations need device-bound credentials and therefore a planned way to replace them.

Designing consumer recovery

Consumer services cannot run a help desk check for every user, and most users will never print a recovery code. The design goal is to make recovery rare, then make it slow and noisy enough that an attacker gains little from it.

Encourage a second passkey: after the first passkey is created, prompt the user to add one from a different provider or a security key, and show which providers hold their passkeys on an account settings page. The FIDO Alliance's Passkey Central design guidelines treat a page to create, see and manage passkeys as a required pattern.
Let synced passkeys do most of the work: the majority of lost-device cases are solved by the user recovering their provider account. Explain that in your help pages rather than offering an account-level reset first.
Offer a saved recovery code at enrolment: generated with at least 64 bits, stored hashed, shown once, and replaced after use. See the MFA backup codes and recovery codes guide.
Combine methods for higher-value accounts: for example a saved code plus an issued code to a verified address, in line with the AAL2 combinations above, rather than any single channel.
Add friction after recovery: a waiting period before sensitive actions (changing payout details, exporting data, adding new credentials), a notification to every registered address, and a one-click "this was not me" path that freezes the account.
Do not silently fall back to a password plus SMS: if the account still has a password and SMS reset, an attacker will use that path. Retire it once enough users have a second passkey, or limit it to the post-recovery restricted mode above.

Designing workforce recovery

Workforce accounts carry more privilege and have a better recovery anchor: the organisation already knows who the person is. Passkey Central's workforce guide says recovery is consistently the sharpest pain point in deployments and deserves attention early, and that device-bound passkeys require re-enrolment on every new device.

Event	Weak pattern to retire	Stronger pattern
Lost or broken security key	Help desk resets to password plus SMS	Backup key issued at enrolment; or identity check, then a short-lived one-time bootstrap code to register a new key
Laptop or phone refresh	Temporary password emailed to the user	Register the new device's passkey from the old device or with a cross-device sign-in before the old one is wiped
Caller says they are locked out	Caller ID, manager's name, date of birth	Video identity check against the HR record or in person with ID; callback to a number on file
Privileged user locked out	Same desk, same process as everyone else	Second approver, separate queue, and a review of the account's recent activity before access is restored
Suspected compromise	Reset and carry on	Revoke all credentials and sessions, investigate, then re-enrol through the strongest path

Bootstrap codes: Microsoft Entra ID's Temporary Access Pass is an example of the bootstrap pattern. Microsoft describes it as a time-limited passcode for onboarding passwordless methods such as passkeys and for recovery when a user loses a strong method. Its documented defaults are a one-hour default lifetime, a maximum of eight hours (configurable from 10 minutes to 30 days) and an eight-character length, and one-time use is off by default. Turn one-time use on, keep lifetimes short, and note Microsoft's point that existing sessions are not invalidated when a pass expires. Who can issue it also matters: Microsoft limits issuance for administrators to the Privileged Authentication Administrator role.

The incidents in the NHIMG breach database show why the identity check matters more than the code. In the MGM Resorts Breach, attackers reportedly called the IT help desk posing as an employee they had found on LinkedIn, and in the Co-op Cyber Attack attackers reportedly impersonated an employee to have that employee's password reset. A passkey programme that leaves those desk procedures in place has moved the attack, not stopped it. See the Account Recovery and Help Desk Security Guide and the Deepfake-Resistant Identity Verification Guide.

Cleanup after a recovery

Revoke the lost credential: delete the passkey record at the relying party. NIST section 4.3 requires compromised authenticators to be invalidated. A lost device should be treated as potentially compromised.
Tell the passkey provider: the WebAuthn Signal API lets a relying party tell providers that a credential no longer exists (signalUnknownCredential) or which credentials are still valid (signalAllAcceptedCredentials), so stale passkeys stop appearing to the user. Chrome's developer documentation lists support from Chrome and Edge 132 and Safari 26, with Firefox not supporting it at the time of writing. Treat it as a usability aid, not a security control.
Review sessions and tokens: sign out other sessions and revoke refresh tokens where the recovery was not clearly benign.
Notify independently: send the recovery notification to all notification addresses (NIST requires support for at least two) rather than only to the address used in recovery.
Watch the account: new credential registrations, contact detail changes and payment or permission changes in the following days are the attacker's next steps.

Decision guidance: synced, device-bound and fallback choices

Consumer services: accept synced passkeys and let provider recovery handle most lost-device cases; add saved recovery codes and a combined-method recovery for the rest. Requiring device-bound passkeys would drive up recovery volumes without a matching gain for most users.
General workforce: synced passkeys in managed provider accounts, or device-bound platform passkeys on managed devices, with a bootstrap code issued after an identity check. NIST notes that enterprise device management can limit passkey sharing, which consumer contexts cannot.
Privileged and AAL3 users: device-bound security keys, at least two per person, registered at the same session. Recovery by in-person or video identity check with a second approver.
Small organisations: two security keys per administrator and a written procedure for the rare lost-key case are usually enough; the main risk is an informal reset by whoever answers the phone.
Large organisations: separate recovery queues by privilege, measure recovery volumes and outcomes, and sample recoveries for audit.

Detection and measurement

Signal	Why it matters
New passkey registered shortly after a recovery or help desk ticket	The usual sequence in recovery abuse
Recovery followed quickly by contact, payout or permission changes	Attacker consolidating access
Several recovery attempts against one account, or one source against many accounts	Targeted or scaled recovery attacks
Authenticator from an unexpected provider (AAGUID) on a privileged account	Credential registered outside the approved authenticator set
Bootstrap codes issued without a linked identity verification record	Desk procedure bypassed
User reports "this was not me" after a notification	Confirmed abuse: freeze and investigate

Metrics:

Coverage of backups: percentage of accounts with two or more passkeys or security keys.
Recovery rate: recoveries per 1,000 active users per month, which should fall as second credentials spread.
Phishable recovery share: percentage of recoveries completed through a single SMS or email channel (target falling to zero for workforce).
Verification evidence: percentage of workforce recoveries with a recorded identity check and, for privileged users, a second approver.
Post-recovery incidents: recoveries followed by a "not me" report or confirmed abuse.

Framework mapping

Framework	Reference	How it applies
NIST SP 800-63B-4	Sections 4.1.2.1, 4.2, 4.3, 4.6 and Appendix B	Binding additional authenticators, recovery methods and combinations, loss handling, notifications, syncable authenticators
NIST SP 800-53 Rev. 5	IA-5 Authenticator Management; IA-12 Identity Proofing; IA-2 Identification and Authentication	Replacing lost authenticators, re-proofing for recovery, phishing-resistant authentication
NIST CSF 2.0	PR.AA-01; PR.AA-03	Credential management and authentication of users
MITRE ATT&CK	T1556 Modify Authentication Process; T1098.005 Device Registration	Abuse of recovery to register attacker-controlled credentials or devices
CIS Controls v8.1	Control 6 Access Control Management	MFA and credential management processes
ISO/IEC 27001:2022 Annex A	A.5.17 Authentication information; A.8.5 Secure authentication	Issuing and replacing authentication information securely

Common failure patterns

Passkeys at the front door, SMS at the back: the account keeps a password and SMS reset "for recovery", so attackers use SIM swap or a phishing kit against the reset flow. See the SIM Swap Fraud Guide.
One passkey per account: no second credential means every lost device becomes an account recovery event, which overloads the desk and pushes it towards weak checks.
Help desk knowledge checks: verifying callers with details found on social media or in breached data, as the incidents above illustrate.
Bootstrap codes that live for days: long-lived or reusable codes sent by email turn into a password by another name.
No cleanup: the lost credential, old sessions and the attacker's newly added passkey all remain on the account after recovery.
Ignoring the sync account: privileged staff hold synced passkeys in personal provider accounts with weak recovery settings, so the organisation's strongest credential depends on a consumer account it cannot see.

Practitioner checklist

Map every path that can add a credential to an account, including help desk and legacy password resets.
Prompt for a second passkey or security key at enrolment and show registered passkeys on an account settings page.
Choose recovery methods from the four NIST recognises and combine them for AAL2 accounts.
Issue saved recovery codes with at least 64 bits, store them hashed and replace them after use.
For workforce, require an identity check against HR records before issuing a short-lived, one-time bootstrap code, with a second approver for privileged users.
Issue at least two device-bound security keys to privileged and AAL3 users.
After every recovery, revoke the lost credential, review sessions and notify all registered addresses.
Alert on new credential registrations soon after recovery and on bootstrap codes issued without verification records.
Retire SMS and email-only recovery for workforce accounts and restrict it for consumers.

Passkey account recovery: designing recovery without phishable fallbacks