2026-09-27 · 20 min read

What happens to passkeys if you lose your phone?

What happens to passkeys if you lose your phone depends on where each key was saved — synced ones come back, device-bound ones are gone. How to check yours.

Losing the phone does not, by itself, lose the passkey — what matters is where that passkey's private key was stored. A synced passkey lives in a platform account's credential store and is synced to the user's other devices signed into the same account, so it reappears when you set up a replacement phone; a device-bound passkey never leaves a single device, so it goes with the hardware and has to be re-issued rather than recovered. The question worth answering before you need it is not "did I lose my phone" but "which of my passkeys were synced, and can I still pass the check my provider will run — an Android screen lock, a Google Password Manager PIN, or an Apple device passcode I no longer hold?"

Do my passkeys still work the moment the phone is gone?#

The passkeys held by your platform account keep working. The ones held only by that one device stop existing for you the moment you can't unlock it.

Most people are now carrying both kinds without having picked either. On World Passkey Day 2026 the FIDO Alliance reported an estimated 5 billion passkeys in use worldwide — its own estimate, calculated from publicly available data combined with its internal deployment data — and its State of Passkeys 2026 report found 90% of consumers are familiar with passkeys and 75% have enabled them on at least some accounts. The save prompt that created each of those passkeys named a store, not a sync behavior, which is why the difference tends to surface for the first time at the worst moment.

What is the difference between a synced passkey and a device-bound passkey?#

FIDO draws the line at whether the passkey is synced through a cloud service or never leaves one device: passkeys that are synced between user's devices via a cloud service are generally referred to as "synced passkeys", and those that never leave a single device (including those on FIDO security keys or UAF apps) are referred to as "device-bound passkeys". Microsoft Entra ID documentation draws the same line in product terms, distinguishing synced passkeys saved to a platform credential manager such as iCloud Keychain or Google Password Manager and synced across the user's devices, and device-bound passkeys created and stored on a single device, such as Passkey in Microsoft Authenticator, Entra Passkey on Windows, or a FIDO2 hardware security key.

Dimension	Synced passkey	Device-bound passkey
Where the private key lives	A platform account's credential store, synced end-to-end encrypted	Only on that device — it never leaves a single device
After you lose the phone	Survives; available for sign-in on a new device set up with the same provider	Gone with the hardware
Getting signed in again	Restore from the provider	Re-issue: sign in another way and create a new passkey
Effect on recovery odds	Improves the likelihood of account recovery	Forces a fallback to other authentication methods on every new device — a first sign-in that is in practice inconvenient and phishable
Who it suits	Microsoft recommends synced passkeys for all users with non-admin permissions	Microsoft recommends them for admins and highly privileged users

How do I tell which kind of passkey I have?#

By where you saved it. The save prompt that appeared when you created the passkey named the store, and that name decides everything that follows.

Where the passkey was saved	Synced?	What happens if the device is lost
iCloud Keychain	Yes — passkeys sync across a user's devices using iCloud Keychain	Recoverable through iCloud keychain escrow
Google Password Manager	Yes — securely backed up and synced to your Google Account	Recoverable, but to unlock a passkey you need your Google Password Manager PIN or your Android device's lock screen PIN
Windows Hello	No — Google's Chrome help states synchronization or backup aren't supported	Google warns you can't recover them if your computer is lost or the operating system is reinstalled
Chrome profile	No	Google warns you can't recover them if your computer is lost or the Chrome profile is deleted
FIDO2 security key	No — passkeys stored on security keys aren't backed up	Unrecoverable if the key is lost or reset — but useful as a spare
Passkey in Microsoft Authenticator	No — only device-bound and can't be synced	Re-issue on the new device

I lost my phone and the passkey was synced — how do I get it back?#

You set up the replacement device with the same passkey provider, and the passkeys follow: FIDO states that if the user gets a new device and sets it up with their passkey provider, the user's passkeys are synced and available for sign-in on the new device. The step people get stuck on is the one that proves you are you to the encryption layer, and each platform asks for something different.

