Passkeys matter because they remove the reusable secret from the primary sign-in path and sharply reduce phishing risk. Fallback still matters for recovery, but it should be designed as a controlled exception, not the default user experience. If fallback is too easy, the programme keeps the old attack surface alive under a modern label.
Why This Matters for Security Teams
Passkeys reduce the impact of phishing because the primary sign-in flow no longer depends on a reusable secret, but that security gain only holds if fallback is treated as a tightly governed exception. If recovery paths are easy, over-permissive, or poorly monitored, attackers simply shift from stealing the primary credential to abusing the weakest alternate path. That is why identity teams should judge passkeys as part of the whole authentication system, not as a standalone control.
This is especially important in environments that still rely on passwords, SMS, email recovery, or service desk override flows. Guidance in NIST SP 800-63 Digital Identity Guidelines emphasises that authentication assurance is not only about the factor used at sign-in, but also about how recovery and lifecycle processes preserve that assurance. NHI governance work makes the same point for machine and human-adjacent access: the Ultimate Guide to NHIs shows that 91.6% of secrets remain valid five days after notification, a sign that weak exception handling can keep an old attack surface alive long after a modern control is deployed.
Teams often assume the new factor changes the whole risk model, but in practice many incidents begin when the recovery path is easier to exploit than the primary login, rather than through the passkey itself.
How It Works in Practice
Operationally, the right design is to make passkeys the normal path and fallback a conditional, higher-friction path with stronger verification, logging, and review. That usually means step-up checks, helpdesk escrow rules, device binding, and explicit recovery expiry windows. The goal is not to eliminate fallback, but to make it narrow enough that it does not become the true primary path by habit.
Security teams should also distinguish between user convenience and recovery authority. A password reset, email-based unlock, or SMS code may be acceptable as a temporary exception in some low-risk environments, but current guidance suggests these channels should not silently restore the same level of trust as a passkey. This is where identity assurance, lifecycle control, and operational monitoring intersect. The NIST SP 800-63 Digital Identity Guidelines are useful for mapping assurance levels to recovery strength, while the Ultimate Guide to NHIs reinforces the broader lesson that credentials and secrets must be governed across their full lifecycle, not only at issuance.
- Use passkeys for the standard sign-in path.
- Require stronger verification for fallback than for everyday use.
- Limit who can approve recovery and record every override.
- Set short review windows for fallback enrolment and reset events.
- Monitor repeated fallback use as a signal of account abuse or poor adoption.
In mature programmes, fallback is also tested like an attack path: service desk scripts are reviewed, recovery tokens are time-bound, and suspicious resets trigger alerting or temporary access holds. These controls tend to break down when helpdesk processes are optimised for call speed and recovery approvals can be granted without strong identity proofing.
Common Variations and Edge Cases
Tighter fallback controls often increase support effort, so organisations have to balance user recovery speed against the risk of account takeover. That tradeoff is real, especially during passkey rollout, but best practice is evolving toward risk-based exception handling rather than broad recovery convenience.
Some environments cannot remove password fallback immediately because of legacy devices, shared workstations, regulated users, or business continuity requirements. In those cases, teams should isolate the exception rather than normalise it: restrict which users can use fallback, shorten reset lifetimes, and require additional evidence before restoring access. For higher-assurance services, NIST SP 800-63 Digital Identity Guidelines provide a useful basis for matching recovery strength to the required assurance outcome.
There is no universal standard for every fallback design yet, but the direction is clear. If passkeys are introduced while password reset, email recovery, or service desk override remains broad and untracked, the organisation has only moved the phishing target, not removed it. The Ultimate Guide to NHIs is a useful reminder that control quality matters most where exceptions accumulate, because that is where attackers look for the shortest path to valid access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-63 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Recovery assurance must match the sign-in assurance level. | |
| NIST CSF 2.0 | PR.AC-1 | Access control must cover recovery and exception paths, not just sign-in. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Fallback becomes a secret-handling weakness when passwords or reset tokens persist. |
Set fallback flows to preserve the intended assurance level and avoid weaker reset paths.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 4, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
