Passkeys Stop Phishing. Account Recovery Decides Whether They Stop Takeover.

A security team can finish a passkey rollout, report that most employees now sign in with phishing-resistant credentials, and still leave the account takeover path exactly where it was. The sign-in page got stronger. The phone line to the service desk did not.

On August 25, 2026, the W3C published Web Authentication Level 3 as a Recommendation. For many organizations that milestone will restart a stalled passkey program, and it should. The cryptography is sound, support for the core API is broad, and the user experience has finally become good enough for general populations. The risk is that the program is scoped as a sign-in project, measured by enrollment, and declared done while every other way of getting into an account keeps its old assurance.

Our position is simple. The assurance of an account is the minimum across every path that can bind a new credential to it, not the strength of the path most users take. Passkeys raise one path. Recovery, re-enrollment, help desk resets and administrative overrides decide whether the account actually got safer.

What Level 3 changes, and what it does not

Much of Level 3 codifies capabilities that browsers and platforms had already started shipping, and that is good news for anyone planning work. The specification’s change log lists JSON serialization methods that remove a class of hand-written encoding bugs, conditional mediation for both creating and using credentials so passkeys can appear in autofill, a getClientCapabilities() method, a hybrid transport value for signing in on one device with a phone, support for related origins, and a set of signal methods that let a site tell the credential provider which credentials are still valid.

Two of those deserve attention beyond the sign-in page. The capabilities method, which MDN marks as Baseline 2025, lets you decide at runtime which enrollment and fallback flows a client can actually support instead of guessing from the user agent. The signal methods let you clean up credentials you have revoked, which matters when a lost device or a recovery event should retire an old passkey. Treat them as helpful rather than authoritative: MDN still lists signalAllAcceptedCredentials() as limited availability, and the specification says clients provide signals opportunistically and do not report whether an update succeeded. Revocation still has to be enforced on your server.

What Level 3 does not do is define how a person who has lost every credential gets back in. That is deliberately outside the protocol. It is also where the attacks have gone.

The advisory that describes the gap

The joint CISA and FBI advisory on Scattered Spider, last revised in July 2025, is worth reading as an architecture document rather than a threat bulletin. It describes a group that first calls to learn what a help desk requires for a password reset, then gathers the specific details for a target employee, and finally persuades help desk staff to reset passwords or transfer MFA to a device the attacker controls. The advisory notes that these calls are enriched with personal information from social media, commercial tools and leaked databases.

The same advisory recommends FIDO and WebAuthn authentication because those methods resist phishing, push bombing and SIM swapping. Both statements are correct, and together they describe the trap. Phishing-resistant credentials remove the cheapest attacks on sign-in. They do nothing about a process that will issue a new credential to whoever is most convincing on the phone. If that process exists, the attacker’s cost of entry is the cost of a good pretext, regardless of how many employees enrolled a passkey.

Treat account credentials as a state machine

Most passkey designs are drawn as a login sequence. The failure is easier to see when you draw the account instead, with the states it moves through as credentials are added, lost and replaced.

stateDiagram-v2
  state "Normal operation" as Normal {
    state "No redundancy" as Exposed
    state "Redundant" as Resilient
    [*] --> Exposed: first passkey, BS=0
    [*] --> Resilient: first passkey, BS=1
    Exposed --> Resilient: separate device added, or BS=1
    Resilient --> Exposed: revocation or backup loss
  }
  [*] --> Normal
  Normal --> Recovery: anyone claims lockout
  Recovery --> Normal: owner passes target proof
  Recovery --> Takeover: attacker's claim accepted

The important edge is the one labeled “anyone claims lockout”. The legitimate user and the attacker enter recovery the same way. Nothing about the passkey the real user holds is visible at that moment, so the proof recovery demands is the only thing separating the two exits. When that proof is weaker than sign-in, the takeover exit is the cheaper one for an attacker to reach.

Use the signals the specification already gives you

