Passkey Recovery Codes vs Backup Authenticators

When a user loses the device holding their only passkey, the account’s real strength is whatever gets them back in. This page compares the two mechanisms that actually work — a second registered credential and a set of single-use recovery codes — and covers how to handle each so that neither becomes the weakest part of the account. It sits under Credential Revocation and Account Recovery.

Option Reference

Option Proves Phishable Fails when
second passkey on another device possession of a second credential no that device is not to hand
single-use recovery code possession of a stored secret yes, once the user cannot find them
identity verification who the person is no, but slow cost and jurisdiction limit it
email or SMS control of a mailbox or number yes the mailbox is compromised

The first two are the ones a product controls directly, and the ones this page is about.

Two answers to the same question A recovery code is a bearer secret you issue; a second passkey is a credential the user already controls. Prefer the second; keep the first for when it is impossible recovery codes issued by you, stored by the user a bearer secret — phishable once work from any device fail when the user cannot find them a second passkey created by the user on another device phishing-resistant, like the first needs that device to hand the stronger option when available Most accounts should end up with both, because they fail in different circumstances.

Root Cause Analysis

1. Offering neither. An account with one passkey and an email-based reset is an account whose real strength is the mailbox. That is a legitimate design choice for a low-value account and a poor one for anything else, but it should be a choice rather than an oversight.

2. Treating recovery codes as a password replacement. They are a bearer secret with all the properties that implies: guessable if short, phishable if the user can be persuaded to type one, and permanently valuable if not marked consumed.

3. Requiring the lost device to authorise its own replacement. Recovery that is gated behind the credential the user no longer has is not recovery.

4. Prompting for a second passkey at the wrong moment. The moment is immediately after a successful sign-in on a device that is not the one already enrolled, and specifically when the backup-eligibility bit says the existing credential is device-bound.

Handling rules for recovery codes A code is a password with a short life and a single use, and it needs the same handling. Five rules, all of them familiar from password handling hash them store a hash, never the code — display is a one-time event single use mark consumed atomically at redemption regenerable a full new set, invalidating the old one, from an authenticated session rate limited by account, because a code is guessable in a way a signature is not never re-displayed a code shown twice is a code in two screenshots

Step-by-Step Resolution

Step 1 — read the backup bits and prompt accordingly

A credential that reports backup-eligible and backed up is already resilient. One that does not is the account that genuinely needs a second credential, and that is where the prompt belongs.

Step 2 — make adding a second passkey a one-screen flow

From account settings and from the post-sign-in prompt, with copy that names the benefit: signing in if this device is lost.

Step 3 — issue recovery codes once, hashed

Generate a set, display them once, offer a download, store only hashes. Never display an issued code again.

Step 4 — consume atomically and rate-limit

Mark a code used in the same operation that validates it, and rate-limit redemption by account. A code is guessable in a way a signature is not.

Step 5 — vary the cooling-off period by factor

A recovery proved by a second passkey can clear quickly; one proved by a code deserves a longer window and a notification to every existing device.

Step 6 — regenerate on demand and after use

Let an authenticated user replace the whole set, invalidating what came before.

Where each option fits the flow Recovery starts by establishing which factor the user still has, then applies the delay appropriate to it. The factor decides the delay, not the other way round recovery starts which factor is available? second passkey possession proved directly recovery code a bearer secret redeemed cooling-off shorter for the stronger factor Varying the delay by factor strength is what lets a strong recovery be fast without making a weak one dangerous.

Verification and Testing

Test the redemption path for single use directly: redeem a code, then attempt the same code again and assert it fails. Then attempt two concurrent redemptions of one code and assert exactly one succeeds — the second test is the one that catches a read-then-update pair masquerading as an atomic operation.

Test the second-passkey path end to end with two virtual authenticators, asserting that the account can sign in with either and that revoking one leaves the other working.

Test the prompt logic against both backup states, asserting that a synced credential does not trigger a nag and a device-bound one does.

Pitfalls

1. Storing codes in plaintext “so support can read them”. That is a support process that can hand over an account.

2. Issuing too many codes. A set the user cannot keep track of ends up in a note file, which is where bearer secrets go to be found.

3. Treating a redeemed code as still valid until a cleanup job runs. Consumption must be immediate and atomic.

Frequently Asked Questions

How many recovery codes should be issued?

Enough that consuming one does not create anxiety and few enough that the set stays manageable — eight to ten is the common choice. What matters more than the number is that they are single-use, that the user is told they are single-use, and that regenerating the set is easy to find.

Should a recovery code be accepted as a second factor alongside a passkey?

No. It exists for the case where the passkey is unavailable, so requiring both means requiring the thing the user has lost. Keep them as alternatives, and make the code redeemable on its own subject to the delay and notification controls.

Is a second passkey always better than codes?

Better, but not always available. A user with one device and no security key cannot create a second credential that would survive losing it, and for them codes are the only mechanism that helps. The right posture is to offer both and to prefer the passkey when the user can create one.

What should happen to recovery codes when a passkey is added?

Nothing automatically. They remain valid until redeemed or regenerated. It is reasonable to point out, once a second passkey exists, that the codes are now a backup to a backup — but invalidating them silently removes a path the user may be relying on.

Do recovery codes need the same cooling-off period as an email reset?

Usually shorter, because a stored code is evidence of prior possession in a way that control of a mailbox is not. Sizing the delay by the strength of the factor is the whole point of measuring factor strength.

Should redemption end existing sessions?

Yes. A successful recovery means control of the account was in doubt, so every session and refresh token issued before it must end along with the credentials being replaced.

Where should recovery codes be presented in the product?

Immediately after a user enrols their first passkey, as part of the same flow rather than as a separate errand in account settings. That is the only moment when the connection between “I now sign in with this device” and “here is what happens if I lose it” is obvious, and conversion elsewhere is dramatically worse. Offer a download and a print option, say plainly that each code works once, and do not block the flow on the user confirming they have stored them — a forced confirmation trains people to click through without reading, which is worse than no confirmation at all.

It is also worth putting a single line in your help content explaining that the codes are the only path back if every registered device is lost, because support conversations about locked accounts almost always begin with a user who did not realise the codes mattered until the moment they did.

Related