Google. Passkeys saved in Google Password Manager are available across your devices when you're signed in with the same Google Account on Chrome or Android, and to unlock one you need your Google Password Manager PIN or your Android device's lock screen PIN. That PIN is created for you the first time you create a passkey on a computer, iPhone or iPad; Google's stated purpose for it is to help you use your passkeys on a new device and to make sure no one, not even Google, can access your encrypted data. On an Android device there is no PIN to create or reset — Google Password Manager uses your device's screen lock instead.

Google's security blog is more specific about the fallback. To recover the end-to-end encryption key, the user must provide the lock screen PIN, password, or pattern of another existing device that had access to those keys — and because screen lock values are not known to Google, when the screen lock is removed from a device, the previously configured screen lock may still be used for recovery of end-to-end encryption keys on other devices for a period of time up to 64 days. That 64-day window is the quiet deadline in the whole system: it starts when you clear the lock on an old phone, and nothing prompts you when it expires.

Apple. Passkeys sync through iCloud Keychain, which is end-to-end encrypted with strong cryptographic keys not known to Apple and rate limited to help prevent brute-force attacks even from a privileged position on the cloud backend. When devices are lost, escrow is the mechanism that gets the keychain back: Apple's documented sequence is that the user must authenticate with their iCloud account and password and respond to an SMS sent to their registered phone number, then enter their device passcode, with only 10 attempts allowed before the escrow record is destroyed. Read that sequence again in the situation it is meant for — it asks for an SMS to the number in the missing phone, and for the passcode of a device you can no longer pick up.

Apple's own remedy for that trap is a recovery contact. The same page says that optionally, a user can set up an account recovery contact to make sure that they always have access to their account, even if they forget their Apple Account password or device passcode. You can add up to five, and they won't have any access to your account, only the ability to give you a code — and if you use Advanced Data Protection, a recovery contact can also help you access your end-to-end encrypted iCloud data.

What if the passkey was device-bound — is it genuinely unrecoverable?#

Yes, and the design is deliberate rather than an oversight. Microsoft states plainly that Authenticator passkeys are only device-bound and can't be synced, and that on iOS Authenticator stores the private key in the Secure Enclave while on Android it uses the Android Keystore system to bind the key to a Secure Element or Trusted Execution Environment. Hardware built to never release a key does not make an exception for its owner.

So the remedy is re-issuance, not recovery. Microsoft's guidance when a passkey is no longer valid is to select one of the alternatives offered to sign in, then check your account for any passkeys that no longer apply and delete them, and to set up a new passkey. Every step there depends on an alternative still being offered, which is why the fallback you registered years ago decides this, not the passkey.

One detail worth knowing before it surprises you: a device-bound passkey can break while the phone is still in your hand. Microsoft notes that your passkey is invalidated if you change your PIN, or if you change your biometric sign in from thumbprint to face, or vice-versa on an Android device, after which you need to sign in by using a different method and then create a new passkey.

Does syncing just move the single point of failure somewhere else?#

It does, and that is the honest trade. Syncing takes the risk off the phone and puts it on the platform account — a better place for it, because you can add recovery paths to an account and you cannot add them to a phone that is in the back of a taxi. But it concentrates the consequence, and FIDO says so itself: even when a user is using a synced passkey, they may encounter situations where they are unable to restore the passkey, either by losing access to their passkey provider, or by switching to a device that does not support the previous passkey provider.

Apple is blunt about the sharpest version: if you set up a recovery key and can't provide it when you lose access to your account, you'll be locked out of your account permanently, and if you lose it, Apple can't provide you with your recovery key. One 28-character string, printed once and filed somewhere forgettable, can take every synced passkey with it.

