Passkeys are better than passwords in almost every technical way, and that is exactly why their slow adoption is so maddening.
The security story is fantastic. No shared secret. Origin-bound credentials. Phishing resistance. Device unlock with a face, fingerprint, or PIN instead of yet another human-memorable string. Apple, Google, Microsoft, and the FIDO Alliance all lined up behind the model. Google said in May 2024 that passkeys had been used more than a billion times across over 400 million Google Accounts in two years — already more often than SMS and app-based one-time codes combined.
And yet, step off the handful of giant platforms and the web still feels like a password world with a passkey demo living off to the side.
What a Passkey Actually Is
Strip away the branding and a passkey is a WebAuthn credential backed by public-key cryptography.
The private key stays on the user’s device or security hardware. The server stores a public key. During login, the server sends a challenge, the authenticator signs it, the browser hands the result back. No shared password is transmitted. No one-time code is copied. The credential is bound to the relying party’s origin — which is why phishing resistance is real, not aspirational.
A phishing site can trick you into typing a password. It cannot casually convince a WebAuthn credential for real-site.com to authenticate to lookalike-site.com. The origin check is built into the ceremony.
This is the strongest argument for passkeys. They don’t just resist phishing better than passwords. For the passkey itself, credential-relay phishing stops working: there is nothing to type into a fake page and nothing a fake page can forward. The weak point that remains is the fallback. As long as the account still accepts a password, a phisher simply asks for that instead.
Passkeys vs. Traditional MFA
This is the comparison that actually matters to most security teams, because “passwords” in 2026 usually means “password plus a second factor.”
A password plus an SMS code or an authenticator-app (TOTP) code is two secrets a human can read and retype. That is exactly what modern phishing kits exploit: they sit between you and the real site, relay your password, relay your six-digit code a second later, and keep the session cookie. The code was valid. It was just handed to the wrong party. Push-notification MFA has its own version of the problem — attackers spam prompts until a tired user taps “Approve.”
A passkey collapses both factors into one gesture and removes the relay. Possession is the private key on your device; the face, fingerprint, or PIN that unlocks it is the second factor; and the signature is bound to the real site’s origin, so a man-in-the-middle page gets nothing it can use. That is why NIST’s 2024 supplement to SP 800-63B (since folded into revision 4 of the guidelines) accepted synced passkeys at Authenticator Assurance Level 2 — the same level as conventional MFA — while device-bound passkeys on security keys can reach AAL3. The practical summary: a passkey is at least as strong as password-plus-TOTP and, unlike it, phishing-resistant.
One more term that gets confused with passkeys: the W3C Digital Credentials API. Passkeys prove you are the same person who registered an account. Digital credentials let a wallet present signed claims issued by someone else — a mobile driver’s license, an age attestation. One is a login; the other is an ID card. They complement each other rather than compete.
The UX Confusion
Here’s where things get messy.
“Use your face to log in” is how most users experience passkeys. The biometric scan — Face ID, Touch ID, Windows Hello — is what they see. What they don’t understand is that the biometric is just unlocking a key stored on the device — the face or fingerprint never leaves the phone. The key does the authentication. The face is the lock on the box that holds the key.
This abstraction is great for security. It’s confusing for mental models. Users don’t know what was created, where it lives, or what happens if they switch devices. They just know “my face works” and stop thinking about it.
Until they get a new phone. Then the thinking starts.
The Sync Problem
Apple syncs passkeys through iCloud Keychain. Google syncs through Google Password Manager. Microsoft was the slowest of the three: since the November 2025 Windows update, Windows 11 can sync passkeys through Microsoft Password Manager and lets third-party managers such as 1Password and Bitwarden plug in as system-wide passkey providers. Within a single ecosystem, this works beautifully. Create a passkey on your iPhone, use it on your Mac, done.
Cross-platform is where the experience degrades.
Logging into a Windows PC with a passkey stored on your iPhone involves a QR code displayed on the PC, scanning it with your iPhone, Bluetooth proximity verification, and then biometric confirmation. It works. It’s not fast. It’s not intuitive. It feels like a workaround, because it is.
The escape hatches are third-party password managers, which store passkeys on every major platform, and the FIDO Alliance’s Credential Exchange Protocol, which finally gives passkeys an export format; Apple implemented it first, in iOS 26 and macOS 26. Both help. Neither is something a typical user has heard of.
For a technical user who understands what’s happening, it’s tolerable. For someone who already struggles to remember which email they used to sign up, it’s a wall.
The Recovery Problem
Passwords have a well-understood recovery flow: “Forgot password?” → email link → set new password. Everyone knows this. It works across every platform and device.
Passkey recovery is platform-dependent and confusing. If you lose all your Apple devices, your passkeys are in iCloud — recoverable if you can access your Apple account. If you never synced, they’re gone. If you used a hardware key with no backup, gone.
“But you should have set up a backup passkey on a second device.” Sure. How many regular users actually do this? How many understand that they need to?
The recovery story is the weakest link in the passkey ecosystem, and it’s the question users care about most: “What happens if I lose my phone?”
Site Adoption: Optional Means Never
Most major sites offer passkeys as an option. Almost none require them. Passwords remain the default. The passkey option is usually buried in security settings — a page most users never visit.
This is the adoption trap. As long as passwords work everywhere and passkeys are opt-in, adoption will be limited to the security-conscious minority. The majority will use passwords because passwords are the default, and defaults win.
Google, Apple, and Microsoft can push passkeys in their own ecosystems. But they can’t force the thousands of smaller sites, enterprise apps, and legacy systems that still only support username/password. The long tail of the web moves slowly.
The Enterprise Gap
Enterprise adoption has its own problems. Single sign-on (SSO) providers are adding passkey support, but the migration from password-based SAML/OIDC to passkey-based flows is non-trivial. IT departments need to provision passkeys, manage device enrollment, handle lost-device scenarios at scale, and support users who can’t or won’t adopt.
Plenty of organizations only recently finished rolling out TOTP as their “advanced” MFA. Jumping from “we just finished our 2FA rollout” to “now replace everything with passkeys” is a hard sell.
Passkeys Are the Right Answer to the Wrong Question
The technology is right. Public-key cryptography is better than shared secrets. Origin binding is better than user vigilance. Biometric unlock is better than memorized strings.
But the question that determines adoption isn’t “what’s more secure?” It’s “what will people actually use?”
People use passwords because passwords work everywhere, require no setup, recover via email, and are universally understood. Passkeys are more secure and, at the margin, less convenient — and at the margin is where adoption decisions are made.
The transition will happen. Eventually. But it won’t happen through opt-in adoption on individual sites. It’ll happen when platforms start requiring passkeys for sensitive actions, when browsers make password autofill feel legacy, and when “forgot passkey” has an answer as universally understood as “forgot password.”
Until then, passkeys deserve better than what they’re getting. The best authentication technology we’ve ever built, waiting for the rest of the ecosystem to catch up.