Security
Passkey Account Recovery: Planning for Lost Devices
Design passkey recovery that handles lost devices without recreating a weak password or support-desk takeover path.
In this article
Passkey Account Recovery: Planning for Lost Devices
Passkeys resist phishing because authentication uses a private key tied to the legitimate site rather than a reusable secret. Recovery is where many deployments give that advantage back. A good design distinguishes synced passkeys, device-bound credentials, recovery contacts, administrative recovery, and deliberate account closure.
The practical model
Treat passkey account recovery: planning for lost devices as a system with four review points: inventory credential paths, use step-up for dangerous changes, make support resistant to persuasion, test the lost-everything scenario. Give each point an owner, a measurable acceptance condition, and a rollback trigger. Thresholds should come from observed workloads, contracts, or risk tolerance rather than an unexplained default.
Inventory credential paths
Show users which authenticators are registered, when they were added, and whether they are synced or hardware-bound when the platform exposes that distinction. Encourage two independent paths, such as a synced passkey plus a hardware key. Do not present “this phone” as the only recovery plan.
Use step-up for dangerous changes
Adding or removing a passkey, changing recovery addresses, exporting data, and disabling security controls should require a recent strong authentication. Notify existing channels and impose a delay on high-risk recovery changes so an account owner has time to react.
Make support resistant to persuasion
Support staff should not be able to replace a passkey after seeing a photo of an ID or answering biographical questions. Use a documented, auditable recovery policy with multiple signals, cooling-off periods, limited operator permissions, and escalation. For high-value accounts, allow recovery to be intentionally difficult.
Test the lost-everything scenario
Walk through a lost phone, inaccessible cloud account, changed number, unavailable security key, deceased administrator, and departing employee. Business accounts need multiple administrators and break-glass credentials stored separately. Recovery events should revoke active sessions selectively and trigger a security review.
Common pitfalls
- Keeping password reset as an invisible weaker fallback.
- Letting one logged-in session delete every other credential immediately.
- Using SMS alone for high-value recovery.
- Failing to explain that deleting a local passkey may not delete a synced copy.
A focused test plan
- Inventory credential paths: verify that show users which authenticators are registered, when they were added, and whether they are synced or hardware-bound when the platform exposes that distinction. Then introduce the failure case “keeping password reset as an invisible weaker fallback” and confirm that the system fails visibly, stays within its safety boundary, and has a documented recovery action.
- Use step-up for dangerous changes: verify that adding or removing a passkey, changing recovery addresses, exporting data, and disabling security controls should require a recent strong authentication. Then introduce the failure case “letting one logged-in session delete every other credential immediately” and confirm that the system fails visibly, stays within its safety boundary, and has a documented recovery action.
- Make support resistant to persuasion: verify that support staff should not be able to replace a passkey after seeing a photo of an ID or answering biographical questions. Then introduce the failure case “using sms alone for high-value recovery” and confirm that the system fails visibly, stays within its safety boundary, and has a documented recovery action.
- Test the lost-everything scenario: verify that walk through a lost phone, inaccessible cloud account, changed number, unavailable security key, deceased administrator, and departing employee. Then introduce the failure case “failing to explain that deleting a local passkey may not delete a synced copy” and confirm that the system fails visibly, stays within its safety boundary, and has a documented recovery action.
Primary references
Conclusion
Passkeys improve the front door, but recovery defines the real assurance level. Give users independent credentials, protect credential changes with step-up and delay, and make exceptional recovery auditable.