FIDO2 Account Recovery: The Gap Passwordless Rollouts Leave Open

Why the recovery path decides the security of a rollout

A FIDO2 authenticator is bound to a credential store the service cannot copy. That property is what makes phishing ineffective against it, and it is also what makes account recovery hard. When a user loses the device, there is no shared secret to fall back on. Every organisation deploying passkeys eventually designs a recovery path, and that path is frequently weaker than the password it replaced.
This is the routine failure mode of passwordless programmes. The login path is modernised, the recovery path keeps a legacy mechanism, and attackers move to the legacy mechanism.

What recovery options actually exist

A small number of defensible patterns exist, and they differ in how much they rely on a second factor the service can verify.
Multiple registered authenticators. The user enrols a primary key and at least one backup, ideally stored separately. Recovery becomes a normal authentication with the backup. This is the recommended baseline in the relevant specifications. Its weakness is human: the backup is enrolled, then left in a drawer, unverified, until the day it is needed.
Recovery codes. The service issues single-use codes at enrolment. These are shared secrets, so they reintroduce the phishing surface FIDO2 removed. They remain defensible when they are single-use, stored offline, and rate-limited, which is a narrow set of conditions.
Identity proofing. Recovery is delegated to an identity provider that has already verified the user through an independent process, such as an in-person check or a video call with document verification. This is the strongest option and the most operationally expensive.
Help-desk reset. A human confirms the requester's identity and issues new credentials. Most programmes end up here, and most of the risk lives here, because a help-desk reset is a social-engineering target with a human in the loop.

Where the failure concentrates

Published account-recovery attacks against MFA deployments share a shape. The attacker never defeats the cryptographic factor. They contact support, present enough of the victim's identity data to satisfy a checklist, and receive a credential reset.
Two properties make this effective. The identity data the checklist requires, such as employee ID, manager name, and recent activity, is often available on professional networks and in breach corpora. The help desk is measured on resolution time, which creates pressure to approve rather than to verify.

Defensive implications

Design recovery as an authentication ceremony, not as a support ticket.
Verify the backup authenticator at enrolment instead of trusting that it exists. An unverified backup is a recovery failure waiting for the day it is needed.
Keep a logged record of what changed and when for every recovery event, and notify the account owner through a channel the attacker does not control.
Separate the accounts that may be recovered through a help-desk process from those that require independent identity proofing. Administrators of identity infrastructure should not be recoverable through the path they administer.
Set the recovery process to fail closed. When verification cannot be completed, the outcome should be a delayed, supervised recovery, not an immediate reset.
The uncertainty is real. No widely deployed standard for FIDO2 recovery matches the assurance of the login ceremony, and any organisation claiming otherwise is describing its own controls rather than a specification. The workable position is to make recovery as strong as it can be for the accounts that matter, and to state the residual risk plainly.