The Hard Part of Passkeys Is Recovery, Not Cryptography

The cryptography in a passkey is finished work. WebAuthn's own issue tracker has known where the real problem lives since June 5, 2018 — issue #931, "Recovering from Device Loss," still open, deliberately left to relying parties. The handshake is solved. What happens when a user drops the only phone that ever held their passkey into a lake is not, and that is the part you are actually being asked to build.

Recovery is not password reset with new words

The instinct is to treat recovery as a rename of "forgot password." It isn't. A password reset proves identity through a channel — usually email — that you were about to declare insufficient by going passwordless in the first place. The moment your recovery path sends a magic link to an inbox protected by a password and an SMS code, your unphishable login is only as phishing-resistant as that inbox. A system is exactly as strong as its worst recovery path, and most passkey rollouts quietly ship a worst path that undoes the whole point.

That is the structural trap. Recovery has to prove you are you through some channel, and every easy channel is a downgrade. The engineering question is not "how do we let people back in" — it's "how do we let people back in without reopening the door we just welded shut."

How the platforms actually do it

Three shipping products, three genuinely different security models.

Apple leans on escrow and people. iCloud Keychain recovery combines your Apple Account, its password, an SMS code to a registered number, and the device passcode — escrowed so neither Apple nor any single party can unlock the data alone. On top of that, up to five Recovery Contacts can vouch for you, and a dedicated Recovery Key gives the security-conscious a self-custody option. The trust is distributed: across your own factors, and across people you chose.

Microsoft Entra treats recovery as identity proofing. Its Account Recovery — deliberately separate from self-service password reset — re-establishes trust through Microsoft Entra Verified ID and third-party verification providers, then issues a Temporary Access Pass to get the user back to enrolling a real credential. It ships with Evaluation and Production modes and a cost estimator against helpdesk-led recovery, which tells you who the buyer is: an enterprise counting the price of every reset call.

GitHub keeps it blunt. The fallback for lost 2FA or passkey access is sixteen single-use, ten-character recovery codes. SMS fallback was removed. The current guidance is to register two or more recovery methods rather than lean on one — an admission that any single fallback is a single point of failure.

Notice what none of them do: none falls back to a plain emailed link as the primary recovery path. That is the pattern to copy.

What FIDO actually tells you to build

FIDO's Passkey Central guidelines come out of annual UX research — a 128-person, 32-company working group that catalogued 270 distinct moments to introduce a passkey, then narrowed them to two required patterns plus optional and security-key patterns. The one worth internalizing: create a passkey right after account recovery.

The pattern is specific. Rename "Reset password" to "Confirm account." Verify identity. Then offer passkey creation as the primary option, with password as the fallback — and never force it. The reason it works is behavioral. Google's own guidance lists four enrollment moments — during sign-in, in security settings, after account recovery, and after reauthorization — and notes recovery is "never an easy process." A user who just fought their way back into a locked account is more motivated to set up something better than at any other moment. The pain is the conversion.

Portability is harm reduction, not recovery

FIDO's Credential Exchange work — CXF reached Review Draft on March 13, 2025, with CXP (built on Hybrid Public Key Encryption) targeting standardization in early-to-mid 2026 — is easy to misread as the recovery answer. It isn't. Built with Apple, Google, Microsoft, 1Password, Bitwarden, Dashlane, and NordPass, and already shipping as same-device transfer in iOS and macOS 26, it lets users move passkeys between managers instead of being locked to one vendor.

That matters, but for a narrower reason than it looks. It reduces how often a user hits a hard recovery path at all. It does nothing for the zero-devices-left case. If every device is gone, there is no manager to export from. Portability lowers the frequency of the disaster; it does not change what you do when the disaster happens. Design both.

A checklist for the relying party

• Enroll at four moments, not one: account creation, security settings, after recovery, and after reauth. The last two convert best.
• Require a backup credential before you let a user go passkey-only. One device is one lake away from a lockout.
• Do not let email or SMS be the strongest link in your recovery path. If it is, you have a passwordless front door and a password-grade back door.
• Support a security key as a recovery credential. CTAP 2.2's Persistent PIN/UV Auth Tokens, scoped to read-only credential enumeration, make a hardware key a clean answer for the user who lost every synced device.
• Log recovery-flow usage as a rate. A rising recovery rate is not a recovery problem — it's an enrollment or device-management problem surfacing downstream. Watch it like an error budget.

The number that pays for the design time

Passkeys log in at a 93% success rate against 63% for passwords, and in 8.5 seconds against 31.2. PayPal reports 70% lower account-takeover and more than 10% higher login success on passkeys. Those numbers are why you're rolling passkeys out. But they only hold for users who successfully enrolled and stayed enrolled — and enrollment lives or dies on the recovery moment. Widely repeated helpdesk figures put a password reset near $70 per call, with resets at 20–50% of tickets; treat those as unverified secondary marketing numbers, but the direction is not in doubt. A recovery path that dumps locked-out users onto support is where the savings leak back out.

Where adoption is actually won

Recovery is where passkey adoption gets won or lost at the margin. The handshake was solved years ago; the spec left the hard part — issue #931, still open — to you. FIDO's CEO now calls account recovery the next chapter of the passwordless journey, which is a polite way of saying it was skipped. Build the recovery path with the same seriousness you'd give the login, because a user only meets your login on a good day. They meet your recovery flow on the worst one.