The End of Passkey Prison
Passwords seem to create endless security problems. Passkeys seemed like the answer. But as more people started using them, a new problem appeared: you couldn’t move them between different apps and services. I wrote about this in The Passkey Illusion. Now the FIDO Alliance is trying to fix it with two new specifications.
The problem is simple. Say your company spends months setting up passkey authentication everywhere. You train people, integrate with a password manager, get everything working. Then you need to switch providers. Maybe for security reasons, maybe for cost, maybe because there’s something better. Until now, that meant starting over completely.
This isn’t theoretical. Todd Thiemann at TechTarget for example simplifies it in “there are a group of users who are concerned about vendor lock in, and this new protocol addresses their concerns.” The fear of getting trapped with one provider has stopped many companies from adopting passkeys.
Two Specifications
The FIDO Alliance worked with Apple, Google, Microsoft, Bitwarden, 1Password and others to create two related specifications.
Credential Exchange Protocol (CXP)
This protocol defines how to securely move credentials between two applications. Think of it as the rules for how password managers should talk to each other when someone wants to move their digital keys.
Credential Exchange Format (CXF)
The CXF protocol defines how credentials get packaged for transport. It makes sure a passkey exported from one system can be imported into another.
How It Works
The problem is more sophisticated than it might seem. When you want to move credentials, the destination app (called the “importing provider”) starts by creating an export request. This isn’t just a simple ask. It includes a list of HPKEParameters in order of preference, telling the source what encryption methods it can handle.
The source app (the “exporting provider”) looks at this list and picks the best cryptographic method both systems support.
They establish a secure channel using Diffie-Hellman key exchange. This creates shared secrets that only the two apps know. You have to authorize the transfer as the credential owner. The system ensures only legitimate owners can move credentials.
Then comes the encryption. The source app uses HPKE (Hybrid Public Key Encryption) following RFC9180. HPKE combines public key cryptography with symmetric encryption. You get the security benefits of public keys with the speed of symmetric encryption.
HPKE is a modern standard that’s already used in TLS Encrypted Client Hello, Oblivious DNS-over-HTTPS, and other protocols. The idea is simple: use public key crypto to securely exchange a symmetric key, then use that symmetric key to encrypt the actual data. Hybrid encryption has been around since the early days of public key cryptography, but HPKE standardizes it with modern primitives.
Each credential file gets encrypted separately using keys derived from the negotiated HPKEParameters. This compartmentalized approach means if one credential’s encryption gets compromised, the others stay secure. Original filenames get replaced with anonymous identifiers like “1b3.jwe” and “d5f.jwe” so nobody can analyze the metadata and figure out what’s being transferred.
The credentials stay encrypted the entire time. From initial packaging through transmission to final import, they never exist in plaintext. The importing provider validates everything, retrieves the migration key, and decrypts the data.
The CXF format is built around a schema for an account owner and their secrets. Common attributes get dedicated fields, but there’s an extension system for future credential types. If an importing provider specifies which extensions it understands, the exporting provider only includes those. If no extensions are specified, it includes everything it wants to share. If an empty extension list is sent, no extensions get included at all.
The archive structure looks like this:
CXF-Export/
├─ index.jwe (encrypted index file)
├─ documents/
│ ├─ 1b3.jwe (anonymized credential)
│ ├─ d5f.jwe (anonymized credential)
│ ├─ 7h9.jwe (anonymized credential)
│ └─ ...Everything uses JSON Web Encryption. The protocol supports both online and offline transfers. The encryption mode follows RFC9180 and should be a member of HPKEMode. The key encapsulation method comes from the HPKE KEM Identifiers IANA table.
Version negotiation works by having the importing provider specify its preferred protocol version. The exporting provider responds with the highest version it supports. This lets mixed-version environments work during transitions.
The extension framework in both CXP and CXF means new features can be added without breaking existing implementations. The specifications can evolve with new security requirements and credential types.
Why This Matters
Most password exports today use unencrypted CSV files. That’s like broadcasting your credentials in plain text. The new protocol encrypts everything by default.
But the real benefit is eliminating vendor lock in. Companies can now evaluate password managers based on features, security and cost instead of worrying about migration difficulty. If a provider has security problems or changes pricing, moving becomes manageable instead of a crisis.
This should accelerate passkey adoption. One of the biggest barriers was the fear of getting stuck with one vendor. With that gone, more organizations will probably switch to passkeys.
The Collaboration
The companies working on this include some surprising partnerships. René Léveillé from 1Password explains: “By changing the paradigm to where the keys can be synced, a lot of rethinking of security properties and interoperability needed to happen.”
This isn’t just vendor cooperation. It’s vendors recognizing that the future of digital identity requires interoperability, not isolation.
Bitwarden reports that daily passkey creation peaked this summer at 500% higher than early 2024. Amazon says over 175 million customers have enabled passkeys. The momentum is clearly building.
Current Status
These are still draft specifications. They’re open for community feedback and not ready for implementation yet. FIDO plans to publish a public review draft in Q1 2025.
1Password and Bitwarden will release an open source Rust library to demonstrate the specifications and hopefully speed up implementation.
What’s Next
If you’ve been hesitant about passkeys because of vendor lock in, these specifications change the equation. The standardization effort shows the industry is committed to making passkeys truly open rather than proprietary.
For companies already using passkeys, this provides future protection. Your investment won’t trap you with a single vendor.
For security teams evaluating authentication strategies, the CXP/CXF specifications remove a major barrier to recommending passkeys. Enhanced security plus improved user experience plus vendor neutrality makes a compelling case.
The FIDO Alliance’s credential exchange specifications represent more than technical standards. They embody the idea that user security shouldn’t come with vendor chains. By making credential portability secure and standardized, these specifications could accelerate the passwordless future while keeping choice and competition at the center.
Organizations should start evaluating their authentication strategies knowing that passkey vendor lock in will soon be history. But let’s be honest about what this doesn’t solve.
Passkeys still have fundamental problems. Cross-device authentication remains clunky. Try signing into a website on your laptop using a passkey stored on your phone. You get a QR code, scan it with your phone, approve the request, and hope it works. It’s better than typing a password, but it’s not seamless.
Recovery is still a mess. Lose your device and you lose your passkeys. Most providers offer some kind of backup, but it usually involves trusting them with your credentials. The whole point of passkeys was to eliminate shared secrets, but now you’re back to trusting a third party.
Enterprise deployment is harder than anyone admits. How do you provision passkeys for thousands of employees? How do you handle device replacement when someone’s laptop dies? How do you audit who has access to what? The tooling for this barely exists.
User education remains a huge barrier. Most people don’t understand what passkeys are or why they should care. They see another authentication method to learn and think “I’ll stick with passwords.” The UX has improved, but it’s still confusing for regular users.
The ecosystem is fragmented. Different browsers, operating systems, and password managers implement passkeys differently. Some websites support them well, others barely work. Users encounter enough friction that they often give up and use passwords anyway.
And then there’s the bigger question: are we solving the right problem? Password reuse and weak passwords are symptoms. The real issue is that we’re still doing authentication the same way we did in the 1970s. Each website maintains its own user database. Users need separate credentials for every service. Passkeys make this system more secure, but they don’t fundamentally change it.
What would actually fix this? A few possibilities come to mind.
True federated identity could work, but not the way we’ve tried it. OAuth and SAML exist, but they create new problems. When you sign in with Google, you’re just shifting trust from the website to Google. And if Google decides to cut you off, you lose access to everything. We need identity systems that don’t create new single points of failure.
Decentralized identity protocols might be the answer. Instead of each website having its own user database, what if your identity lived in a system you controlled? Blockchain-based solutions like self-sovereign identity have promise, but they’re still too complex for normal users. Most people can’t manage their own private keys securely.
Cardano is taking an interesting approach here. Their Atala PRISM platform (now called Hyperledger Identus) lets you create a decentralized ID that lives on the Cardano blockchain. Organizations can issue verifiable credentials to you, like a digital diploma or employment certificate. You store these in your own wallet and choose what to share with whom.
The Cardano Foundation also launched Veridian, which uses something called KERI (Key Event Receipt Infrastructure) for decentralized identifiers. The idea is that your identity becomes portable across services while staying under your control. Instead of Facebook or Google owning your identity, you own it.
But even these solutions have problems. Atala PRISM requires organizations to adopt new infrastructure. Verifiers need to understand blockchain-based credentials. The user experience is still complex compared to typing a password. And you’re back to the key management problem, this time with blockchain wallets instead of passwords.
Zero-knowledge proofs could let you prove who you are without revealing personal information. You could demonstrate you’re over 21 without showing your birthdate, or prove you have a valid account without revealing your identity. But again, the technology isn’t ready for mainstream use.
The zero-knowledge proofs are almost like the old “Where’s Wally?” puzzle. You know where Wally is, but instead of pointing him out, you cover the entire image with paper and cut a small hole showing just Wally. Your friend can see that Wally exists and that you found him, but they learn nothing about where he is in the picture. That’s zero-knowledge: proving you know something without revealing what you know.
The math behind this is incredibly complex, but the concept is simple. Zero-knowledge proofs let you prove statements about private data without exposing the data itself. You could prove your age is over 21 without showing your birthdate, or prove your salary meets a loan requirement without revealing the exact amount.
Maybe the real solution is simpler: get rid of accounts entirely for most services. Do you really need an account to read a news article or buy something online? Guest checkout works fine for shopping. Anonymous access works fine for content. We create accounts because businesses want to track users, not because authentication is necessary.
The most radical idea would be to separate identity from authentication entirely. Instead of proving who you are to get access, you’d prove you have permission to access something. Your phone could hold cryptographic tokens that grant specific access rights. You wouldn’t need to identify yourself to use them.
None of these approaches are ready today. But they point toward a future where authentication doesn’t require giving every website your personal information and trusting them to keep it secure.
The CXP/CXF specifications solve vendor lock in, which is important. But they don’t address any of these deeper issues. We’re still building better chains for a fundamentally flawed model.
The future of digital identity isn’t just passwordless. It’s also vendor neutral. But it’s going to take a lot more work to get there.
The CXP and CXF specifications are in working draft status and open for community feedback through the FIDO Alliance GitHub repository.