WebAuthn exposes recovery-relevant information worth storing. Every authenticator response carries two flags in its authenticator data. Bit 3, Backup Eligibility, says whether the credential can ever be backed up. Bit 4, Backup State, says whether it is backed up right now. An eligible credential is not necessarily a backed-up one, and an account can hold both kinds. The specification’s section on credential backup state makes the eligibility flag permanent for a credential, defines the backup flags as part of each credential record, recommends that sites store their most recent values, and spells out what to do with them. Keep that state per credential, not per account, or a sign-in with one authenticator will mask a change on another.

// authData: authenticator data your server has already verified.
// Bytes 0-31 are the RP ID hash; byte 32 holds the flags.
const flags = authData[32];
const backupEligible = (flags & 0x08) !== 0; // bit 3, BE: permanent
const backedUp = (flags & 0x10) !== 0;       // bit 4, BS: can change

// Compare against the stored record for THIS credential.
const cred = await credentials.get(credentialId);
const lostBackup = cred.backupState === true && !backedUp;
await credentials.update(credentialId, {
  backupEligible,
  backupState: backedUp,
});

// Backup switched off for this credential: review factors
// while the user can still sign in.
if (lostBackup) {
  queuePrompt(account, 'review-factors-and-add-credential');
}

// Account redundancy, as last observed, over ACTIVE credentials
// only. A credential count is not independence: two passkeys can
// live on one phone. enrolledDeviceId is an ID your app assigns to
// the physical device holding the authenticator (a security key is
// its own device), not the browser that ran enrollment. Credentials
// with an unknown device do not count. Rerun after every revocation.
const all = await credentials.listActive(account.id);
const anyBackedUp = all.some((c) => c.backupState);
const known = all.filter((c) => c.enrolledDeviceId != null);
const devices = new Set(known.map((c) => c.enrolledDeviceId));
if (!anyBackedUp && devices.size < 2) {
  queuePrompt(account, 'register-second-authenticator');
}

That guidance maps directly onto the state diagram. A single-device credential “is not resilient to single device loss”, so the site should make sure another authenticator is registered or that a recovery process exists. When backup state changes from backed up to not backed up, the site should guide the user through validating their other factors and adding a credential. Separately, the specification’s discussion of credential loss says sites should allow and encourage multiple credentials per account and use the registration options to keep them bound to different authenticators. Even then, different authenticators can share one device, so the backup flag you stored is the last observed signal, not a guarantee.

The point of doing this is not a nicer settings page. Every account you make redundant before it needs recovery is an account far less likely to reach the weakest path through ordinary device loss. Fewer legitimate recoveries also make the remaining ones easier to scrutinize.

A published floor for recovery

Private companies are not bound by NIST’s federal identity guidelines, but SP 800-63B-4, finalized in July 2025, is the most concrete public baseline for what recovery should require. It recognizes four classes of recovery method: saved recovery codes, issued recovery codes, recovery contacts and repeated identity proofing. To recover an account whose maximum authentication level is AAL2, it requires two recovery codes obtained through different methods, one recovery code plus a single-factor authenticator already bound to the account, or repeated identity proofing. That last option exists only for accounts that were identity-proofed in the first place, and it means repeating the proofing steps and confirming the claimant matches the identity already on record, not a first-time document check or an informal call. An issued code sent by text message is valid for at most ten minutes, one sent by email for at most 24 hours, and every recovery must trigger a notification to the subscriber.

Two details matter for passkey programs. First, NIST notes that look-up secrets, the category saved recovery codes belong to, are not phishing-resistant. A recovery code is a pragmatic fallback, not an equivalent of the passkey it replaces, so its use should be rare, throttled and loudly notified. Second, the appendix on syncable authenticators accepts synced passkeys at AAL2 when access to the sync fabric is itself protected by AAL2-equivalent MFA, and states that syncing violates the non-exportability requirement of AAL3. A synced passkey therefore inherits some of the recovery posture of the platform account that holds it. That is an acceptable trade for most consumer and many workforce populations. It is a poor fit for administrators of your identity provider.

