What should organisations do first when a passkey is lost or deleted and no other MFA factor exists?

The first priority is to ensure account recovery is not dependent on a single passkey. Organisations should require two additional recovery factors, or at minimum well-managed recovery codes, before they allow passkeys to become the primary sign-in method. That reduces lockout risk if a device is lost, a cloud manager entry is deleted, or a user cannot access their passkey.

Why Losing the Only Passkey Becomes an Account Recovery Problem

A lost or deleted passkey is not just a convenience issue when it is the only factor left. At that point, the organisation has turned authentication into a single point of failure, so recovery design matters as much as sign-in design. The practical question is whether the account can still be recovered without weakening assurance or creating an ad hoc help desk override.

That is why organisations should treat passkey rollout as a recovery architecture decision, not just a login upgrade. If a user can authenticate only with one device-bound or cloud-synced passkey and nothing else, then device loss, profile deletion, or platform sync failure can strand the account. A safer design keeps recovery separate from everyday sign-in, so the loss of one credential does not become a complete lockout.

NHIMG research shows why lifecycle controls matter: only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them. The same lifecycle discipline applies here, because the issue is not the passkey itself but whether an organisation can still govern access when that factor disappears. In practice, many teams discover the weakness only when a user is already locked out and a rushed exception path has to be improvised.

How Recovery Should Work When No Secondary Factor Exists

The first step is to decide whether the account should ever be allowed to rely on a single passkey at all. For most environments, the answer should be no. Organisations should require two additional recovery factors, or at minimum managed recovery codes, before passkeys become the primary sign-in method. That way, the organisation can verify identity after a passkey loss without resetting trust based on a single support interaction.

In practice, good recovery design separates three things: daily authentication, account recovery, and administrative reset. Daily authentication can be passkey-first, but recovery should use a different trust path such as a second device, a pre-enrolled backup factor, or a controlled recovery code flow. Administrative reset should be reserved for cases where the user can be re-verified through documented identity proofing and an auditable approval process.

Require at least one backup factor before enabling passkey-only sign-in.
Issue recovery codes through a channel the user can store securely offline.
Define who can approve a recovery exception and what evidence is required.
Log every recovery action so support teams can distinguish normal recovery from fraud.

For organisations that already use hardware-bound credentials, the same principle still applies: do not let the strongest factor become the only factor. A second factor may be a separate passkey on another device, a vetted recovery code set, or another authenticating mechanism that is not co-located with the primary passkey. NIST guidance on identity assurance and authentication emphasises controlled recovery and re-binding processes rather than informal resets, and the control logic should be reflected in the account lifecycle, not improvised after loss. The relevant control set is described in NIST SP 800-53 Rev 5 Security and Privacy Controls.

Where organisations also manage machine or service credentials, the same lesson from NHIMG’s guide on non-human identity governance is that recovery paths must be explicit, tested, and revocable rather than assumed. If the backup path is undocumented, it is not a control. If it is easy enough to bypass under pressure, it is not a recovery control either. The direct lesson is explained in Ultimate Guide to NHIs.

These controls tend to break down when recovery is handled entirely by a help desk, because support pressure pushes teams toward weak identity verification and one-time exceptions.

When Passkey Loss Exposes a Bigger Governance Gap

Tighter recovery controls often increase friction, so organisations have to balance usability against lockout risk. That tradeoff becomes visible in edge cases such as shared support models, bring-your-own-device environments, or users who rely on a single consumer cloud account to sync their passkeys. Best practice is evolving here, and there is no universal standard for every organisation, but the principle is stable: the recovery path must be harder to abuse than to use.

Another edge case is the “deleted but still trusted” scenario, where the user believes the passkey is gone but the organisation still has stale trust records, cached sessions, or unmanaged backup devices. That is why teams should verify not just the user’s current device state but also whether any second factor, synced credential, or recovery code remains valid. If none exists, the account is not recoverable in a controlled way, and the organisation must treat that as a design defect rather than a support nuisance.

Organisations should also decide in advance what happens when passkey loss overlaps with suspected compromise. A lost factor plus abnormal sign-in activity should trigger a higher-assurance recovery review, not a faster reset. The practical boundary is simple: if the organisation cannot explain how identity is re-established without weakening the original assurance level, then the recovery model is under-designed.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, CIS Controls v8, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.AA-1 — Identity and Credential Management	Passkey loss is an identity assurance and recovery design issue.
	PR.AA-2 — Identity Proofing and Credential Binding	Recovery must re-establish identity without weakening assurance.
Recommendation — Require alternate recovery paths before making passkeys the only sign-in factor. Re-bind access only after verified recovery, not after an informal reset.
CIS Controls v8	5 — Account Management	Backup factors and controlled reset flow are account lifecycle controls.
	6 — Access Control Management	Access should not depend on one lost authenticator.
Recommendation — Inventory recovery methods and remove any single-point account recovery dependency. Enforce separate recovery controls before allowing primary passkey use.
NIST Zero Trust (SP 800-207)	AC-2 — Account Management	Zero Trust still requires controlled re-authentication after credential loss.
Recommendation — Treat passkey recovery as managed account re-establishment, not a trust reset.
NIST SP 800-63	IAL2 — Identity Assurance Level 2	Recovery should preserve the original identity assurance level.
	AAL2 — Authenticator Assurance Level 2	Passkey use depends on binding and recovery of authenticators.
Recommendation — Use identity proofing strong enough to restore access without downgrading assurance. Require at least one independent authenticator or recovery mechanism before passkey-only rollout.

Practitioner Guidance

What to prioritise: Make recovery factors part of the enrolment standard, not an optional follow-on. If a passkey is allowed to become the only factor, the organisation is choosing lockout risk up front.

Decision rule: If the account cannot be recovered through a separate, pre-enrolled trust path, do not promote passkey-only sign-in to production for that user population.

What to verify: Confirm that recovery codes, backup devices, and admin reset paths are all independently documented, tested, and revocable. A recovery path that exists only in policy language is not operationally real.

Practitioner takeaway: The first control is not faster recovery, but preventing single-factor recovery dependency in the first place, because the moment passkey loss becomes unrecoverable, the organisation has already converted authentication failure into an access governance failure.