Designing passkey account recovery for users who lose their device

Passkey account recovery is the flow in which a user who can no longer use their passkey proves who they are some other way and registers a new one. Design it in three layers: (1) help users avoid losing access, (2) give them a way to recover on their own, and (3) verify the rest at your support desk. Recovery gets attacked as much as sign-in does, so if recovery is weaker than sign-in, your overall security drops to the level of recovery. After recovery, notify the user and revoke the lost device's passkey.

Why recovery is hard

Passkey sign-in fails without the device that holds the private key. That's exactly why it's secure, and it also locks out the owner when the device is gone.

So you check identity another way, and attackers target that way too. Suppose sign-in accepts only passkeys, but a link in an email lets anyone register a new passkey. An attacker then needs only the user's mailbox to add their own passkey, and the phishing resistance you gained is gone.

When designing recovery, ask two questions: "Can only the real user get through this?" and "Is it in proportion to the strength we require at sign-in?"

Layer 1: help users avoid losing access

Reducing how often recovery is needed has the biggest payoff.

Encourage synced passkeys

Synced passkeys reach the user's other devices through the OS or a password manager's cloud. Apple says passkeys synced with iCloud Keychain are designed to be recoverable even if the user loses all their devices. Google says Google Password Manager syncs passkeys between Android devices and Chrome. Losing one device then still leaves another that can sign in.

Suggest a second passkey

WebAuthn authenticator data includes flags for whether a passkey can be synced (BE, Backup Eligibility) and whether it is currently backed up (BS, Backup State). If none of a user's passkeys are backed up, suggest registering a second one on another device or a security key. NIST SP 800-63B-4 likewise points to multiple independent authenticators as a way to recover from losing one.

Layer 2: self-service recovery

NIST SP 800-63B-4 lists account recovery methods such as these:

When one method isn't enough, combine them. For example, a code sent to the registered email plus "the request comes from a recently used device" or "part of the payment details matches" means a mailbox takeover alone won't get an attacker through. The right mix depends on how sensitive your data and transactions are.

Layer 3: support-desk verification

Users who can't recover on their own go to your support desk. Attackers target this too, so write the procedure down rather than relying on individual judgment.

• Decide in advance what you will check (enrollment details, transaction history, identity documents, and so on)
• Instead of "removing the passkey requirement," grant a short-lived right to register a new passkey
• Record who approved the recovery, when, and why

After recovery

Notify the user

NIST SP 800-63B-4 requires sending a notification when recovery happens. If someone recovers an account without the owner knowing, this is how the owner finds out. Send it to every address on file.

Revoke the lost device's passkey

A passkey on a lost device can't be used unless the finder can unlock the device, but there's no reason to keep it. Show each passkey's name and last-used date in the device list so users can pick the lost one and revoke it. If takeover is suspected, revoke all passkeys and have the user register again.

Review sessions

Decide whether to end sessions that were active at recovery time. If recovery followed a suspected takeover, end them all.

Decide before launch

1. What is the self-service method, and is it in proportion to sign-in?
2. What does the support desk check, who approves, and where is it recorded?
3. Who gets notified after recovery, and how?
4. Do you revoke one passkey or all of them?

Implementing with SealGate

SealGate does not verify identity. You verify the user on your side, then use SealGate's API to grant the right to register again.

# 1. After verifying the user's identity on your side, issue a recovery token
curl -X POST https://api.sealgate.jp/v1/recovery/start \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{"external_id":"user-123","reason":"Verified by support"}'
# → { "recovery_token": "rt_...", "expires_at": "..." }  (valid for 15 minutes)

2. When your server requests registration options for that user, it adds recovery_token to POST /v1/register/options. In the browser, it's the usual sg.register() from the SDK.
3. A user who already has a passkey can't register another without signed_in: true or a recovery_token (403 recovery_not_allowed). The same error comes back for an invalid or expired recovery token.

APIs that help before and after recovery:

• GET /v1/users/{external_id}/credentials lists passkeys with name, last_used_at, backup_eligible, and backed_up, which helps identify the lost device and decide when to suggest a second passkey.
• DELETE /v1/credentials/{credential_id} revokes the lost device's passkey.
• POST /v1/users/{external_id}/revoke revokes all of the user's passkeys when takeover is suspected (the user and the audit log are kept).
• The recovery.issued webhook tells you when a recovery token is issued, which you can use to trigger the user notification. The reason is kept in the audit log.

See the recovery section of the docs for details.

FAQ

If users have synced passkeys, do we still need recovery?

Yes. Some users don't use sync, some have only device-bound passkeys, and some lose access to the sync account itself.

Is an email link enough for recovery?

If the mailbox is taken over, so is recovery. For services that handle sensitive data, combine email with another factor or require a support-desk check.

Do old passkeys disappear after recovery?

Design as if they don't, and make sure the user or your operators can revoke the lost device's passkey.

Sources

• NIST SP 800-63B-4 Digital Identity Guidelines: Authentication and Authenticator Management (NIST, August 2025)
• Web Authentication: An API for accessing Public Key Credentials Level 3 (W3C Recommendation, 2026-08-25)
• About the security of passkeys (Apple)
• Passkeys (Google for Developers)