Fallback methods create risk because attackers target the weakest available route, not the strongest one. If SMS, push, QR fallback, or weak recovery still exists, the attacker can steer the user into that path and defeat the stronger factor indirectly. A passkey deployment is only as resistant as its recovery and fallback design.
Why This Matters for Security Teams
Fallback paths are not a minor implementation detail. They define the real attack surface after passkeys are introduced, because an attacker only needs one weaker route to bypass the stronger factor. If recovery still depends on SMS, push approvals, email resets, or helpdesk verification, the organisation has preserved a parallel authentication system with weaker assurance. That is why passkey projects often reduce risk on paper but leave account takeover exposure in practice. The baseline in NIST SP 800-63 Digital Identity Guidelines is clear that authentication assurance is only as strong as the enrolled authenticator and recovery process, not the best factor in the stack.
This is the same pattern seen in wider identity security failures: attackers do not fight the strongest control first, they route around it. NHIMG research on Ultimate Guide to NHIs — Key Challenges and Risks shows how weak lifecycle controls and excessive access create persistent exposure, and the lesson transfers cleanly to human authentication. If the fallback is easier than the passkey, it becomes the path of least resistance. In practice, many security teams encounter passkey failure only after a recovery abuse event has already occurred, rather than through intentional testing.
How It Works in Practice
After rollout, the safest design is to treat fallback and recovery as high-assurance controls, not convenience features. That means mapping every path a user can take after losing a device, failing a biometric check, or getting locked out. Good practice is to reduce the number of recovery routes, require step-up verification for any reset, and make the fallback assurance level visible to risk owners. NIST Cybersecurity Framework 2.0 supports this by pushing organisations to manage identity risk as part of broader access governance, not as a one-time login control.
Operationally, teams should ask three questions: who can trigger recovery, what evidence is required, and how quickly can the old factor be revoked. A fallback path that sends a one-time code over SMS may still be acceptable in a low-risk consumer context, but it is a poor choice for privileged users, finance admins, or support staff with production access. NHIMG guidance in Top 10 NHI Issues reinforces the broader principle that ungoverned identity paths become attack multipliers when they remain valid for too long. One relevant data point from Ultimate Guide to NHIs — Why NHI Security Matters Now is that 91.6% of secrets remain valid five days after notification, which illustrates how delay and leftover access amplify compromise conditions.
- Prefer phishing-resistant recovery methods over SMS or email resets.
- Require JIT approval or delegated admin review for high-risk account recovery.
- Revoke old authenticators immediately after a recovery event.
- Log and alert on repeated recovery attempts, even when they fail.
These controls tend to break down in large helpdesk-led environments because support staff are pressured to restore access quickly and attackers exploit that urgency.
Common Variations and Edge Cases
Tighter recovery controls often increase support overhead, so organisations have to balance user friction against the cost of account takeover. There is no universal standard for fallback design yet, and current guidance suggests using the strongest practical recovery method for the user population rather than applying one policy everywhere. That distinction matters because consumer services, internal enterprise apps, and privileged admin portals have very different risk tolerances.
One common edge case is legacy identity infrastructure. If a passkey is added on top of older MFA, the organisation may keep SMS or push as a silent backup “just in case,” which usually undermines the security gain. Another case is shared or delegated access, where teams assume one trusted operator can always reset another user. That can be acceptable for low-risk accounts, but it should be explicit, audited, and limited for sensitive roles. For maturity planning, the best way to frame the issue is through Oasis Security & ESG data showing that 72% of organisations have experienced or suspect a non-human identity breach, which underscores how often hidden identity paths matter in real environments. The same operational lesson applies here: backup routes are not neutral, they are attack surfaces.
Teams that want a durable passkey rollout should review recovery flows as carefully as primary login flows, and align them to risk-based access policy rather than convenience alone.
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 | Defines assurance expectations for authenticators and recovery flows. | |
| NIST CSF 2.0 | PR.AA-1 | Identity proofing and authentication governance cover fallback risk. |
| OWASP Non-Human Identity Top 10 | NHI-04 | Weak lifecycle and recovery paths create persistent identity exposure. |
Treat recovery as part of the authenticator assurance model and reject weak fallback paths for sensitive users.
