Passkey Account Recovery Is the Whole Problem

Here is a claim you will find on nearly every passkey landing page, including some very good ones: passkeys are phishing-resistant, unphishable, unreusable, and not vulnerable to credential stuffing. All of that is true.

Here is the sentence that usually follows, several scrolls later, in smaller type: "If you lose access to your passkeys, you can recover your account using your email address."

Read those two claims together and notice what has happened. You have replaced a credential that could be phished with one that cannot, and then attached to the account a recovery path that can be — and that, when exercised, produces exactly the same outcome as a successful phish. The attacker's job did not get harder. It got relocated.

This is not a criticism of passkeys. WebAuthn is the most significant improvement in consumer authentication in twenty years and I would deploy it everywhere. It is a criticism of how the deployment conversation is structured: teams spend three months on the registration and authentication ceremonies, which are the well-specified and comparatively easy part, and three days on recovery, which is now the actual security boundary of the account.

Your authentication strength is min(passkey, recovery_path). It has always been a minimum function. Passwords hid this, because the password was usually the weakest link and the recovery flow was merely as weak. Passkeys make the asymmetry impossible to ignore.

Why the passkey-shaped version of this is different

Account recovery has always been the hardest problem in identity, and the general shape of that argument holds here. But passkeys change the problem in four specific ways, and skipping them is how you end up designing recovery for the wrong threat.

The credential cannot be transmitted, so it cannot be re-delivered. A password can be reset — you send a link, the user picks a new string, the account works again. A private key living in a Secure Enclave cannot be re-issued to a new device, ever. There is no "reset my passkey" that returns the same credential. Recovery therefore always means enrolling a new credential, which means the enrolment path is a full account-takeover primitive. With passwords, the reset flow set a value the user chose. With passkeys, the recovery flow grants a permanent, phishing-resistant, hard-to-detect foothold.

Loss is much more likely than compromise. For passwords, the risk model was dominated by theft: breaches, reuse, phishing. For passkeys, theft is genuinely hard, so the dominant event by a wide margin is the user no longer has the thing. Phone in a lake, phone stolen, phone replaced and the migration didn't carry the credential, device wiped by MDM, employee's laptop returned to IT. Your recovery flow will be exercised far more often, by far more legitimate users, than the equivalent password flow ever was — while simultaneously being far more valuable to an attacker. Both dials moved in the wrong direction at once.

Users cannot tell you what they have. "Do you have a passkey for our site on another device?" is a question most users cannot answer. The credential is invisible: created during a flow they half-remember, stored by a platform they don't distinguish from the browser, possibly synced to a keychain they've never opened. A user who has three working passkeys will call support saying they have none. Any recovery flow gated on the user correctly reporting their credential inventory is gated on a coin flip.

The credential is bound to an ecosystem, not a device. Synced passkeys live in iCloud Keychain, Google Password Manager, or a third-party manager, and the recovery story for the account is now downstream of the recovery story for that ecosystem. Which is mostly good news — Apple and Google have invested enormously in it — but it means your users' access to your service depends on a vendor relationship you have no visibility into and cannot troubleshoot. When someone loses their Google account, they lose every passkey stored in it, and they arrive at your support queue with a problem you cannot see the cause of.

The recovery paths, honestly assessed

There are roughly seven things you can build. Each one has a real cost and none of them is free.

Email a magic link. The default, and the one that quietly negates the phishing resistance you just bought. Email is a bearer channel: possession of the inbox is possession of the account. It's phishable, it's vulnerable to whatever the mail provider's own recovery flow allows, it's frequently accessible on an unlocked device, and it's the first thing an attacker pivots to. If your passkey is phishing-resistant and your recovery is an emailed link, an attacker with a convincing "verify your account" page and control of nothing but a lookalike domain still wins — they just phish the recovery rather than the login.

This does not mean never use it. It means: if email recovery exists, your account's security level is your email provider's security level, and you should say so internally rather than claiming phishing resistance in a security questionnaire.

