Why some sites still don't support passkeys, and when that will change

You've read that passkeys are the future. You've seen the pitch: no more passwords, no more phishing, authentication that just works. Then you log into your bank and find the same username-password form you've been filling out since 2006.

The gap between the promise and the reality isn't a failure of the technology. Passkeys work. The problem is everything else: legacy systems, compliance frameworks, customer support infrastructure, and the organizational inertia that comes with touching authentication in a regulated industry.

Here's the underlying mechanism behind slow passkey adoption, what's actually blocking your bank from offering them, and when that will change.

The technical mechanism behind passkeys

Passkeys use public-key cryptography to authenticate you without transmitting a secret. When you create a passkey, your device generates a key pair: a private key that stays on your device and a public key that the service stores. When you log in, the service sends a challenge. Your device signs the challenge with the private key. The service verifies the signature using the public key. If it matches, you're in.

The private key never leaves your device. The service never sees it. An attacker who breaches the service gets public keys, which are useless without the corresponding private keys. An attacker who phishes you gets nothing, because the passkey only works on the legitimate domain. The cryptographic proof is tied to the URL. A fake site can't trick your device into signing a challenge for the real site.

This is the FIDO2 standard, built on WebAuthn. It's been stable since 2019. Apple, Google, and Microsoft all support it. The technical foundation is solid.

The problem isn't the standard. The problem is integrating it into systems that were built when passwords were the only option.

Legacy authentication systems weren't designed for passkeys

Most large organizations run authentication systems that predate passkeys by a decade or more. Those systems were designed around a username-password model with bolt-on two-factor authentication. The database schema, the session management logic, the fraud detection rules, the customer support workflows, all of it assumes that authentication starts with a password.

Adding passkey support isn't a matter of flipping a switch. It requires changes to the authentication flow, the session layer, the account recovery process, and the customer support tooling. If your bank uses a third-party identity provider, that provider needs to support passkeys. If the bank built its own system, it needs to refactor code that's been running unchanged for years.

The deeper the legacy stack, the harder the integration. Banks that run authentication on mainframes face particularly brutal upgrade paths. The FIDO2 protocol wasn't designed with COBOL in mind.

Even organizations with modern stacks face integration complexity. Passkeys require a different mental model for account recovery. With passwords, recovery means resetting a shared secret. With passkeys, recovery means re-establishing trust in a device. The service needs to verify that the person requesting recovery actually owns the account, then provision a new passkey to a new device. That flow touches identity verification, fraud detection, and customer support in ways that password reset doesn't.

Compliance and regulatory frameworks lag behind the technology

Financial institutions operate under regulatory frameworks that specify acceptable authentication methods. Those frameworks were written when passwords and SMS 2FA were the state of the art. Passkeys didn't exist when the rules were drafted.

Regulators move slowly. Adding a new authentication method to an approved list requires review, testing, and formal acceptance. Banks can't deploy passkeys until the regulatory framework explicitly allows them, or at least doesn't prohibit them.

NIST updated its digital identity guidelines to recognize phishing-resistant authentication, which includes passkeys. CISA has published guidance on phishing-resistant MFA. But these are guidelines, not mandates. Individual regulators in banking, healthcare, and other sectors need to update their own frameworks. That process is ongoing, but it's not fast.

Banks won't risk deploying authentication that might fail a compliance audit. They'll wait until the regulatory position is clear. That means passkey adoption in regulated industries trails consumer services by years.

Customer support infrastructure isn't ready for passkey recovery

When a customer forgets a password, the support process is well-established: verify identity, send a reset link, customer creates a new password. When a customer loses access to a passkey, the support process is less clear.

Passkeys sync across devices through platform-specific keychains. If you use iCloud Keychain, your passkeys sync across your iPhone, iPad, and Mac. If you use Google Password Manager, they sync across Android devices and Chrome. But if you lose all your devices, or if you switch platforms, you're starting from scratch.

Account recovery for passkeys falls back to whatever the service offers. That might be email verification, phone verification, or a recovery code you saved during setup. But customer support agents need training on how passkeys work, what can go wrong, and how to guide customers through recovery without compromising security.

Most organizations haven't built that training yet. They haven't updated their support scripts. They haven't tested the recovery flow under real-world conditions. Deploying passkeys without solving the support problem creates a new category of support tickets that agents can't handle.

The organizational cost of changing authentication

Authentication is a high-stakes system. If it breaks, customers can't log in. If it's too permissive, accounts get compromised. If it's too restrictive, legitimate users get locked out. The risk profile makes organizations cautious.

Changing authentication requires coordination across engineering, security, compliance, fraud detection, customer support, and legal. Each team has its own concerns. Engineering wants to minimize technical debt. Security wants phishing resistance. Compliance wants regulatory approval. Fraud detection wants to preserve existing signals. Customer support wants a recovery process that doesn't generate unmanageable ticket volume. Legal wants liability clarity.

Getting all those teams aligned takes time. The larger the organization, the longer the alignment process. Banks don't move fast because they can't afford to get authentication wrong.

Where passkeys are actually rolling out

Consumer services are adopting passkeys faster than regulated industries. Google, Apple, and Microsoft all support passkeys for their own accounts. GitHub, Shopify, PayPal, and eBay offer passkey login. These companies control their own authentication infrastructure, move faster than banks, and face less regulatory friction.

Financial institutions are moving more slowly. A few early adopters have launched passkey support, but most are still in the testing phase. The timeline for widespread adoption in banking is around late 2027 or 2028, based on current regulatory progress and the integration timelines I'm hearing from people inside those organizations.

Healthcare providers face similar constraints. HIPAA compliance adds another layer of review. Schools and universities move at their own pace, constrained by budget and IT capacity. Government services are even slower, because procurement and compliance processes are more rigid.

The pattern is consistent: the more regulated the industry, the slower the adoption. The more legacy infrastructure, the longer the integration. The more distributed the decision-making, the harder the coordination.

What you can do while you wait

If your bank doesn't support passkeys yet, you're not stuck with passwords alone. Two-factor authentication still works. Authenticator apps are better than SMS. Hardware security keys offer phishing resistance even without full passkey support.

Use a password manager to generate unique passwords for every account. Password reuse is still the highest-risk behavior you can change. Even if your bank doesn't support passkeys, you can eliminate the risk of credential stuffing by making sure no two accounts share a password.

Enable passkeys where they're available. If a service offers passkey login, use it. The more you normalize the workflow, the less friction you'll face when your bank finally catches up.

The timeline for universal passkey support

Passkeys will eventually replace passwords, but the transition will take years. Consumer services will lead. Regulated industries will follow once compliance frameworks catch up. Legacy systems will get refactored or replaced. Customer support infrastructure will adapt. The organizational barriers are real, but they're temporary.

By 2028, I'd estimate that most major banks will offer passkey login as an option. By 2030, it might be the default. But that timeline assumes steady regulatory progress and no major setbacks. If a high-profile passkey-related breach happens, or if a compliance audit flags passkeys as non-compliant under an outdated interpretation of the rules, the timeline stretches.

In Breaking Bad, Walter White spends an entire season building a meth empire before the DEA even realizes he exists. The infrastructure was in place long before the authorities caught on. Passkeys are the opposite: the authorities (standards bodies, regulators, security researchers) have been ready for years. The infrastructure is what's lagging.

The technology works. The adoption curve is just slower than the technology deserves.