Losing a device does not have to break access if the programme is designed correctly. Users can recover through backup authentication, cloud synchronisation, or re-registration after verifying their identity again. Cross-platform friction is real, but it is operational, not fatal. The key is to plan for recovery before passkeys become the only way in.
When a passkey user loses a device
Passkeys are not meant to behave like a single point of failure. A well-designed programme assumes devices will be lost, replaced, or wiped, and it keeps recovery paths available through a second registered device, cloud-synced credentials, or a fresh registration flow after the user re-verifies identity. The security question is whether recovery is controlled, not whether recovery exists.
That is why recovery design matters as much as initial enrolment. If the only way back in is a help desk reset with weak identity checks, the convenience of passkeys turns into a support and fraud problem. If recovery is tied to strong identity proofing and step-up verification, the loss of one device becomes an inconvenience rather than an outage.
Why moving between platforms is usually a usability problem, not an account-loss event
Cross-platform movement can feel awkward because passkeys live inside platform ecosystems and authenticators do not always move with equal ease. That creates friction when someone switches phone platforms, changes browsers, or uses a work device and a personal device interchangeably. The result is usually a re-enrolment or sync issue, not a security failure.
The practical distinction is between portability and recoverability. Users may need to register a new authenticator, approve a sync path, or re-bind the account to the new device. If the organisation has planned for that transition, the user keeps access with minimal interruption. If it has not, the user may fall back to weaker recovery methods or pressure support teams into exceptions.
Where this becomes important is policy. Organisations should decide in advance whether they support platform-bound passkeys, cloud-synced passkeys, or both, because each choice changes the user journey and the recovery controls needed around it. The more diverse the device estate, the more deliberate the re-registration process has to be.
How to avoid turning passkey recovery into the weakest link
Passkeys reduce phishing exposure only if the surrounding lifecycle is disciplined. Recovery, reset, and re-enrolment are the moments when attackers often look for shortcuts, because those paths can bypass the strength of the authenticator itself. A sound programme therefore treats account recovery as part of authentication design, not as an admin afterthought.
That means the recovery path should be harder to abuse than the login path is to protect. If a lost-device workflow can be triggered with easily guessed information, weak support scripts, or inconsistent identity checks, the organisation has simply moved the risk from passwords to process. If the recovery path is too rigid, users will create shadow procedures or avoid adoption altogether.
Risk and Threat Considerations
Loss and migration are the two moments when passkey deployments are most likely to fail operationally. The risk is not that passkeys stop working by design, but that organisations underbuild recovery and then push users toward insecure backup channels or help desk exceptions.
Failure mechanism: Weak re-verification, excessive reliance on support staff, or poorly governed device sync can let an attacker exploit recovery instead of the passkey itself, especially after a device loss or platform change.
Impact: The result can be account takeover, support fraud, unnecessary lockouts, or pressure to reintroduce passwords and SMS as emergency fallbacks.
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 addresses the attack and risk surface, while NIST SP 800-63, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Passkey recovery and phishing-resistant authentication are central to digital identity assurance. |
| Recommendation — Use phishing-resistant authenticators and recovery rules that preserve assurance during re-registration. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Lost-device recovery and passkey re-enrolment depend on controlled authenticator lifecycle management. |
| Recommendation — Manage authenticators across issuance, recovery, rotation, and revocation. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account recovery, re-enrolment, and device replacement are account lifecycle concerns. |
| Recommendation — Enforce account lifecycle controls that keep recovery paths governed and auditable. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Lost-device and replacement flows depend on timely removal and replacement of old authenticators. |
| NHI-07 — Long-Lived Secrets | Passkey ecosystems still need controlled recovery paths that do not rely on stale fallback credentials. | |
| Recommendation — Remove obsolete authenticators and revoke access when a device is lost or replaced. Eliminate long-lived fallback secrets that undermine passkey recovery. | ||
Practitioner Guidance
What to verify: Before declaring passkeys production-ready, verify that a lost device can be recovered through at least one strong, documented path that does not depend on ad hoc human judgement. Test the full journey, including device replacement, browser change, and cross-platform migration.
Decision rule: If recovery requires support intervention, require the same identity standard you would trust for an account takeover reset, not a lighter standard chosen for convenience.
Common mistake: Treating passkey rollout as an enrolment project only. The real control question is whether the programme can survive device churn without creating a weaker back door.
Practitioner takeaway: Passkeys remove password risk, but they do not remove lifecycle risk, so the design target is resilient recovery with strong re-verification, not perfect device permanence.
Related resources from NHI Mgmt Group
- What happens if users lose access to their second-factor device and have no recovery process?
- How should organisations plan passkey migration when users need to move credentials between platforms and password managers?
- What is the difference between runtime protection and NHI lifecycle management?
- What is the difference between rotating a secret and revoking access?
