Passkey Account Recovery and Fallback Strategies

A user replaces their phone, the passkey was never synced, and now the only authenticator for the account is gone — and the recovery path you bolt on in a hurry is usually a worse-than-passwords backdoor. This page is part of the passkeys and WebAuthn walkthrough, and it covers recovery done right: why losing a passkey is a recoverability problem, how multiple credentials solve most of it, and how to add fallbacks without throwing away the phishing resistance you adopted passkeys to get.

Root cause: the recovery path is the weakest factor

Phishing resistance comes from origin binding — a passkey can’t be exercised on a look-alike domain. But an account is only as strong as its easiest way in. Bolt an SMS OTP or a knowledge-based “security question” reset onto a passkey account and you have reintroduced exactly the phishable, social-engineerable factor you removed; an attacker simply ignores the passkey and attacks recovery. The discipline is to treat recovery as a first-class authentication path with its own threat model, held to a bar as close to the passkey’s as practical — not as an afterthought funneled through a support inbox.

flowchart TD
    A["User cannot present a passkey"]:::client --> B{Another credential\nenrolled?}
    B -- "Yes" --> C["Sign in with second passkey"]:::idp
    B -- "No" --> D{Recovery factor\navailable?}
    D -- "Magic link to verified email" --> E["Re-enroll new passkey"]:::idp
    D -- "TOTP or recovery code" --> E
    D -- "None / high risk" --> F["Manual review\nidentity proofing"]:::threat
    C --> G["Enroll an additional passkey"]:::store
    E --> G
    classDef client fill:#fff0ee,stroke:#c0392b,stroke-width:2px,color:#1a1614
    classDef idp    fill:#eef0ff,stroke:#2c3e8c,stroke-width:2px,color:#1a1614
    classDef store  fill:#fffbec,stroke:#d4840a,stroke-width:2px,color:#1a1614
    classDef threat fill:#fff0ee,stroke:#922b21,stroke-width:2px,color:#1a1614

Strategy 1: multiple credentials per account (the primary defense)

Most “lost passkey” incidents never need a fallback if the account holds more than one credential. Each device a user enrolls produces an independent credential ID and public key under the same userID, so losing one device leaves a working passkey on another. This is built into the registration ceremony — you simply prompt for it.

// After a successful login, nudge users who have only one credential.
const creds = await db.getCredentialsForUser(userId);
const singleDeviceOnly = creds.length === 1 && !creds[0].backedUp;
if (singleDeviceOnly) {
  // backedUp === false means a non-synced, single-device passkey:
  // losing that device loses the account. Strongly prompt a second one.
  res.locals.prompts.push("add_backup_passkey");
}

The backedUp flag you stored at registration tells you which accounts are fragile: a synced passkey (backedUp: true) already survives device loss through the user’s cloud keychain, while a single-device hardware credential does not. Drive enrollment of a second credential — a second platform device or a roaming security key — for the fragile ones before they ever hit recovery.

Strategy 2: a phishing-aware fallback factor

When no passkey is available, fall back to a factor that still resists or limits attacker abuse. Two acceptable options, in rough order of preference:

TOTP or single-use recovery codes. If the user enrolled an authenticator-app code or saved recovery codes when they set up multi-factor auth, those are offline, not phishable in bulk, and rate-limitable. Recovery codes in particular are designed for exactly this moment — see generating and storing MFA recovery codes for the hashing and single-use mechanics. Verifying a TOTP or recovery code grants a recovery session whose only privilege is to enroll a new passkey.

// A recovery session is scoped: it can ONLY re-enroll a credential.
async function startRecoveryWithCode(userId: string, code: string, res) {
  const ok = await consumeRecoveryCode(userId, code); // hashed + single-use
  if (!ok) return res.status(401).json({ error: "invalid recovery code" });

  await req.session.regenerate();
  req.session.userId = userId;
  req.session.scope = "recovery:reenroll"; // not a full session
  req.session.amr = ["recovery_code"];
  await req.session.save();
  res.json({ next: "enroll_new_passkey" });
}

Magic link to a verified email. A single-use, short-TTL link sent to an email the user verified earlier is acceptable only when the email account itself is well protected and the link is bound tightly: one-time token, minutes-long expiry, invalidated on use, and ideally requiring the link to be opened in the same browser that requested it. Email is the recovery channel of last resort because its security is delegated to the mailbox provider — never make it both the primary and the fallback factor.

In all cases the fallback must yield a scoped recovery session, not a full login. Its single job is to walk the user through enrolling a fresh passkey, after which they re-authenticate normally.

Strategy 3: explicit lockout and manual proofing

For accounts with no credential and no fallback factor, do not invent a self-service reset — that is the backdoor. Route to manual identity proofing (document checks, verified support workflow) with rate limits and audit logging. It is intentionally high-friction because it is the highest-risk path.

Anti-patterns that defeat phishing resistance

Security implications

Recovery is where account-takeover campaigns concentrate, because attackers attack the easiest factor, not the strongest. The threat model must assume the attacker knows the victim’s email, phone number, and public knowledge-base answers, and ask whether each recovery path still holds. Multiple enrolled credentials shrink how often recovery runs at all; scoped recovery sessions limit the blast radius when it does; rate limiting and audit logging make abuse detectable. Crucially, every recovery event should be treated as a security event — notify the user out-of-band, and require step-up before sensitive actions in the newly recovered session. For accounts that keep a password or other factors alongside passkeys, align the whole recovery design with the multi-factor authentication TOTP and FIDO2 guide so factors and recovery share one coherent policy.

Prevention & monitoring

• Measure fragile accounts. Report the share of users with a single, non-backedUp credential and drive that number down with enrollment prompts.
• Notify on every recovery. Email and in-app alert the user whenever a recovery flow starts or completes, with a one-click “this wasn’t me” lockdown.
• Rate-limit and lock recovery endpoints per account and per IP; a burst of recovery attempts on one account is a takeover signal.
• Audit-log recovery with full context (factor used, IP, device) and retain it; recovery is the path you will most often investigate after an incident.
• Expire and rotate recovery codes so a years-old leaked code can’t be replayed.

Frequently Asked Questions

Related

• Implementing passkeys and WebAuthn — the ceremony model and credential storage that recovery builds on.
• Generating and storing MFA recovery codes — the single-use, hashed recovery codes used as a phishing-aware fallback.
• Multi-factor authentication with TOTP and FIDO2 — aligning fallback factors and recovery with your broader MFA policy.