There is a visibility cost too. Microsoft acknowledges that today, administrators can't see or control exactly which devices hold a copy of a synced passkey, nor can they query where a synced passkey has been synchronized, describing this as a broader, industry-wide limitation. If a tenant admin with full directory access cannot enumerate the copies, your personal accounting of which devices hold what is a guess as well.

Even so, the balance favors syncing for most people. Microsoft states that the fact a passkey can sync between the user's client devices and the cloud massively reduces the recoverability and reissuance costs associated with device-bound passkeys, and FIDO notes that because passkeys can be backed up, they can be better protected from loss.

Are passkeys safer than the 2FA I was using before?#

Yes, on the dimension that actually gets people robbed. CISA's fact sheet ranks FIDO/WebAuthn and PKI-based MFA as phishing-resistant — "the gold standard for MFA" — with push bombing, SS7 and SIM swap attacks marked "not applicable", while app-based one-time passwords remain "vulnerable to phishing attacks", push notifications without number matching are "vulnerable to push bombing attacks as well as user error", and SMS or voice is "vulnerable to phishing, SS7, and SIM swap attacks". The same document calls FIDO/WebAuthn "the only widely available phishing-resistant authentication". CISA's accompanying note puts the value in one line: even when an employee falls for a phishing email, the attack will still fail.

The catch is the fallback you leave behind. CISA's mobile guidance says to disable SMS for each account once enrolled, because enrollment in authenticator-based MFA does not automatically unenroll the account's SMS, and this can create a weak fallback mechanism that can be exploited by threat actors. It also concedes the awkward part: some online services may default to SMS during account recovery flows, so it may not be feasible to completely eliminate SMS messages from the service. That leftover SMS path is the same one you were quietly counting on to get back in after losing the phone — which is why the passkey upgrade and the recovery cleanup are two separate jobs, and only the first one is prompted for.

Is the SMS safety net going away?#

On work accounts, yes, and the dates are published. Microsoft announced on 13 July 2026 that passkeys are the default authentication method in Entra ID, citing AI-enabled phishing campaigns reaching click-through rates as high as 54%, compared with roughly 12% for more traditional campaigns.

Date	What changes
1 September 2026	Users enabled for SMS or voice are auto-enabled and nudged for passkey registration upon MFA sign-in — by default with unlimited snoozes of the nudge
30 October 2026	Customers who need to continue using SMS or voice can select and configure a telephony provider from Microsoft Security Store, with Soprano and Telesign as the initial private-preview providers
1 February 2027	Microsoft-provided SMS and voice authentication is retired for all users except Global Administrators and external users; after that date, in-scope users whose only MFA method is SMS or voice must register a passkey during sign-in — a blocking prompt with no opt out
1 July 2027	The later retirement date for Global Administrators and external users, while internal guest users stay on the 1 February date

By that published schedule the first row is already live, so a work account still signing in with a text message should be seeing the registration nudge now, and has until 1 February 2027 before the nudge becomes a wall.

A tenant can delay the automatic enablement but not the ending: Microsoft offers a temporary opt-out for the 1 September 2026 through 1 February 2027 changes, via the Graph authentication methods policy property passkeyDynamicMigration, and states there is no opt out for enforcement on the applicable retirement date.

This is the workforce side, not your personal Gmail. But it sets the direction, and it puts a shelf life on the answer "I lost my phone, text me a code".

Can I move my passkeys somewhere else, or hand them on?#

Not portably, and not by inheritance.

Between providers. The format half of the standard has landed: FIDO published Credential Exchange Format v1.0 as a Proposed Standard on 14 August 2025. The transfer protocol has not. Credential Exchange Protocol v1.0 remains a Working Draft published 3 October 2024, and the specification itself states it "is not intended to be a basis for any implementations as the Specification may change". Apple has gone furthest, shipping passkey transfer between participating credential manager apps on iOS, iPadOS, macOS and visionOS 26 using a data schema built in collaboration with members of the FIDO Alliance — user-initiated, secured by local authentication such as Face ID, with no insecure files created on disk — backed by the ASCredentialExportManager and ASCredentialImportManager APIs. That is one device, app to app. Moving a passkey from Apple's ecosystem to Google's is specified on paper and unshipped in practice.

