Passkeys are FIDO credentials that use public‑key cryptography through standards such as WebAuthn/CTAP. The concept matters because it changes what a login secret is. Instead of a password that both you and a service “know,” a passkey uses a public key registered with the website or app and a private key that stays on your device (or in your credential manager). The private key isn’t shared with the site, which makes passkeys phishing‑resistant: there’s no reusable secret for an attacker to steal and replay. The FIDO Alliance frames this as the central security win for passkeys—no shared secret, private key stays under user control. (FIDO Alliance, passkeys overview)

That said, passkeys come in two “shapes,” and the distinction drives most lockouts:

A synced passkey is available across multiple devices via a passkey provider such as iCloud Keychain, Google Password Manager, Microsoft Password Manager, or some third‑party managers. If you lose one device, the passkey can reappear on another—assuming you can sign back into the provider account. (FIDO Alliance, passkeys overview)

A device‑bound passkey lives locally on a single device or hardware key. If that device is lost, reset, or wiped, the passkey can be lost with it. FIDO’s own consumer deployment practices flag that “losing or switching devices” can become a loss‑of‑access event, especially when the new device doesn’t support the same provider or setup. (FIDO consumer deployment practices)

The nuance many people miss is that passkeys solve authentication far better than they solve recovery. FIDO’s enterprise guidance calls recovery the hard part—the “finish line” problem—often requiring processes external to the FIDO credential itself. (FIDO high‑assurance enterprise white paper)

The simplest passkey failure mode is also the most mundane: you saved the passkey to one device, and then you lost the device—or the device lost you.

Microsoft’s Windows documentation describes that a passkey may be saved locally to a Windows device using Windows Hello. (Microsoft Support: create and save a passkey in Windows) That local storage can be a perfectly reasonable choice. It’s fast, private, and avoids dependency on a third‑party sync system.

Local storage also has a sharp edge: operating‑system reinstall, factory reset, or hardware changes that wipe secure storage can strand the credential. Microsoft’s own consumer guidance lists several potential passkey storage locations—credential manager, a phone/tablet via QR, a security key, or Windows Hello local—implicitly acknowledging that “where you save it” changes your risk profile. (Microsoft Support: create and save a passkey in Windows)

The problem isn’t that any vendor is hiding this; it’s that users interpret “passkey” as a single thing, not a family of storage models. People who chose device‑bound passkeys often did so without realizing they had just created a single point of failure.

A common scenario goes like this: you create a passkey on a Windows PC using Windows Hello. Weeks later you reinstall Windows to fix performance issues. The reinstall wipes secure storage; the site still expects the same passkey; you no longer have it. If you also removed passwords or never set up another login method, you are now negotiating recovery—if recovery exists at all.

FIDO’s consumer practices warn that loss of access can happen simply by “switching devices,” a scenario many people now treat as routine. (FIDO consumer deployment practices) Passkeys make logins harder to phish, but they also make them more “physical”: your devices matter again.

Synced passkeys are supposed to reduce lockouts. FIDO describes synced passkeys as more “durable” across device loss and suggests they can reduce recovery events—without claiming they eliminate them. (FIDO: displace password/OTP with passkeys)

Durable is not the same as recoverable. Synced passkeys depend on your ability to re‑authenticate to the provider account that syncs them.

Apple’s iCloud Keychain is explicit about the goal: sync passkeys “across approved devices” so you have redundancy “in case you lose a single device.” (Apple Support: iPhone iCloud Keychain / passkeys guidance) That redundancy, however, flows through Apple’s account and its recovery factors. If you lose access to your Apple Account—say, a lost trusted number, an unreachable trusted device, or a compromised recovery pathway—your synced passkeys may be stranded behind the very door you’re trying to open.

The “meta‑risk” becomes painfully clear in one special case: when the provider account is the account you need. If your Google account holds the passkeys for your bank, but you can’t sign into Google, you may discover your bank passkeys are safe but inaccessible. The same circularity can exist for Apple or Microsoft ecosystems.

From a security standpoint, centralized providers are a rational design. A good provider can enforce strong device security, encrypt synced credentials, and offer a consistent experience across devices.

