Passkeys Were Supposed to Kill the Password. Here's Why They're Stalling.

Passkeys won't kill passwords until services actually remove them. Optional security features don't change anything — the fallback password is the unlocked back door.

Passkeys Were Supposed to Kill the Password. Here's Why They're Stalling.

Four hundred million Google accounts now have passkeys set up. Over a billion authentications completed. Christiaan Brand, Google's Group Product Manager for Identity and Security, called passkeys "the easiest and most secure way to sign into apps and websites." Microsoft followed suit. Apple shipped support across every device. The entire industry held hands and declared: passwords are dead.

Except I still type passwords dozens of times a week. So do you. And if you've actually tried using passkeys across devices, platforms, and services, you've hit the same wall I have. The underlying cryptography is sound. The protocol is elegant. But the experience of living with passkeys in the real world? It's a mess.

→ Related: The Complete Guide to AI Security in 2026

The Ecosystem Fragmentation Problem

Passkeys are built on FIDO2 and WebAuthn. On paper, they're interoperable. In practice, "interoperable" means "it works great in the demo."

Here's the core issue: passkeys are bound to platform credential managers. Create a passkey on an iPhone, it lives in iCloud Keychain. Create one on Android, Google Password Manager. Windows? Windows Hello. Each platform stores credentials differently, syncs through its own cloud, and enforces its own rules about when and how you can use them.

If you live entirely inside one ecosystem, this works fine. But who actually does that? I use a MacBook for work, a Windows machine for certain tasks, and an Android phone. My passkeys are scattered across three credential managers with no clean way to move them.

Andrew Shikiar, Executive Director of the FIDO Alliance, has acknowledged this gap publicly. The Alliance introduced the Credential Exchange Protocol (CXP) to address it, enabling secure transfer of passkeys between providers. But getting Apple, Google, and Microsoft to agree on credential portability is... well, it's exactly as slow as you'd expect. As of mid-2025, CXP is still a draft spec. The portability problem isn't solved. It's barely started.

This fragmentation is what kills adoption. It's not a bug in the protocol. It's a feature of an industry where three companies each want to be your credential provider, and none of them are rushing to make it easy to leave. If you've followed how smart home security vulnerabilities expose the risks of fragmented ecosystems, you'll recognize the pattern. Competing platforms, no shared standards where it matters, and the user caught in the middle.

The UX Is Confusing. That's a Dealbreaker.

I've shipped authentication flows for production systems. I know what happens when you put even slightly confusing security prompts in front of users. They bail. They click "cancel." They find the path of least resistance, which is usually the old password field sitting right there as a fallback.

Passkeys have a serious UX problem, and it starts with the name. Most people don't know what a "passkey" is. They don't understand why their phone is suddenly showing a biometric prompt when they're trying to log into a website on their laptop. The cross-device flow where you scan a QR code on your phone to authenticate a desktop session is technically clever but practically bewildering for anyone who hasn't read a FIDO Alliance whitepaper.

Steve Won, Chief Product Officer at 1Password, has been candid about this. He's pointed out that the passkey creation and sign-in experience varies wildly between browsers, operating systems, and services. Some sites offer passkeys during registration. Others bury them in account settings. Some prompt you after a traditional login. The inconsistency means users never build muscle memory around the flow.

Won's argument, and I agree with it completely, is that the gap isn't in the security model. It's in the human interface layer. 1Password's own research found that first-time passkey users were often confused about whether they'd actually created one, where it was stored, and how to use it on a different device.

After years of building and debugging auth systems, I'm convinced of one thing: the best security feature is the one people actually use. If users are confused, they default to passwords. Every single time. Security that requires a learning curve loses to convenience. I've watched this play out across enough products to stop being surprised by it.

The Password Fallback Trap

Here's the thing nobody's saying about passkeys: almost every service that supports them still requires a password as a fallback.