To another person, if you go unreachable. Apple's Legacy Contact documentation states that a Legacy Contact can't access data stored in your iCloud Keychain (payment information, passwords, and passkeys). Apple's Platform Security guide confirms it at the cryptographic level: the keying information used by a beneficiary doesn't encompass the information necessary to decrypt the decedent's iCloud Keychain. The wider list of what a Legacy Contact does and does not reach is in what happens to an iCloud account when its owner can no longer sign in.

Google is equally clear. For a deceased person's account it states that we cannot provide passwords or other login details. Inactive Account Manager lets you select up to 10 people to receive account data and choose to share all or only specific data types, while noting that some information can't be shared. Neither platform documents any route by which a passkey itself passes to someone else.

So the thing you can hand over is not the credential. It is the map: which accounts matter, which store holds each passkey, where the recovery key and device passcode are written down, and who should act. That is the layer Proceedly covers — a business-continuity check-in that, if you miss it past a grace window, has a person you name confirm before your encrypted handoff plan reaches the people who depend on you. It holds your instructions and where the keys live, never the passwords themselves.

What should I set up today?#

Work through this once, per platform, and losing a phone becomes an inconvenience:

FAQ#

If I lose my phone, can someone else use my passkeys? They would need to defeat the device lock first. Microsoft notes that to register a passkey with a passkey provider, most require two-factor authentication to be set up first, and most also require a device lock to be configured before a passkey can be stored on the device — an experience it describes as common across Google Password Manager and iCloud Keychain, though it may vary with other providers. A device-bound passkey's private key never leaves the device, and syncing is end-to-end encrypted.

I am buying a new phone on purpose. Is that different from losing one? Only in that you still hold the old device, which is the thing recovery most often asks for. FIDO states that if the user gets a new device and sets it up with their passkey provider, the user's passkeys are synced and available for sign-in on the new device. Migrate before you wipe or sell the old phone, and before the 64-day window on a removed Android screen lock runs out.

Why can't Apple or Google just restore my passkeys for me? Because neither holds the keys. iCloud Keychain is protected by cryptographic keys not known to Apple, and Google states that screen lock PINs, passwords or patterns themselves are not known to Google. Support cannot hand over what it cannot decrypt.

Are passkeys stored on a security key safer, given they cannot be recovered? They are harder to steal and harder to replace. Google states that passkeys stored on security keys aren't backed up, and if you lose or reset the security key you can't recover your passkeys. FIDO's own framing is that a device-bound credential forces a fallback to other authentication methods on every new device, a first sign-in that is in practice inconvenient and phishable. Use one as a spare alongside synced passkeys, not instead of them.

Can I export my passkeys to a different password manager? Between apps on Apple's platforms, yes — Apple ships user-initiated transfer between participating credential manager apps on iOS, iPadOS, macOS and visionOS 26. Across ecosystems, not yet: FIDO's Credential Exchange Format is a Proposed Standard, but the Credential Exchange Protocol that would carry the transfer between platforms is still a Working Draft that says it is not intended as a basis for implementations.

Will my family be able to use my passkeys if I go unreachable? No. Apple names passkeys among the iCloud Keychain data a Legacy Contact can't access, and Google says it cannot provide passwords or other login details. Plan to hand over instructions and locations, not credentials.

How were the passkey adoption numbers measured? FIDO's State of Passkeys 2026 report is based on a consumer survey of 11,000 adults across ten countries with a margin of error of plus or minus 0.9 points, and a workforce survey of 1,400 decision-makers at organizations with 500 or more employees with a margin of plus or minus 2.6 points, both conducted by Sapio Research in April 2026. It also found 68% of organizations deploying, piloting, or rolling out passkeys for employee authentication. The 5 billion figure is FIDO's own estimate rather than a measured count.