Identify where the passkey was stored, recover through an existing supported route, then replace and retire credentials deliberately.
Losing a device does not always mean losing its passkeys, but recovery depends on where each credential was kept and which alternatives were already available. Distinguish a passkey synchronized through a credential provider from one bound to a particular device or security key. Then use another available credential or the website’s supported recovery process. Installing the same app on a new phone is not sufficient evidence that access has returned.
There are two accounts to think about: the website you want to enter and the provider that stores or synchronizes your passkeys. Recovering one does not automatically recover the other. This guide addresses that post-loss decision; the broader account protection and recovery guide covers preparation.
Identify the missing dependency
Write down the affected website, account identifier, passkey provider, lost device and any other enrolled method. Keep this inventory free of passwords, recovery codes and private credential material. If you still have a trusted session, use it to review security settings, but do not assume an open session will authorize every sensitive change.
FIDO distinguishes synced and device-bound passkeys. A synced credential can be available through the same provider on another compatible device; a device-bound credential remains with its device or key. The biometric gesture or PIN unlocks local use. Your fingerprint is not a backup that recreates a missing private key.
Check where the particular credential was created, rather than guessing from the device brand. One phone can contain credentials managed by different providers. A spare computer may have its own separately enrolled passkey, a synced copy, or no usable credential for this website.
| What remains available? | First supported route to check | What it does not prove |
|---|---|---|
| Another device with the synced credential | Fresh sign-in using that provider and account | That every website credential synchronized |
| A separately enrolled security key | The website’s security-key sign-in option | That an unenrolled replacement key will work |
| Another accepted recovery method | The website’s documented alternative | That a password bypasses additional protections |
| No remaining credential or recovery proof | Official recovery or organizational administrator | That support can restore access |
A fictional loss scenario: three websites, three outcomes
Consider a fictional publisher who loses a phone. Its registrar passkey was synchronized to a credential provider also accessible from a trusted laptop. Its membership-service passkey was device-bound. Its hosting account has a separately enrolled hardware key stored elsewhere. These are illustrative arrangements, not tested accounts.
For the registrar, the publisher checks a fresh sign-in from the laptop and confirms the correct account and role. For hosting, the publisher uses the enrolled hardware key. For the membership service, the publisher follows that service’s remaining documented recovery route. None of those successes establishes the other two.
Now change one fact: the credential provider itself requires approval from the missing phone, and no independent recovery option remains. The registrar route is no longer demonstrably available. Map the dependency before relying on the word synchronized, rather than repeatedly recreating the same inaccessible setup.
Recover the provider and the website separately
Use an independently known official address for the credential provider. Read its replacement-device and recovery instructions for the actual account type. Personal accounts, organization-managed accounts and hardware credentials can have different controls. Avoid deleting a synchronized vault, resetting encrypted data or removing the last working device while establishing what is recoverable.
After provider access returns, confirm the intended website credential is available. Complete one fresh sign-in in a separate signed-out context on a trusted device. Verify account identity and useful access, not merely that the credential picker displayed a familiar label.
NIST describes account recovery as a distinct process involving supported recovery methods followed by binding replacement authenticators. That is an architectural distinction, not a promise that every website accepts the same proof. Follow the relying party’s policy rather than asking someone to waive its checks.
If the device was stolen, contain access too
A broken phone at home and an unlocked phone in someone else’s possession are different situations. From a trusted route, review the lost device, active sessions, recent changes and credentials associated with it. Use supported lost-device controls where available. Record actions and unresolved access without exposing secret values.
Google documents removing a passkey on a lost or stolen device after signing in on another accessible device. This is a Google Account example. Another website may require deleting its registered credential, managing the sync provider, ending sessions, or several separate actions. Removing one entry should not be described as universally wiping every synced copy or ending every existing session.
If account control is uncertain, use the provider’s compromised-account route. Do not trust newly changed recovery details merely because they appear in settings. Preserve relevant notifications privately and identify which changes were yours.
Replace access before retiring the remaining route
- Confirm the website, correct account and a currently working supported sign-in.
- Add the replacement credential through official settings, reauthenticating as required.
- Verify a fresh sign-in on the intended replacement device.
- Remove the lost or retired credential according to the provider’s documented meaning.
- Check sessions and recovery details separately, recording any unverified boundary.
For administration, recovery email deserves its own check. The business email recovery guide explains the mailbox dependency. If recovery instructions are kept in an encrypted backup, the backup-key planning guide addresses the separate requirement to unlock that copy.
Your next step is a loss rehearsal that preserves a working method: assume one named device is unavailable and identify the route that remains. Record which fresh sign-in you checked and which recovery behavior remains documentation-only. A useful plan ends with an independent route you can reach, not simply a list of devices you own.
When a passkey appears but the account still refuses it
A credential picker entry is a useful lead, not proof that the website still accepts that registration. The entry could belong to another account, an old hostname or a credential the website already removed. Compare the account identifier and official service route before deleting local data or repeatedly creating replacements.
Keep the two inventories distinct: the provider’s stored credential and the website’s registered authentication method. Their labels need not be identical. Ask official support for the appropriate redacted account reference if those inventories disagree; do not send a vault export or any private key material.
For organizational accounts, establish whether an administrator revoked access independently of device loss. Recovery of a perfectly valid credential cannot restore an employment role or membership that no longer exists. The acceptance check must therefore confirm both successful authentication and the intended authorized role.
Sources and verification
Editorial review 2026-10-17. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- FIDO Alliance: PasskeysChecked Synced versus device-bound passkeys and local credential use.
Limits: General architecture; individual services control enrollment and recovery. - NIST SP800-63B-4: Account recoveryChecked Account recovery, replacement authenticator binding and notifications.
Limits: Normative assurance guidance is not a recovery promise from every website. - Google Account: Sign in with a passkeyChecked Google-specific lost-device passkey removal and alternative sign-in.
Limits: Google Account policy only; sync-provider and relying-party recovery are separate.