There’s been some buzz recently around the new specifications regarding the Credential Exchange family of specifications coming out of the FIDO Alliance, which has led to some confusion about the whole concept of exportable passkeys.
If you’re like many others, you might be confusing syncing passkeys and Credential Exchange (CX). (Note: Device-bound passkeys are not affected by these specifications). Before we spiral into hypothetical doom scenarios, let’s get one thing straight: this is not about syncing. It’s not about making passkeys magically work across all your devices and all your platforms, like some universal login pixie dust. This is about something much more specific, much more niche, and arguably much more important for long-term user control and ecosystem interoperability.
Let’s talk about Credential Exchange (CX).
What is Credential Exchange
CX is a point-in-time migration protocol, not a sync protocol. If you’ve ever tried to leave one password manager for another, you probably remember the painful steps: exporting a CSV, crossing your fingers that nothing gets corrupted, and importing the file only to realize half your entries didn’t map correctly. Oh, and that CSV? Probably sitting unencrypted in your downloads folder.
The CX family of specifications was designed to fix that.
The CX family has both a schema specification and a protocol specification for securely moving passkeys (and other credentials and items you’d typically find in a credential manager) from one credential manager to another. Think: moving from Apple Passwords to Bitwarden, or Google Password Manager to 1Password. The goal is to eliminate the plain-text mess and standardize the fields so that you can actually preserve metadata like tags, notes, and usage history during a migration.
Again, because this keeps getting misunderstood, this is not a continuous cross-platform sync model. There’s no background process constantly pushing updates to different ecosystems. The user must initiate the migration from one credential manager to another. They can do this as many times as they want.
Why This Matters (Even if Most People Will Never Use It)
Let’s be honest: the regular person (hi, Mom!) will never touch CX. Most people will stick with whatever ecosystem their phone gives them—Apple, Google, whatever—and never think twice.
But for those who do care—those who worry about vendor lock-in, future-proofing access, or trust boundaries between providers—this matters a lot.
Imagine a world where:
- You’re done with Apple and want to move everything to 1Password.
- Your credential manager of choice is shutting down.
- You want to archive your credentials in a way your estate executor can actually access.
These aren’t everyday scenarios, but they’re real. And right now, they’re painful. CX gives us a clean, interoperable way to move between providers without compromising security (or sanity).
What Could Possibly Go Wrong?
Plenty. Like any tool, CX can be misused.
One of the concerns floating around is that CX could become another attack vector. Bad actors could convince users to “migrate” credentials to a malicious app, and if that app poses as a legitimate destination, it could harvest the user’s entire credential set. The threat model here isn’t fully defined yet—though it probably looks like how attackers already trick people into exporting or copying passwords from their managers—but it’s worth watching closely. OS platforms do have mitigations in place for dealing with malicious apps, before and after they are installed (e.g., Google Play Protect, app store review, etc), so mitigations are already in place.
From the relying party (RP) side, one of the issues here isn’t security as much as it is user experience and reliability. Some services today rely on hints from the credential manager (like “this credential lives in the Apple ecosystem”) to drive helpful UX choices. But once CX is in play, those hints can quietly become stale. A credential that once lived in one ecosystem may have been exported elsewhere, and the RP has no way of knowing. There are future plans to enable providing these hints when passkeys are used as well (not just during creation), which should alleviate these concerns.
This isn’t a CX design flaw. But it is a consequence of treating ecosystem-specific metadata as a proxy for where a credential lives, rather than what the protocol actually guarantees. As more users gain the ability to migrate their credentials, services that depend on these assumptions may need to rethink what “helpful” really means and how they rely on that information.
Security Model: New Questions, Not New Threats
CX doesn’t introduce a fundamentally new class of threats, but it does complicate the security model that many RPs and security teams have come to expect.
If CX has been used to export credentials, that same passkey may now live in a completely different ecosystem. There’s no standard way for RPs to tell whether a credential has moved or where it ended up. That makes it harder to scope the blast radius of an incident, and harder to know who still needs help.
There’s also the practical issue: most services haven’t built passkey rotation flows yet. Even if passkey re-registration is technically possible, very few RPs support it in production today. So when credentials are compromised and there’s no clear path to rotate them, users may fall back to less secure recovery options like SMS or email-based OTPs.
These aren’t dealbreakers. But they are operational challenges that need to be solved as CX gains adoption. If you’re building or maintaining a passkey-enabled system, now’s the time to think through:
- What happens when a credential manager is breached?
- Can you support credential rotation or re-enrollment?
- Are you depending on ecosystem hints that might no longer be valid?
Let’s Not Lose the Plot
Yes, there are risks. Yes, they’re worth discussing. But let’s be clear: not every use case demands the same level of security response, and not every theoretical vulnerability warrants panic.
CX is a tool, not a mandate. Its value depends on how and where it’s used. That’s why these questions about breach impact, credential portability, and fallback mechanisms must be addressed as part of a proper risk management exercise, not just tossed around as worst-case hypotheticals.
Threat modeling isn’t about imagining everything that could possibly go wrong. It’s about weighing likelihood, impact, mitigation, and business value. Treating CX as inherently dangerous because it introduces new questions is a shortcut to bad security decisions. Ask the questions, but do it in context.
Why Not Just Call It “Migration”?
Honestly, that might’ve avoided a lot of confusion. CX as a name is technically accurate, but it doesn’t scream “this is only for rare migrations.” And unfortunately, consumer tech reporting has run with the idea that CX means passkeys can be synced across all providers, finally making good on the cross-platform dream.
That’s… not what this is.
It’s also not a get-out-of-jail-free card for people storing the same passkey across multiple providers. If one manager is compromised, that same credential may be reused elsewhere. Using CX doesn’t remove the passkey from the source. That’s still manual and must be done by the user if the user wants to avoid having credentials in multiple locations. The best practice, just like with passwords, is still to use one provider, close old accounts when you’re done, and avoid scattering credentials like breadcrumbs across the Internet.
Bottom Line: This Is About Control, Not Convenience
Exportable passkeys, via CX, aren’t for your average user. They’re for those who want choice, who don’t want to be tied to a single vendor forever, and who want a standards-based path forward.
It’s not about making your credentials work everywhere. It’s about giving you a secure, private way to move them somewhere else when you’re ready to go.
It may not be a feature you ever use. But you’ll be glad it exists when you need it.
Thanks to Dean H. Saxe and many others for all their support in answering my questions and reviewing the post!
Disclaimer: The views expressed in the content are solely those of the author and do not necessarily reflect the views of the IDPro organization.
Author
Heather Flanagan is the Principal at Spherical Cow Consulting, helping organizations navigate the fast-moving world of digital identity and Internet standards. With 15+ years of experience translating complex technical concepts into clear, actionable strategy, she is known for bridging communities and guiding collaborative work. Heather currently co-chairs the W3C Federated Identity and Exploration Interest Groups, the IETF Secure Patterns for Internet Credentials (SPICE) working group, and HotRFC. Her past roles include leadership positions with the OpenID Foundation, IDPro, the IETF/IRTF, and REFEDS. Named to the 2025 Okta Identity 25 as a top thought leader in digital identity, Heather is a frequent speaker and writer focused on standards, governance, and the real-world friction of identity implementation. You can find more of her blog posts (and link to an audioblog podcast!) on her website at https://sphericalcowconsulting.com.
