How should organisations handle passkey recovery across new devices and old accounts?

How to design passkey recovery so new devices do not strand legitimate users

Passkey recovery should be designed as a first-class control, not treated as an exception that undermines the passwordless model. The practical challenge is preserving account continuity when a user changes device, loses an old email address, or relies on platform sync. That means recovery has to be tested as part of the normal sign-in journey, with controls that match the account’s risk.

For organisations rolling out passkeys, the key decision is whether the recovery path preserves the same assurance as the primary authenticator or deliberately steps down for lower-risk accounts. A good design separates routine device migration from true account recovery, because those two events carry very different abuse potential.

For implementation detail on passkeys, phishing resistance, and recovery patterns, Passwordless and Passkeys Guide is the most direct reference point.

What to test before you trust the recovery flow

Recovery should be exercised against the scenarios that actually break users out of their accounts: switching phones, replacing laptops, losing access to the old mailbox, restoring from backup, and moving between ecosystems with different sync behaviour. If any of those paths silently depend on a legacy email inbox, SMS, or an unreviewed help desk process, the passkey model is only partially deployed.

Organisations should also separate consumer-style convenience recovery from workforce or high-value account recovery. In lower-risk environments, a simpler fallback may be acceptable if the blast radius is small. For privileged, financial, or high-impact accounts, recovery should require stronger verification, explicit step-up checks, and a clear ownership trail.

Where support staff or service desks are involved, recovery controls should be verified against social engineering as well as technical failure. Account Recovery and Help Desk Security Guide and Workforce Identity Security Guide both address why recovery must be designed, monitored, and bounded like any other sensitive access path.

Platform behaviour matters too. synced passkey can improve survivability across device loss, but they change the trust model because the user is no longer relying only on one physical authenticator. That is useful, but it also means organisations must understand what the platform provider syncs, how account takeover of the platform account is handled, and when a device replacement becomes a genuine recovery event rather than routine continuity.

What fallback options are appropriate when recovery must be possible

Not every account should use the same fallback. High-risk accounts often need more than one recovery lane, but each lane should be explicit about its assurance level. A common pattern is to combine recovery codes, verified device change, help desk-assisted escalation, and step-up identity checks, then reserve the strongest path for the highest-value accounts.

Fallback options should be chosen to reduce lockout without turning recovery into a universal bypass. That means avoiding weak shortcuts that are easy to social engineer, such as loose support overrides or knowledge-based questions. It also means defining when a user can self-recover and when the case must be escalated for manual review.

Organisations handling consumer accounts or broad customer populations should map this to account takeover risk and recovery abuse. Customer IAM (CIAM) Guide is useful where recovery must balance usability, fraud resistance, and account continuity across large populations.

For stronger assurance around identity checks before recovery is granted, Identity Proofing and KYC Guide helps frame when additional verification is justified, especially for accounts where device loss could expose sensitive data or financial value.

Risk and Threat Considerations

Passkey recovery is a high-value target because it can become the easiest route around a strong authenticator. If the recovery process is weaker than the passkey itself, attackers will aim for the recovery step rather than the login step, especially through help desk impersonation, mailbox compromise, or platform account takeover.

Failure mechanism: Recovery flows fail when organisations over-trust a lost email address, a support agent override, or a synced platform account without verifying that the person requesting recovery still controls the account with sufficient assurance.

Impact: The result can be account takeover, silent re-enrolment of a new authenticator, or permanent lockout of the legitimate user. In higher-value environments, that can also create persistence, delayed detection, and a false sense that passkeys alone solved authentication risk.

Practitioner Guidance

What to verify: Test passkey recovery as a complete workflow, not just as an enrollment feature. The strongest evidence is a successful device-change test, a failed old-email test, and a reviewed fallback path that still meets the account’s risk threshold.

Decision rule: If the account can move money, change security settings, or expose sensitive records, require a recovery path with step-up verification and clear auditability. If the account is low-risk, you can optimise for usability, but only after confirming that the fallback cannot be used as a generic bypass.

Common mistake: Treating “we use passkeys” as equivalent to “recovery is secure.” The recovery path is part of the authenticator model, and it should be reviewed with the same discipline as enrollment, revocation, and reset handling.

Practitioner takeaway: The right question is not whether users can recover, but whether recovery preserves the intended assurance level while still allowing legitimate migration to a new device.

Related resources from NHI Mgmt Group

• How should security teams handle recovery for passkey-protected accounts?
• How should organisations implement authentication as a service without creating new access sprawl across their apps and devices?
• How should organisations handle outdated browser risk across employee devices and access workflows?
• When should organisations prioritise federated identity over forcing a new directory standard across devices?