Account recovery when users lose their passkey
Passkey account recovery done right: synced passkeys, email recovery links, revoking old keys, and trade-offs that keep recovery from becoming a backdoor.
When a user loses their passkey, the safest recovery flow sends a short-lived, single-use link to their verified email address, has them create a new passkey on their current device, and revokes every old passkey on the account in the same step. Most users never get that far: synced passkeys from iCloud Keychain, Google Password Manager or 1Password come back automatically when they sign in to a new phone or laptop. Recovery is for the remaining case, where every device holding the passkey is gone, reset or inaccessible.
Recovery is also the part of a passkey system attackers will aim for, since everyday sign-in is phishing-resistant. So it deserves as much design attention as sign-in itself.
How often users actually lose passkeys
Less often than with passwords, mostly because of how passkeys are stored:
| Situation | What happens |
|---|---|
| New phone, same Apple or Google account | Synced passkeys restore with the account. No recovery needed. |
| Uses 1Password or another cross-platform manager | Passkeys follow the vault. No recovery needed. |
| Signs in on a laptop with a phone’s passkey | Works through the QR-code cross-device flow. No recovery needed. |
| Device-bound passkey only (a single security key or non-synced authenticator) and it’s lost | Recovery needed. |
| Phone lost or stolen, and the user can’t get into their Apple or Google account | Recovery needed. |
| Passkey deleted from the password manager by mistake | Recovery needed. |
Your design goal is to make the last three cases safe and short, without creating a path that bypasses passkeys for everyone else.
The recovery options
Email recovery link
Send a link to the account’s verified email address. Clicking it lets the user enroll a new passkey.
- Pros: every user already has it, nothing extra to set up, works on any device.
- Cons: security is bounded by the email account. Anyone who controls the inbox can recover.
For consumer and most SaaS apps, this is the pragmatic default, provided the link is short-lived, single use and does something meaningful to old credentials.
SMS recovery
Text a code to a phone number on file.
- Cons: SIM swapping, number recycling, real-time phishing and per-message cost. It reintroduces the exact weaknesses passkeys remove. We’d avoid it. See passkeys vs passwords, SMS codes and magic links.
Recovery codes
Show the user a set of one-time codes at signup and ask them to store them.
- Pros: doesn’t depend on email.
- Cons: most consumers lose them or never save them. They’re also phishable bearer secrets.
They can make sense for high-assurance or enterprise accounts, alongside other options.
Multiple passkeys
Encourage users to have more than one passkey: a synced one plus a security key, or passkeys in two different ecosystems.
- Pros: prevents the need for recovery in the first place.
- Cons: relies on users doing something extra in advance.
Manual identity verification
Support staff check identity documents or account history.
- Cons: slow, expensive, and support agents are a classic social-engineering target. Reserve it for exceptional cases.
Design rules for a safe recovery flow
Whichever channel you choose, the same rules apply.
- Short expiry. Minutes, not days. A link that lingers in an inbox is a liability.
- Single use. Once the link is opened and acted on, it’s dead. Store only a hash of the token so a database leak doesn’t expose live links.
- Require a deliberate action. Opening the link should show a confirm step, not complete recovery on page load. Email security scanners prefetch links.
- Revoke old credentials. If recovery adds a new passkey but leaves the old ones active, a thief holding the lost phone keeps access. Recovery should replace, not add.
- End existing sessions. Treat recovery as a reset of the account’s authentication state.
- Rate-limit requests. Limit recovery emails per address and per IP to prevent mailbombing and enumeration.
- Don’t reveal whether an account exists. Show the same “check your email” message either way.
- Notify the user. Tell them, through the same email, that recovery happened, so they notice if it wasn’t them.
Why recovery shouldn’t double as login
It’s tempting to let users “sign in with email” whenever their passkey isn’t handy. Don’t. If an email link can sign someone in on any day, then your sign-in is only as phishing-resistant as email, and attackers will steer users to that path. Keep recovery clearly separate:
- A distinct “Lost your passkey?” entry point, not a “sign in with email” option.
- Every recovery ends with a new passkey enrolled.
- Recovery revokes old credentials, which makes it costly to use casually.
That friction is a feature. It keeps recovery for genuine loss. Our post on why passkeys stop phishing explains why fallback paths matter so much.
Telling users what to expect
Good recovery starts at signup. A sentence or two goes a long way:
- “Your passkey is saved in your password manager and will come with you to new devices.”
- “If you lose every device, you can recover by email. Recovery replaces your old passkeys.”
Linking to a help page like Gatekeep’s lost passkey guide answers most support questions before they’re asked.
How Gatekeep handles recovery
Gatekeep builds recovery around the same ideas. Email links are used only for signup and recovery, never for everyday sign-in. A recovery link expires after 10 minutes and works once, and like every bearer secret in Gatekeep it’s stored only as a SHA-256 hash. The user confirms on the page, creates a new passkey on their current device, and completing recovery revokes every existing passkey on the account. Recovery requests are rate-limited per address and per IP, and the response is the same whether or not an address has an account.
Synced passkeys from iCloud Keychain, Google Password Manager and 1Password are fully supported, so most users never need recovery at all. See the security model, creating an account, and request early access.