Think about what that means. You go through the effort of setting up a passkey. You authenticate with your fingerprint or face. It feels futuristic. Then the service asks you to maintain a traditional password "just in case." You now have more authentication methods to manage, not fewer.

This isn't just annoying. It's a security regression. If an attacker can still use your password to get in, the passkey hasn't eliminated the attack surface. You've added a shiny new front door while leaving the old one unlocked.

Joy Chik, President of Identity at Microsoft, has been one of the more aggressive voices pushing for true passwordless accounts. Not passkey-as-an-option. Actually removing passwords. Microsoft's approach with consumer accounts moves toward deleting passwords entirely, not layering passkeys on top. But Microsoft is an outlier here. Most services treat passkeys as a nice addition, not a replacement.

The industry is stuck in a chicken-and-egg loop. Services won't remove passwords until passkeys are reliable enough to stand alone. Passkeys won't feel essential as long as passwords work fine alongside them. I've seen this exact pattern in enterprise systems. You ship the new auth method, keep the old one around "temporarily," and temporary becomes permanent because nobody wants to break the 8% of users who haven't migrated. That 8% has outsized power.

Third-Party Password Managers: Help or More Fragmentation?

Third-party passkey support in tools like 1Password, Bitwarden, and Dashlane was supposed to fix the cross-platform problem. And in some ways, it does. These tools give you a credential store that isn't tied to Apple, Google, or Microsoft.

But it also adds another layer of friction. Now when you create a passkey, your OS offers its native credential manager and your third-party tool. On some platforms, the native option pushes itself aggressively. I've dealt with this on macOS, where Safari fights hard to save your passkey to iCloud Keychain even when 1Password is installed and properly configured. It's maddening.

So a user who wants to use passkeys correctly has to navigate a decision tree every time: which credential manager should store this? Is it the same one I used last time? What happens if I switch password managers later?

The protocol works. The implementations fight each other. The user pays the tax.

For anyone who follows how prompt injection remains the top vulnerability in LLM systems, there's a useful parallel here. In both cases, the underlying system is technically strong, but the seams between components create the real attack surface. Security problems live in the gaps between things, not inside them.

What Actually Needs to Change

I'm not bearish on passkeys. The cryptographic model is genuinely better than passwords. Phishing resistance alone makes them worth pursuing. But "better technology" and "ubiquitous adoption" are separated by a set of problems that aren't technical.

Credential portability needs to actually ship. Not as a draft spec. Not as a press release. The FIDO Alliance's CXP needs to become a real, implemented standard that Apple, Google, and Microsoft support with actual working code. Users need to move passkeys between platforms the way they move photos or documents. This is table stakes.

The UX needs to converge. The way "Sign in with Google" became a universally understood pattern, passkeys need their equivalent. Right now every implementation looks different, behaves differently, and confuses people in different ways. That's not a UX. That's a research project.

Services need to start removing passwords. Not adding passkeys alongside them. Removing passwords. This is the hard one. It requires confidence that recovery flows work, that cross-device scenarios are handled, that users won't get locked out. But until passwords actually disappear, passkeys stay optional. And optional security features don't change anything.

The industry needs to invest in user education with the same energy it puts into security research. This is the part that frustrates me most. The average person has no mental model for public-key cryptography. They don't need one. But they need to understand what a passkey is, where it lives, and why they should trust it. Right now the messaging is inconsistent and often just... absent.

The Scenic Route to Passwordless

Passkeys are one of those things where the boring answer is actually the right one. The protocol works. The vision is correct. Passwords are genuinely terrible and the world will be better without them.

But we're in the worst part of the transition. The new thing exists but doesn't work seamlessly. The old thing still works fine. We've been here before. HTTP to HTTPS. SMS 2FA to authenticator apps. FTP to cloud storage. The better technology always wins eventually. It just takes longer than the spec documents suggest, and the path is never as clean as anyone predicted.

Passkeys will kill the password. They're just taking the scenic route.

Photo by Kedibone Isaac Makhumisane on Unsplash.