The short answer is that it depends on whether the passkey is synced or device-bound. Below is how that plays out for Android, Apple and Windows users, and what to do now.
Where the passkey actually lives
A passkey uses public-key cryptography. The website keeps only the public key. The private key stays with your passkey provider or authenticator. The fingerprint tap just unlocks that private key locally. It tells you nothing about whether a copy exists anywhere else.
This is why the site can't rescue you. If the private key is gone and the provider can't restore it, the service has nothing to rebuild it from. You fall back to the service's account-recovery process and then enroll a new passkey.
There are two broad categories:
- Synced passkeys are encrypted and made available through a provider such as Google Password Manager, iCloud Keychain or a third-party password manager. They reappear on other devices signed in to the same account.
- Device-bound passkeys stay on one authenticator. Examples are a hardware security key or a local Windows Hello container. If that is the only copy, losing the device loses the credential.
Independent explainers reach the same conclusion. One recovery guide sums it up as: a synced passkey survives a lost phone; a device-bound one does not.
Android and Google Password Manager
Google's Chrome Help says passkeys used on an Android device are stored in Google Password Manager and are backed up and synced across your Android devices. On computers, Google says passkeys saved there are available on other connected devices when you sign in with the same Google Account on Chrome or Android.
Google's Android guidance covers the lost-phone case directly: you can recover your passkeys on a new device by signing in to your account and providing the security PIN, pattern or password of the lost device. Google's desktop documentation adds that a Google Password Manager PIN can help you recover passkeys on a new device. It also says unlocking an existing passkey needs that PIN or your Android lock-screen PIN.
One caution on the original article's wording. It says recovery means verifying with the old phone's screen lock. Google's Android help supports that for Android recovery, but the Chrome documentation also describes a PIN route. Which one you see depends on your setup, so don't assume every recovery looks identical.
Removing the lost phone's access
Once you're back in, Google's account help says to remove the passkey from a device you can still reach. The steps depend on how the passkey was created:
- For a passkey you created yourself: go to your Google Account, tap Security & sign-in, then under "How you sign in to Google" tap Passkeys and security keys. Select the passkey and tap Remove.
- For a passkey an Android device created automatically: under "Your devices," tap Manage all devices, pick the lost device and sign it out.
- If a removed passkey still shows up at sign-in: check any third-party credential manager and remove it there.
Google also notes that adding a passkey doesn't remove your existing authentication or recovery factors. A passkey is an addition to your account, not a replacement for its recovery options.
Apple and iCloud Keychain
Apple describes iCloud Keychain as keeping passwords and passkeys up to date across approved devices. To check that sync is on, an iPhone user goes to Settings, taps their name, taps iCloud, then Passwords, and turns on Sync this device. On a Mac the path is System Settings, your name, iCloud, Passwords.
If every device is lost, Apple's documentation describes recovery through a recovery contact, if you set one up, or through iCloud Keychain escrow. Escrow recovery involves:
- Signing in with your Apple Account on a new device.
- Answering an SMS sent to a trusted phone number.
- Entering a device passcode.
Apple also limits the number of attempts, and after repeated failures the record locks until Apple Support steps in. So recovery depends on a working trusted number and a remembered passcode, not on luck. Apple says the data is end-to-end encrypted, so Apple can't read it.
Windows: where passkeys really can die with the hardware
This is the part that matters most to WindowsForum readers. Microsoft's Entra documentation says a passkey registered on Windows is device-bound in the sense the documentation uses: it is stored in the local Windows Hello container and doesn't sync. Each device needs its own registration for each Entra account.
Some specifics from Microsoft Learn:
- It works with a Windows Hello PIN, fingerprint or face. The PC doesn't need to be Entra-joined or registered.
- An administrator must first enable passkeys (FIDO2) and create a passkey profile that allows the Windows Hello AAGUIDs. Attestation must not be enforced in that profile.
- It complements Windows Hello for Business rather than replacing it, and it doesn't support signing in to the Windows device itself.
- If a Windows Hello for Business credential already exists for the same account, registration can fail.
Google's Chrome Help makes the same point from the browser side. If you save passkeys to Windows Hello, synchronization or backup aren't supported in that route. Per Google, that means you can't recover them if the computer is lost or the operating system is reinstalled. Google adds that passkeys stored on a security key aren't backed up either. Lose or reset the key and those passkeys are gone.
The Entra detail is a work and school scenario. It shouldn't be generalized to every Microsoft account or every Windows Hello credential. Microsoft's own enterprise guidance also describes synced passkeys as an option administrators can enable through profiles. So the type of passkey your tenant allows matters as much as the device you hold.
For admins, the lesson is practical. If your passkey profile permits only device-bound passkeys, a broken laptop or lost key is an account-recovery event. Your helpdesk process should assume that and plan for a second registered authenticator.
QR-code sign-in is not a backup
Cross-device sign-in can create a false sense of security. A computer shows a QR code, you scan it with your phone, and you approve with fingerprint, face or PIN. Google's instructions say Bluetooth should be on. The phone is the authenticator here, and the QR code only starts the request.
If the phone is dead, that route is dead too. A synced copy on another signed-in device is a different path, and it does work without the broken phone. Don't confuse the two.
A pre-failure checklist
Do these while everything still works:
- Identify the provider for each important account. Is it Google Password Manager, Apple Passwords, a third-party manager, Windows Hello or a security key? The provider decides your recovery path.
- Test recovery of the provider account itself. A synced passkey is only as good as your ability to get back into the account that syncs it. Confirm your Google Password Manager PIN, your Apple trusted number and passcode, and any recovery contact.
- Register a second authenticator. A hardware security key or a passkey on another device keeps you from relying on one phone. Google also lets you create passkeys on multiple devices by repeating the setup on each.
- Store backup codes where the phone can't take them down. Keep them separate from the phone.
- Don't rely on SMS alone. A text is useless if you've lost the phone and its number at once.
- After a loss, revoke. Remove the lost device's passkey or sign the device out, as described above.
One Google detail is worth knowing. A newly created passkey may need up to 7 days before it works at Google sign-in, according to Google Account Help. Don't count on a brand-new passkey as your emergency plan.
Analysis: passkeys aren't fragile, but recovery is the weak link
The MakeUseOf piece is a first-person account, and its central point holds up against vendor documentation. Synced passkeys are more forgiving than most people fear, and device-bound ones are less forgiving than most people assume. Several independent guides agree that the real trouble is that people mix the two without knowing which they created.
The tradeoff is real. Device-bound credentials suit high-risk accounts, but only with a spare key. Synced passkeys are friendlier but move your trust to the provider account. If that account falls to a weak recovery path, the strong passkey doesn't help.
The worst case is losing the phone, its SIM and access to the syncing account all at once. Your backup should not depend on the same pocket as your phone.
Bottom line
- A dead phone doesn't automatically kill Google or Apple synced passkeys, but recovery needs your provider account and its verification steps.
- Windows Hello and hardware-key passkeys don't sync and can be lost with the device.
- QR-code sign-in needs a working phone and is not a backup.
- Add a second authenticator and independent recovery methods now, then remove lost devices from your accounts afterward.