Choosing recovery by population

No single recovery design fits every account. The useful question is what a convincing impostor would need to defeat, compared with what sign-in requires. The table below is our recommendation, informed by the NIST floor rather than quoted from it.

Administrators tolerate far more recovery friction than consumers, and consumers carry more residual recovery risk, because the consequences of a takeover differ, not because one population deserves less security. The employee row deserves particular scrutiny: a help desk measured on resolution time, with verification steps an agent can skip, can easily become the weakest recovery path in the company.

Four failure modes worth naming

Passwordless with a password in the basement. Passkeys are offered, but the password and its reset email still work. Attackers do not use the passkey flow; they use the reset link. If you keep a password during migration, record who still depends on it and put a removal date on it.

The help desk as an authenticator. An agent who can transfer MFA after answering questions is an authentication factor, and a weak one, because the answers are exactly the personal details the CISA advisory says attackers collect. Give agents a verification procedure they cannot shortcut and a tool that enforces it.

The silent downgrade. A user who lost their phone recovers with a code by text message, and the account quietly returns to full access. The strong credential is gone, the only notification may have gone to a number the attacker controls, and nobody reviews the event. Recovery should notify every remaining channel and delay high-impact changes such as payout details or adding new administrators.

Enrollment as the success metric. Dashboards report the share of users with a passkey. That number can approach full coverage while every account keeps an SMS reset. Measure the share of accounts whose every binding path meets the target assurance, and report recovery volume, recovery abuse and time to detect a fraudulent recovery alongside it.

The honest counterargument

Recovery hardening is not free, and the research does not show a consensus that it is the main obstacle. In a USENIX Security 2024 interview study of 28 security leaders, authentication managers and FIDO2 experts, fallback authentication and recovery options were among the biggest obstacles participants reported to deploying passwordless authentication. The authors also report that opinions were mixed, and some participants felt passkeys fully allay concerns about account recovery.

For ordinary device loss, they have a point. A synced passkey that follows the user to a new phone removes a large share of legitimate recoveries, and that is a real improvement. It does not resolve the case that matters for takeover: someone who claims to be the user and has no credential at all. Every added verification step also costs support time and produces lockouts, which are an availability failure with their own business cost. The right answer is to make legitimate recovery rarer through multiple credentials and synced storage, so the remaining recovery path can afford to be slower and stricter.

A sequence that fits one quarter

Start with an inventory, not a technology choice. For each population, list every binding path, including the undocumented ones such as an administrator console that can clear MFA and the identity provider’s own recovery flow. Record what proof each path accepts and who can invoke it.

Next, store the backup flags on every sign-in, prompt single-device users to register a second authenticator, and act on backup state changes while the user can still sign in. Use getClientCapabilities() to offer only flows the client supports, and use the signal methods to retire revoked credentials, while continuing to reject them on your server.

Then rewrite the help desk procedure so that no agent can bind a new credential on knowledge answers alone, and test it the way an attacker would. Scheduled pretext calls, with leadership approval and a clear stop condition, will tell you more about your recovery assurance than any enrollment chart. Finally, add notifications to every remaining channel, delay sensitive changes after recovery, and put recovery events on the same detection pipeline as suspicious sign-ins.

Passkeys are worth deploying, and Level 3 removes most of the excuses for waiting. Deploy them as an account security program rather than a sign-in feature. The work that decides the outcome is quieter: counting the ways into an account, closing the ones that accept weaker proof, and rehearsing the moment someone calls and says they are locked out.

If your passkey program is moving faster than your recovery design, we can help. We work with engineering and security teams to map every credential binding path, design recovery and help desk verification that match sign-in assurance, and plan a phased migration away from password and SMS fallbacks. Talk with us about your authentication architecture.