How should organisations recover a lost passkey?

What a Lost Passkey Recovery Process Must Preserve

A lost passkey should be treated as a credential recovery event, not as a reason to weaken the original authentication model. The recovery flow needs to preserve the same assurance that the passkey provided in the first place: the user must prove identity again, the old credential must be revoked, and the new credential must be issued under controlled conditions.

The key design choice is whether the organisation is recovering a device-bound passkey, a synced passkey, or an account recovery path that leads back to passkey enrollment. The principle is the same in each case: restore access through verified identity, then re-establish the authentication binding from scratch rather than reusing trust in the lost factor.

Where organisations already support passkeys as part of a broader Passwordless and Passkeys Guide, recovery should be designed as part of the same lifecycle, not as an exception handled ad hoc. That means the recovery step should fit the assurance level of the account, the sensitivity of the system, and the fallback methods the organisation is willing to trust.

How to Recover Access Without Opening an Attack Path

Strong recovery starts with re-authentication that is meaningfully harder to fake than normal sign-in. Organisations should use step-up checks such as an already-verified second factor, a pre-established recovery channel, or a supervised identity proofing flow where the account risk justifies it. If the fallback path is weaker than the passkey itself, attackers will target the recovery path instead of the primary login.

Once recovery is approved, the lost passkey should be revoked cleanly and the replacement enrolled as a new binding. Avoid parallel validity, temporary exceptions, or a grace period where both the old and new authenticators can work. Those shortcuts create a window where a stolen or found credential can still be abused after the user believes recovery is complete.

Recovery design also depends on the surrounding identity controls. Where passkeys sit inside a broader workforce login stack, the organisation should coordinate revocation, session review, and sign-in policy changes so that the new passkey is not undermined by lingering sessions or other still-valid login methods. Guidance in the Workforce Identity Security Guide is useful here because recovery is only one part of the larger account security state.

Operational Checks After a Passkey Is Lost

After a lost passkey is reported, the practical question is not only whether the user can get back in, but whether someone else may already have tried. Review recovery events, failed sign-in spikes, unusual device changes, help desk contact patterns, and any recent session activity on the account. If the account controls sensitive data or administrative functions, treat the event as a potential takeover attempt until the logs show otherwise.

Recovery should also be tested before an incident happens. Organisations need to confirm that their fallback options are resistant to social engineering, that the help desk cannot bypass the recovery checks under pressure, and that the process works when the user has lost the original device, lost the synced device, or lost access to the usual secondary channel. A recovery path that is only secure on paper usually fails when the real user is locked out and the attacker is persuasive.

For teams building the process around identity proofing and authenticator lifecycle controls, the most useful reference point is NIST SP 800-63 Digital Identity Guidelines, especially where the organisation needs a defensible standard for re-authentication and recovery assurance. The main operational lesson from that model is that recovery assurance should match the account’s actual risk, not the caller’s urgency.

Practitioner Guidance

What to prioritise: Put revocation and re-binding ahead of convenience. A lost passkey is safest when the old authenticator is invalidated immediately and the new one is issued only after the recovery check is complete.

What to verify: Confirm that the recovery path cannot be satisfied by the same channel an attacker can easily hijack, such as weak email-only fallback or help desk shortcuts. Also verify that logs capture who approved recovery, what evidence was used, and whether any session or device state remained active.

Decision rule: If the lost passkey could have authenticated to a privileged or high-value account, require stronger recovery scrutiny and post-recovery monitoring than you would for an ordinary user account. If the fallback method is materially weaker than the original passkey, it is not a safe substitute.

Practitioner takeaway: Good passkey recovery is a controlled identity re-verification process, not a relaxed workaround, because the recovery path is often the easiest path to compromise.

Related resources from NHI Mgmt Group

• Guide: Account Recovery and Help Desk Security Guide
• What should organisations do first when a passkey is lost or deleted and no other MFA factor exists?
• Should organisations build or buy a passkey solution?
• Should organisations keep enterprise password managers after passkey adoption starts?
• What do organisations get wrong about passkey and certificate adoption?