SMS to a registered number. Worse. SIM swap is a mature, cheap, industrialized attack, and the recovery flow is exactly what it targets. Its one virtue is that it works for a population that has no other channel, which is a real consideration for consumer products with older users.

A second passkey on a second device. The best answer, and the one that fails on adoption. Structurally, "enrol two authenticators" is correct: the recovery path is another instance of the strong credential, so the minimum function no longer has a weak branch. The problem is that users will not do it during signup. They came to buy something. A prompt asking them to enrol a second device is friction against a threat they don't yet believe in, and the completion rate reflects that.

What actually works is asking later, at a moment when the value is legible: after the user has stored something worth protecting, at the point they add a payment method, or — the best trigger — immediately after they successfully use the first passkey on a second device, because that proves they have two devices and the enrolment is one click. Nudging at signup is worth doing but plan for a low single-digit percentage. Nudging at the right moment can get you to a majority.

Printed recovery codes. Honest, offline, and phishing-resistant in the sense that nothing about them is transmitted. Also: users lose them, store them in the same password manager that held the passkey (which correlates the failure completely), or photograph them and leave the photo in a synced camera roll. Recovery codes are genuinely useful for a technical audience and near-useless for a consumer one, and it is worth being clear-eyed about which audience you have. They also need to be single-use, hashed at rest like passwords, and rate-limited — a 10-character code checked without a limiter is a brute-force target.

A hardware security key as backup. Excellent security, real cost, and an adoption ceiling somewhere around "people who already own one." For workforce identity this is often the right default and the cost is the company's. For consumer, it's a feature for the 1% who will use it and should be offered rather than relied on.

Identity document verification. Upload a passport, take a selfie, a vendor scores the match. The strongest binding to a real human that you can buy, and the right answer for high-value accounts — banking, healthcare, crypto. Costs a few dollars per attempt, adds a vendor with a privacy footprint, has a false-rejection rate that disproportionately affects exactly the people who most need support, and does nothing at all for accounts that were never identity-verified in the first place. You cannot verify someone back into an account that never knew who they were.

Human support. The one everybody ends up with, and the one most worth designing rather than defaulting into. A support agent who can enrol a new credential is, from an attacker's point of view, an API with a natural-language interface and no rate limit. Social engineering the help desk is how a great many high-profile takeovers actually happened, including several where the technical controls were excellent.

If you have human recovery — and at scale, you will — then treat the agent as a system component with a threat model: the agent must not be able to complete recovery unilaterally, the questions they ask must come from data the account has generated rather than data an attacker can research, the action must require a second approver above a value threshold, and every recovery must be irreversibly logged with the agent's identity attached. The strongest single control is a mandatory delay with out-of-band notification, which we'll come to.

The design that actually holds up

Recovery is not a mechanism to choose. It is a risk decision to make per attempt, and the useful mental model is that you are re-authenticating a user with degraded evidence and must decide how much degradation you'll accept for how much account value.

flowchart TD
    A["Recovery requested"] --> B{"Evidence available?"}
    B -->|"Second passkey"| C["Immediate recovery<br/>notify all channels"]
    B -->|"Recovery code + known device"| D["Immediate, scoped:<br/>enrol credential, no sensitive ops"]
    B -->|"Email only, known device,<br/>normal location"| E["24–72h delay<br/>reversible window"]
    B -->|"Email only, new device,<br/>new country"| F["ID verification<br/>or support escalation"]
    C --> G["New passkey enrolled"]
    D --> G
    E --> G
    F --> G
    G --> H["Cooling-off period:<br/>old credentials retained,<br/>high-value actions blocked"]

Four ideas in that diagram do most of the work.

Delay is your most underrated control, and it is nearly free. If a recovery attempt on weak evidence takes 48 hours and sends a "someone is trying to recover your account — click here to stop this" notification to every channel on file, then the legitimate user who genuinely lost their phone waits two days and gets in, while the attacker's window is two days during which the real owner is repeatedly told what's happening. Delay converts an instantaneous, silent takeover into a slow, loud one. Almost no consumer product does this, and it costs nothing but product courage.

