Passkeys explained: what happens if you lose your phone?
What happens to your passkeys when a phone goes missing? Understand syncing, recovery and spare sign-in methods, then check your setup before you need it.
You reach for your phone to approve a sign-in, then remember it is missing. If that phone held your passkeys, have you also lost access to your accounts?
Losing your phone does not automatically mean losing your accounts. A synced passkey may already be available on another device, or recoverable through its provider. A separately registered passkey or security key can give you another way in. If neither is available, the website's own account-recovery process becomes important.
The useful question is: what can you use to sign in when this particular phone is unavailable? The FIDO Alliance's overview makes the underlying distinction clear: some passkeys can sync; others stay on one device.
This guide covers personal accounts and passkey options available as of 16 January 2024. Work and school accounts can have different rules.
What a passkey actually does
A passkey lets you sign in without typing a password. Your device or credential manager holds a private cryptographic key; the website keeps the corresponding public key. During sign-in, the device signs a challenge, and the website checks the response. The website does not receive the private key.
Your fingerprint, face scan or device PIN authorises that action locally. Your fingerprint does not become a password sent to the website. The W3C's WebAuthn standard describes this public-key mechanism and explicitly keeps biometric verification local.
Passkeys also belong to the service they were registered for. That gives them an important advantage over a password you could accidentally type into a convincing imitation website: the credential is scoped to the real service. FIDO describes this as phishing-resistant authentication .
That protection still leaves a practical question: where is the credential stored, and how will you reach it after a device disappears?
Check where your passkey is stored
The word “passkey” describes the sign-in credential. It does not promise one universal backup system. The place you saved it determines much of the recovery plan.
Storage affects the recovery options available after device loss. Original Jitsumi diagram.
Synced passkeys can survive a lost device
A synced passkey can be made available on other supported devices through a passkey provider. Apple's iCloud Keychain is one example; Google Password Manager on Android is another. Their documented implementations use end-to-end encryption for synchronisation.
Apple's WWDC22 explanation shows a passkey saved in iCloud Keychain becoming available across compatible Apple devices. Google's Android security explanation describes passkeys being available on Android devices using the same Google Account.
Check the provider and its supported devices. “Synced” does not mean that every browser, operating system and password manager automatically has a copy.
Device-bound passkeys need a separate fallback
A device-bound passkey stays with its authenticator: the device that stores and uses it. That might be a computer or a physical security key. If the authenticator is lost or damaged, you cannot simply download that credential onto a replacement.
FIDO recommends registering a second authenticator in advance . The spare needs its own registration with the relevant account. Buying another security key after losing the first does not recreate what was on it.
For PC users, FIDO's May 2023 announcement identifies Windows Hello passkeys on Windows 10 and 11 as device-bound. Microsoft's September 2023 Windows 11 announcement added a more integrated passkey experience. A passkey saved locally with Windows Hello and one synced through a phone's provider have different backup arrangements.
Signing in on a PC with your phone does not create a backup
You may have used a phone's passkey to sign in on a computer by scanning a QR code. That does not necessarily mean the computer now holds the passkey.
Google's 2023 explanation of cross-device sign-in explicitly distinguishes authorising a sign-in from transferring the credential. The phone approves the sign-in; creating a passkey on the computer is a separate action.
This is an easy distinction to miss. A laptop that successfully opened your account yesterday might ask for the missing phone again tomorrow. An existing signed-in session also does not demonstrate that you can complete a fresh sign-in.
Before counting a computer as your backup, check which credential it actually uses.
Recovering the passkey and recovering the account are different
There are two recovery routes to understand.
Passkey recovery goes through the provider that stores your synced credentials. If you satisfy that provider's recovery checks, you may regain access to the existing passkey on a supported device.
Account recovery goes through the website or app you want to use. That service might verify you through another method and let you register a new passkey. The original credential need not be recovered for this to work.
Apple's May 2023 developer Q&A explains that account recovery is separate from the authentication mechanism. It gives an email link for creating a new passkey as one possible approach. That is an option a service can implement, not a guarantee that every website offers it.
Restoring a credential and regaining an account take different routes. Original Jitsumi diagram.
For example, imagine a shopping account whose only passkey was on your lost phone. If the shop can verify you through its recovery process, you might regain the account even when the passkey provider cannot restore the credential. If that process sends a message to an email account you also cannot access, you have another dependency to resolve.
This is why a recovery plan should name the actual route. “It is in the cloud” is not enough information to act on when you need to sign in.
An Android example: the account password may not be enough
Suppose a lost Android phone held a website's passkey in Google Password Manager.
Google's published recovery design requires both access to the Google Account and the remembered screen-lock PIN, password or pattern of a device that already held the encryption keys. That can be the missing phone. Signing into the account alone is not the whole documented process.
Check how you would access the Google Account without that phone, and retain the device's screen-lock information securely. Either can become a recovery dependency.
Google limits incorrect screen-lock recovery attempts. Follow its recovery instructions if you cannot supply the requested information; avoid repeated guessing.
These requirements describe Google's Android implementation. Other providers have their own recovery processes.
Set up another way in while you still have the phone
Start with the accounts that would cause the biggest disruption: your primary email, the account behind your passkey provider, and any service you would struggle to replace.
For each one, write down the account name, where its passkey is stored and the alternative sign-in method you have actually checked. Keep secret recovery material separately and securely; this small inventory only needs to identify your options.
| What you have available | What to check before relying on it |
|---|---|
| Another device with synced passkeys | Can it complete a new sign-in without asking for the phone? |
| A separate passkey on your own computer | Was it registered with this particular account, and can you use it independently? |
| A spare physical security key | Is it registered, usable with your devices and stored separately from the phone? |
| The website's recovery method | Can you reach the required email, codes or other proof without the phone? |
These checks apply the distinction between provider recovery and service recovery in FIDO's June 2023 overview . Available methods depend on the account; you do not need every option in the table.
Try signing in without using your phone
Test an already configured alternative sign-in method. Leave password resets and account-recovery requests out of this rehearsal:
- Keep a working session open on a trusted device. Leave existing passkeys and recovery settings intact.
- Put the phone aside. Do not approve a prompt, scan a sign-in QR code or retrieve a verification code from it during the test.
- Start a fresh sign-in in a separate browser session on another trusted device. Use a browser where your chosen passkey provider is supported, and deliberately select the backup method.
- Check the result. Confirm that you reached the correct account without needing the phone. If a phone prompt appears, look for the intended alternative; do not delete working credentials to force the test.
- Record what worked. If no independent route worked, set one up using the service's instructions before relying on this arrangement.
This rehearsal checks the sign-in route you used. It does not prove that a future provider recovery request will succeed, or that every other account has the same setup.
The distinction matters when you store several recovery options on one phone. A passkey, an authenticator app and a screenshot of a recovery code can all become unavailable together. Consider what remains accessible if the whole device is gone.
If the phone is already missing
Use a trusted device and go directly to the relevant account or provider. Work through the routes you already have: another usable passkey, a registered security key, provider recovery or the website's account-recovery process. Avoid signing out of your remaining working sessions while you investigate.
Protect the missing device as soon as you can; do not wait for a lengthy account-recovery process to finish. Google advises revoking its passkey in your account settings if someone else might unlock the device , and considering remote wiping where supported. Apple likewise describes Find My as a remote-wipe option . Follow the device maker's lost-device procedure and the affected service's instructions; recovery of your access and removal of someone else's access are separate jobs.
Be careful when removing credentials. A synced passkey may be usable from several devices. Check what an entry represents and verify another working method before removing your only usable credential. Review the service's device and session controls too, rather than assuming a credential change ends every existing session.
If none of the documented routes works, use the service's official support process. A replacement handset or security key cannot guarantee recovery by itself.
Three questions before you switch
Do I need a fingerprint reader or Face ID?
Not necessarily. Apple documents device passcodes or system passwords as alternatives when biometrics cannot be used, and Microsoft's Windows 11 announcement includes a device PIN. The available choice depends on the device and service. Passkeys are not limited to people with biometric hardware.
Does creating a passkey delete my password?
It depends on the service. Google's October 2023 announcement says personal Google Account users can still choose password sign-in. Do not assume that enabling a passkey removes every previous sign-in method, or turn off protections on a remaining password route merely because you have added one.
What if I switch from iPhone to Android, or change passkey providers?
Treat that as a migration to check before retiring the old setup. Synchronisation within one provider does not establish that a different provider has the same credential. Use the old device to arrange a supported sign-in method on the new one, then verify a fresh sign-in. Keep the old route available until the new one works.
Passkeys can make everyday sign-in easier while reducing exposure to password phishing. Before depending on them, answer one concrete question for your important accounts: if this phone disappeared tonight, which working method would I use tomorrow?
Sources and further reading
- W3C: Web Authentication Level 2 , 8 April 2021.
- Apple: Meet passkeys , WWDC22, June 2022.
- Google: Security of Passkeys in the Google Password Manager , 12 October 2022.
- Google: So long passwords, thanks for all the phish , 3 May 2023.
- Apple: Q&A with the passkeys team , 15 May 2023.
- FIDO Alliance: Guidelines for passkey creation and sign-in , 31 May 2023.
- FIDO Alliance: Deploying Passkeys in the Enterprise — Introduction , June 2023.
- FIDO Alliance: Authentication for Moderate Assurance Use Cases , June 2023.
- Microsoft: Windows 11 September update , 26 September 2023.
- Google: Passwordless by default , 10 October 2023.