There are roughly five billion passkeys in the world right now, and most of them are sitting next to a password.
That’s the whole adoption story in one sentence. FIDO’s State of Passkeys 2026 puts consumer awareness at 90%, three-quarters of consumers have a passkey on at least one account, and 68% of organizations are deploying, piloting, or rolling out passkeys for their workforce. Those are numbers I like to see, but then the same report notes that 57% of organizations that have deployed passkeys still rely on a phishable method for day-to-day sign-in.
Bias check: I work at Okta and think about this stuff professionally. I’ve used Entra’s passkey tooling but I don’t live in it, so weight my Microsoft commentary below accordingly.
Two Kinds of Passkeys
The spec calls them ‘single-device credentials’ and ‘multi-device credentials’. Normal people call them device-bound and synced. Then there’s a third that not enough peopl are aware exists and I want to make sure that you do.
| Device-bound | Synced | Shareable | |
|---|---|---|---|
| Private key lives in | Secure element / TPM / Secure Enclave | Provider’s E2EE cloud (iCloud Keychain, GPM, 1Password, Bitwarden) | Same as synced |
| Survives a lost device | No | Yes | Yes |
| Supports attestation | Yes | No | No |
| Moves to another person | No | No | Yes |
| WebAuthn flags | BE=0 | BE=1 | BE=1 (indistinguishable) |
So, Apple’s password manager and most third-party providers let a user hand a passkey to another human being. The academic comparison of device-bound vs synced credentials is clear about this: once a passkey is shared, that operation is irreversible. Revoking access in the provider UI doesn’t stop the recipient from having extracted it.
Your relying party cannot detect this. There is no “was shared” bit. If your threat model includes a departing employee or a partner with a grudge, synced passkeys are a shared secret you can’t rotate which is the exact property moist organizations adopted passkeys to escape.
How They’re Actually Secured
Device-bound:
- A key pair is generated inside the hardware and is marked non-exportable
- The private key never crosses the process boundary, so you get signatures, not key material
- An authenticator can prove its make and model via attestation, validated against the FIDO Metadata Service
- The threat model here is basically “physical possession + user verification”
Synced:
- The key is generated locally, then wrapped and pushed to the provider’s cloud
- The provider holds ciphertext. The unwrap key is derived from the user’s device unlock plus a provider-held secret
- Recovery from a total device loss depends on the provider’s own recovery flow
So in short, a synced passkey is only as strong as the weakest recovery path. Every WebAuthn implementation is downstream of somebody’s iCloud recovery contact and a support agent who can be tricked.
Case and point, 2026 has been rough on the “it’s all in the secure hardware, relax” narrative:
- Unit 42 published research on abusing credential-manager recovery flows to re-establish device trust and get at material used to decrypt synced passkeys.
- SpecterOps presented Pass-the-Passkey at Black Hat USA in August. They didn’t break FIDO2, they replayed signed assertion material that Windows had already produced and Entra accepted. CVE-2026-34348 covers the Windows Event Logging Service writing passkey-related material to logs readable by any unprivileged authenticated user. I saw a great post by Robert Graham on LinkedIn about this last week.
Why Adoption Actually Stalls
Stop hiding behind the ‘users don’t know what a passkey is’. Awareness is at 90%. These are what we see actually stalling deployments:
- The password is still there. If you leave a phishable fallback enabled then you haven’t reduced the attack surface, you’ve added a second front door with a better lock. Attackers don’t phish the passkey, they manipulate the flow into offering the fallback.
- Recovery is the new target. The NCSC flagged post-compromise passkey registration specifically: get in through a weak recovery path, register your own passkey, enjoy persistent phishing-resistant access. If your recovery is “magic link to the email on file,” and that email is protected by a reused password, you’re screwed.
- Enterprise attestation and synced passkeys are mutually exclusive. Per Microsoft’s own docs, enforcing attestation excludes synced passkeys entirely. Entra’s passkey profiles went GA in March 2026 with automatic migration for existing FIDO2 tenants (if you didn’t opt in, you got migrated). Go look at what your Default profile actually enforces.
- AAGUID allowlisting isn’t a security control on its own. Without attestation enforcement, an AAGUID is a self-asserted string. It stops normal users from registering a sketcky key, but it does not stop an attacker who can simply spoof it. Don’t think that’s a problem? How’re you guys doing with blocking bot attacks with IP addresses?
Best Practices That Aren’t Just “Use Passkeys”
Design
- Two credentials, minimum, per account. This is the single highest-leverage decision you make.
- Prompt for enrollment immediately after a successful login, not in a settings sub-page. eBay reported a roughly 102% lift in enrollment from exactly this change.
- Make recovery a higher trust bar than sign-in. If recovery is easier than the primary factor, you have done nothing.
The protocol has been ready for a while. The rollouts are what’s behind.
TL;DR
- Device-bound vs synced is a real security boundary; synced vs shareable is the one nobody’s tracking, and there’s no flag for it. A shared passkey is a shared secret you can’t rotate.
- Origin validation and a fresh single-use server challenge are the phishing resistance. Everything else is plumbing.
- Enforcing attestation blocks synced passkeys entirely. Tier your policy: device-bound for admins, synced for everyone else.
- Passkeys next to a live password fallback aren’t a passwordless deployment. They’re a passwordless-themed one, and your attacker will happily use the other door.