The corollary: the notification must be un-suppressible by the recovery flow itself. If recovering the account also changes the notification address, the attacker's first move is to cut the wire. Notification destinations should be frozen for the duration of the cooling-off period.

Recovery should grant less than a login. This is the single biggest structural improvement available and it's rarely built. A recovered session does not need to be a fully privileged session. Let it enrol a new passkey and read the account. Do not let it change the email address, delete the account, export data, add a payment method, or move money, for some period — 24 hours, a week, depending on your stakes. An attacker who has taken over an account but cannot extract value from it for seven days, while the real owner is being notified, has substantially failed. Most products treat recovery as a binary gate producing full authority, which is why a single successful recovery is game over.

Don't destroy the old credentials immediately. Instinct says revoke everything on recovery. But if the recovery was fraudulent, those credentials are the legitimate owner's only proof — and the strongest possible signal that something is wrong is the old passkey being used successfully during the cooling-off window. Keep them valid, and treat their use as a fraud alarm that reverses the recovery. This is the fastest and highest-confidence detection you will ever get, and revoking on recovery throws it away.

Design for the correlated failure. The scenario your flow must survive is not "user lost one device." It is "user's phone was stolen, and the phone had their email, their SMS, their authenticator app, and their password manager." That is one event and it removes four of your seven recovery channels simultaneously. Any recovery design whose channels all live on the same physical object is a design with one channel. Ask of every mechanism: if the phone is gone, does this still work? Printed codes and a hardware key survive. Email, SMS, TOTP, and a synced keychain accessed via that phone do not.

Workforce is a different problem, and easier

Everything above is consumer-shaped. Enterprise recovery has a resource consumer products can only dream of: a verified human relationship and a colleague who can look at a face.

Use it. The strongest recovery flow in existence is an in-person or video verification by a manager or IT staff member who knows the person, combined with an out-of-band check against the HR record. It is not scalable to millions and it doesn't have to be.

Two enterprise-specific notes. First, the correlated-failure question has a good answer here: issue a hardware key as the mandatory second authenticator and hold a small pool of spares at each office. The cost is trivial against the cost of a locked-out engineer or a socially-engineered helpdesk. Second, passkey recovery is a provisioning problem, not an authentication one. Day-one enrolment and post-loss re-enrolment are the same operation, and if your identity platform models it as "an operator with a scoped permission enrols a credential for a user, and it's audited," you already have recovery — with the delegated-administration boundary and audit trail attached. Most enterprise IAM systems treat these as unrelated features. They are the same feature, and noticing that removes an entire duplicate design.

Which points at the general principle: the recovery path should be a first-class, permissioned, audited operation in your identity model, not a special-cased branch inside the login controller. When it's the latter, nobody can answer "who has recovered accounts this quarter, and on what evidence" — and that question is the only way you find out your recovery flow is being abused.

What to actually do

If you are deploying passkeys, the ordering that matters:

1. Write down your recovery path and its strength before you ship the passkey. If the honest answer is "email link," then you have built a phishing-resistant login on top of a phishable account. That may be an acceptable improvement — it removes credential stuffing and password reuse, which are enormous wins — but claim that, not phishing resistance.
2. Drive second-credential enrolment as a product metric. Not a checkbox in settings. Prompt at the moment of proven multi-device use, and measure the percentage of accounts with two or more credentials as the headline number for the whole programme. It is the only metric that reduces the minimum function.
3. Add delay plus un-suppressible notification to every weak-evidence path. Cheapest strong control available.
4. Scope the recovered session. Enrol-and-read, not full authority, for a cooling-off window.
5. Keep the old credentials alive during that window and alarm on their use.
6. Model recovery as an audited operation with named actors, not as a branch in a controller.

The uncomfortable summary is that passkeys move the hard problem rather than solving it, and the hard problem was always the same one: proving that a human without a credential is the human who used to have one. Nothing in WebAuthn addresses that, because nothing can. Cryptography can prove possession of a key. It cannot prove identity to someone who has lost the key, and it never will.

Which means the recovery flow is not the boring part of your passkey project. It is the part where you decide how secure the account actually is. Everything else is the part that's already solved.