Why do passkeys still need fallback controls?

Passkeys reduce password risk, but users can still lose devices, accounts can be locked, and synchronisation ecosystems can fail. Fallback controls exist to preserve access, but they must not be weaker than the assurance you are trying to protect. If fallback is easier to abuse than the passkey, overall security drops.

Why This Matters for Security Teams

Passkeys raise the baseline for user authentication, but they do not eliminate the need for recovery paths. A lost device, a broken sync chain, a reset cloud account, or a locked authenticator can strand a legitimate user unless fallback is available. The security problem is not whether fallback exists, but whether it is bound to the same assurance level as the passkey. NIST’s NIST SP 800-63 Digital Identity Guidelines treats recovery as part of the authentication lifecycle, not an afterthought.

That matters because recovery flows are often the softest point in the identity stack. If a passkey is protected by phishing-resistant authentication, but fallback relies on weak email resets, SMS codes, or help desk exceptions, the attacker only needs the weaker route. NHI Management Group’s Ultimate Guide to NHIs — Standards highlights the same operational pattern in machine identity governance: the weakest exception usually becomes the control failure. In practice, many security teams discover that the recovery path was the real attack path only after account takeover or support abuse has already occurred.

How It Works in Practice

Strong fallback design starts with the assumption that the primary authenticator will fail sometimes. Users lose phones, device-bound credentials expire, sync providers misbehave, and enterprise-managed endpoints get reimaged. The goal is to preserve access without downgrading assurance. Best practice is evolving, but current guidance suggests that fallback should be step-up verified, time bounded, and monitored with the same logging and approval rigor as the primary sign-in path.

In practical terms, organisations should classify recovery options by risk and use the strongest available method first. A well-designed fallback may include:

• Recovery codes stored separately from the main device and protected like sensitive secrets.
• Secondary passkeys on an alternate device or platform, with explicit enrollment controls.
• Help desk recovery that requires identity proofing, manager approval, or out-of-band verification.
• Temporary access grants with short time-to-live and mandatory re-enrollment after use.
• Alerting on recovery events so unusual fallback use is reviewed quickly.

This is where policy matters as much as technology. Under NIST SP 800-53 Rev 5 Security and Privacy Controls, organisations can map recovery to authentication assurance, incident logging, and access enforcement rather than leaving it to support discretion. The same lifecycle logic appears in NHIMG’s Ultimate Guide to NHIs — Standards, which is useful because fallback in identity systems behaves like any other privileged exception: it must be governed, not merely enabled. These controls tend to break down when password resets, shared help desk scripts, or untracked exception approvals are used in high-volume consumer or contractor environments because operational convenience overtakes assurance.

Common Variations and Edge Cases

Tighter fallback controls often increase support burden, requiring organisations to balance recovery speed against abuse resistance. That tradeoff is especially visible where users depend on consumer cloud sync, shared workstations, or regulated contact centres. There is no universal standard for this yet, but current guidance suggests that the fallback path should never be easier to exploit than the passkey itself.

Edge cases matter. For example, high-assurance enterprises may prohibit SMS entirely because SIM swap risk is too high. Others allow SMS only as a last resort with a cooling-off period and additional verification. Some organisations use backup codes, but those codes become high-value secrets and must be stored offline or in a separate vault. In regulated environments, recovery may need fraud review, identity proofing, or documented exceptions before access is restored. NHI Management Group’s research on secrets exposure shows why this discipline matters: the Ultimate Guide to NHIs — Standards notes that weak lifecycle handling is a common failure mode across identity systems, not just machine accounts. For security teams, the practical rule is simple: if fallback is faster, easier, or less monitored than the passkey path, it is no longer a fallback, it is the attack path.

Related resources from NHI Mgmt Group

• Why do passkeys still need adaptive MFA in enterprise IAM programmes?
• Why do phone-based identity signals still need additional controls?
• What is the difference between human IAM controls and NHI governance?
• When does a short-lived API key still create material risk?