From a resilience standpoint, it introduces a dependency chain. A passkey for Site A might be functionally gated by your ability to recover Account B (your provider). The user experience often frames this as “sync,” but the practical truth is closer to “outsourced availability.”

Passkeys shine when you can treat passwords as obsolete. Many services encourage exactly that—remove weak fallbacks and reduce risk. The trouble begins when you remove fallbacks before you have a replacement recovery path.

FIDO’s enterprise guidance states: “As long as a password remains active on the user account,” recovery from credential loss is possible through self‑provisioning flows. (FIDO enterprise: replacing password-only auth with passkeys) That line reads like a technical aside, but it contains the whole consumer story: removing passwords changes the recovery equation dramatically.

Google’s Advanced Protection Program (APP) is a useful case study because it’s intentionally strict. Google says APP requires sign‑in with a passkey or security key and adds tougher checks around recovery. (Google Support: Advanced Protection Program) Google also instructs users before enrolling to add a recovery email and phone number, explicitly anticipating lockouts. (Google Support: APP) If you do get locked out, Google describes a multi‑day account recovery verification process. (Google Support: APP)

Those details—pre‑enrollment preparation and multi‑day recovery—are a public acknowledgment of a key point: stronger authentication can mean slower, more deliberate recovery. For many people, that’s a fair trade. For others—journalists under deadline, travelers abroad, anyone who can’t tolerate multi‑day downtime—it’s a serious operational risk.

If you remove passwords (or a service removes them for you), you’re betting that you have:

- At least one additional passkey stored somewhere else
- A tested provider recovery route (trusted devices, recovery phone/email)
- A backup authenticator such as a security key

Without that redundancy, “phishing‑resistant” can still become “user‑locked.”

A sensible person hearing all this will propose a sensible fix: create two passkeys for the same service, stored in two different places. Redundancy is how you prevent lockouts.

In practice, the ecosystem doesn’t always cooperate. Microsoft’s troubleshooting documentation states that credential managers can only have one passkey per website/app/service—in its wording—meaning a common assumption (“I’ll just add a second passkey in the same manager”) may not work the way users expect. (Microsoft Support: troubleshoot signing in with a passkey)

That design constraint pushes users toward diversification:

- A passkey in your primary credential manager
- A separate passkey stored with a different provider (if the site supports adding another)
- A hardware security key as a backup authenticator
- Or a device‑bound passkey on a second physical device

The broader point is portfolio risk. If your passkeys for critical services all live behind one provider account, one outage or lockout becomes systemic. If they all live on one phone, one accident becomes catastrophic.

Many people upgrade phones the same way they replace toothbrushes—without ceremony. If a user’s passkeys were device‑bound, the upgrade is not routine; it’s a migration project. If the user assumed everything was synced and discovers it wasn’t, they’re now in recovery workflows across multiple services, each with different rules.

FIDO’s enterprise writing is unusually blunt about the hardest part of passwordless adoption: recovery. The high‑assurance enterprise white paper notes that relying parties (the sites and apps you log into) may need recovery external to the FIDO credential. (FIDO high‑assurance enterprise white paper)

That framing is helpful because it clarifies responsibilities:

- FIDO/WebAuthn ensures the authentication ceremony is strong and phishing‑resistant.
- Relying parties must still decide what happens when the credential is lost.
- Platform providers (Apple/Google/Microsoft/others) determine how passkeys are stored, synced, and restored.

No single actor owns the whole problem. Users feel the pain anyway.

A site that fully commits to passkeys can still choose weak recovery (SMS, easily hijacked emails) or overly strict recovery (manual reviews, long delays). Enterprises often accept strict recovery because they can issue managed devices, help desks, and identity proofing. Consumers rarely get that support.

Password reset is also a recovery system—and it has been a security disaster for decades. Many breaches and account takeovers begin with compromised email, SIM swaps, or social engineering of support. If passkeys force organizations to rethink recovery rather than relying on “forgot password” links, the long‑term security outcome may improve.

But the transition period is rough. People who expect passkeys to be “set and forget” learn that the true work is “set and test.”

Security advice fails when it assumes everyone has the same devices, budgets, and risk tolerance. Still, the research points to a few principles that consistently reduce lockouts without undermining the core benefits of passkeys.

### Build redundancy on purpose
Aim for at least two independent ways to authenticate, ideally with different failure modes:

- One synced passkey (for convenience across devices)
- One backup method not dependent on that same sync account, such as:
- a hardware security key, or
- a second device with a device‑bound passkey, or
- a second passkey stored with another provider (when supported)

The goal is not paranoia. It’s avoiding single points of failure.

### Treat provider recovery as part of your security posture
If your passkeys sync through iCloud Keychain, Google Password Manager, or Microsoft’s ecosystem, your ability to recover that provider account becomes mission‑critical.

Apple frames iCloud Keychain as redundancy across approved devices, particularly “in case you lose a single device.” (Apple Support) That is only true if you can still satisfy Apple’s account recovery requirements. Google’s APP documentation makes a similar point pre‑enrollment: add recovery email and phone number, because you may need them. (Google Support: APP)

A practical habit: perform a “cold start” test once a year. Sign into the provider account on a new or reset device and confirm you can regain access without improvising.

### Keep recovery realistic, not theoretical
Google openly warns that APP recovery can take multiple days. (Google Support: APP) That’s a security feature, not a bug. It’s also a scheduling fact. If multi‑day downtime would be catastrophic for you, keep at least one backup login method that doesn’t require waiting for identity verification—often a security key stored safely offsite.

### Expert view, plainly stated
The FIDO Alliance summarizes passkeys’ advantage succinctly: authentication without a shared secret, with private keys staying on user‑controlled hardware/software, producing phishing resistance. (FIDO Alliance, passkeys overview) Microsoft’s support documentation, meanwhile, shows how storage choices vary—Windows Hello local storage, credential manager, phone/tablet via QR, security keys—each with different recovery consequences. (Microsoft Support)

Those two perspectives are not in conflict. They describe different layers of the system. Security at the cryptographic layer does not guarantee usability at the recovery layer.

Passkeys deserve their reputation. Public‑key authentication dramatically reduces phishing risk because there’s no password to steal and reuse. The private key stays under your control, and the sign‑in flow resists the classic tricks that empty bank accounts and hijack inboxes.

Still, the most painful passkey failures come from ordinary life: a lost phone, a reset laptop, a provider account you can’t recover quickly, a service that allowed you to remove passwords without ensuring you had redundancy.

The right mental model is simple. Passkeys are not a single key; they are a system of keys and dependencies. The win is real, but so is the “finish line” problem. Anyone adopting passkeys seriously—especially for their most important accounts—should treat recovery as part of the setup, not as an afterthought reserved for emergencies.

Because the day you need recovery is the day you’re least able to build it.

Yes, depending on how the passkey was stored and what recovery options the service offers. Device‑bound passkeys can be lost if the device is wiped, reset, or destroyed. Synced passkeys reduce that risk, but only if you can recover access to the provider account that syncs them. FIDO’s enterprise guidance notes recovery may need to happen outside the credential itself.

A synced passkey can appear across multiple devices through a passkey provider such as iCloud Keychain or Google Password Manager. A device‑bound passkey stays on one device (or hardware key) and doesn’t automatically migrate. FIDO describes both forms, and the difference is central to whether device loss becomes an account‑access emergency.

Phishing resistance addresses attackers stealing your login secret. Recovery addresses you losing your authenticator—your phone, laptop, security key, or provider account access. FIDO’s high‑assurance enterprise writing explicitly treats recovery as a separate “finish line” challenge and notes relying parties may need recovery mechanisms outside FIDO credentials.

Synced passkeys can be strongly protected, but they also make your provider account a critical dependency. If an attacker takes over that provider account, they may gain access to synced credentials depending on the provider’s protections and your device security. Even without compromise, a provider account lockout can strand your passkeys behind a recovery process.

Only after you confirm you have redundancy. FIDO’s enterprise guidance notes that keeping a password active can enable recovery/self‑provisioning after credential loss—removing it changes the recovery story. Some high‑security programs, like Google’s Advanced Protection Program, intentionally tighten recovery and may involve multi‑day verification if you lose access.

User expectations vary, but Microsoft’s troubleshooting documentation warns that credential managers can only have one passkey per website/app/service (as they describe it). That can limit the “just add another passkey in the same app” approach and pushes users toward storing backups in different locations, including potentially a hardware security key.