They assume a lost device means permanent lockout. In enterprise deployments, passkey recovery should be an intentional workflow with secondary authenticators, backup codes, or help desk-verified re-enrolment. If those paths are weak, the recovery process becomes the real attack surface, not the passkey itself.
Why This Matters for Security Teams
Security teams often treat passkeys as if they eliminate recovery risk, but device loss changes the problem, not the need for control. A lost phone or laptop should not become a permanent lockout, yet recovery must still prove identity strongly enough to resist social engineering. That means designing secondary authenticators, backup codes, and help desk workflows that are harder to abuse than the original sign-in path. The same discipline that applies to NHI lifecycle management in the Ultimate Guide to NHIs also applies here: authentication is only as strong as the enrolment, recovery, and revocation process around it.
Current guidance also aligns with broader identity risk management in the NIST Cybersecurity Framework 2.0, which emphasises governed recovery and access control rather than assuming a single credential type can solve every failure mode. The common mistake is to focus on whether the passkey can be phished, while ignoring whether an attacker can convincingly claim a lost device and walk through a weak reset path. In practice, many security teams encounter passkey “failures” only after an account takeover, rather than through intentional recovery design.
How It Works in Practice
Good passkey recovery starts with policy, not tooling. Teams need to define which recovery paths are allowed, who can approve them, what evidence is required, and how quickly access is restored. A mature design usually includes more than one option: a second enrolled device, pre-generated backup codes stored safely, or help desk-verified re-enrolment with step-up checks. The point is to avoid making the lost device itself the only trust anchor.
For higher-risk environments, best practice is to treat recovery as a privileged action. That means logging every step, using separation of duties where possible, and making sure help desk staff can verify identity without relying on easily spoofed signals. The recovery process should also trigger revocation of the old device key, because a lost device may later reappear in hostile hands. NHI governance guidance in the Ultimate Guide to NHIs is useful here because it frames identity as a lifecycle, including enrolment, rotation, and offboarding.
- Use at least one independent recovery factor, not just the lost device.
- Require step-up verification for help desk resets.
- Revoke the old passkey or device binding immediately after recovery.
- Monitor for repeated recovery attempts as an abuse signal.
Control design should map to established identity and Zero Trust principles in the NIST Cybersecurity Framework 2.0 and NIST Cybersecurity Framework 2.0 guidance on protection and recovery. These controls tend to break down when help desk processes are outsourced and agents lack consistent proofing standards because the attacker targets the weakest human-approved exception path.
Common Variations and Edge Cases
Tighter recovery controls often increase support overhead, so organisations must balance user continuity against fraud resistance. That tradeoff is especially visible when employees travel, lose both device and backup factor, or work in regulated environments where identity proofing is costly. There is no universal standard for recovery timing yet, but current guidance suggests the best designs are role-aware and risk-based rather than one-size-fits-all.
Some teams allow self-service recovery with email links or SMS, but that can weaken the point of using passkeys in the first place if those channels are easier to compromise. Others require in-person proofing for high-privilege accounts, which improves assurance but can delay business operations. For privileged users, tying recovery to PAM and strong identity proofing is usually safer than broad exception handling. NIST’s Zero Trust thinking, reflected in the NIST Cybersecurity Framework 2.0, supports this kind of context-aware access control.
The key lesson is that passkeys are not fragile, but recovery can be. Organisations that document recovery as an operational control, test it, and review it like any other access path usually avoid the worst surprises. Teams that improvise during a device-loss event often discover that the recovery channel was the real security gap all along.
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 CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 | Recovery and revocation are part of the NHI lifecycle, like passkey enrolment and offboarding. |
| NIST CSF 2.0 | PR.AA-2 | Identity verification and authenticated recovery fit CSF access control and recovery expectations. |
| NIST Zero Trust (SP 800-207) | AC-6 | Least privilege and strong recovery boundaries reduce abuse of help desk and reset pathways. |
Treat passkey recovery as a controlled authentication workflow with logging, approvals, and revocation.
