Passkeys couldn't be exported as a CSV file, so nine companies wrote a protocol that could

Moving between password managers used to be a five-minute chore. Export a CSV from the old one, import it into the new one, done. Nobody loved that the file sat there in plain text for the length of the transfer, but a password is just a string of characters, and a plaintext string of characters can go in a spreadsheet column whether anyone likes it or not.

A passkey can’t. It isn’t a string you memorized or a random sequence a generator handed you — it’s a cryptographic key pair that exists specifically so nobody ever has to type it, copy it, or read it back. That’s the whole design. Which meant that for the first couple of years passkeys were a real feature in real apps, “how do I move my passkeys to a different password manager” often had an honest but unhelpful answer: you can’t, not really, not yet.

What actually got built

On September 2, 2025, FIDO Alliance published two new specifications  to close that gap: the Credential Exchange Protocol and the Credential Exchange Format, usually shortened to CXP and CXF. The pair came out of a working group that included Apple, Google, Microsoft, 1Password, Bitwarden, Dashlane, NordPass, Samsung and SK Telecom — competitors, in most of these pairings, agreeing on a shared way to hand a user’s credentials to whichever rival they’re switching to.

CXF is the format: a common, JSON-based shape for a passkey, a password, a TOTP secret, or a note, so that every provider describes the same kind of item the same way instead of inventing its own. CXP is the transport: a way to move a batch of those items from one provider to another without ever putting them down in a form a bystander could read. On the same device — moving from one app to another on the same iPhone, which is how Apple shipped its first version in iOS and macOS 26 — the exchange can happen locally, without leaving the device at all. Moving between two different platforms needs an actual encrypted channel, because now two services that have no existing relationship with each other need to agree on a secure handoff over a wire. According to Bitwarden’s own account of adopting the standard , it was the first third-party manager to support CXP after Apple’s launch, with the Android side arriving via Google Play Services roughly ten months later, on July 23, 2026. 1Password, Dashlane, and Proton Pass have adopted it since. The specifications themselves are still FIDO working drafts, which is a polite way of saying the details can still move before this settles into something as boring and universal as CSV import used to be.

Why passwords never needed this and passkeys did

Nine competitors didn’t form a working group to widen an export button. Plaintext CSV was never a good answer for moving passwords — everyone involved in building a password manager knows it — but it was a workable one, because the underlying object survives being written down. A password copied into a spreadsheet is still the same password. It’s a known, uncomfortable tradeoff people have accepted for two decades: briefly exposed, but functional.

A passkey copied into a spreadsheet is nothing at all. There’s no plaintext representation of a private key that a person could read and retype into somewhere else — the entire point of the credential is that it never leaves a form only machines handle. So when two unrelated companies both hold a slice of a user’s passkeys and that user wants to switch, there was no fallback version of “just export it badly.” Either the industry built an agreed, secure way to hand a key pair from one vendor’s storage to a competitor’s, or passkeys quietly became the reason people felt trapped with whichever manager they happened to pick first. CXP is the industry choosing the first option, in public, together — the kind of coordination problem that genuinely needed a shared standard rather than eleven separate proprietary attempts.

Where a local vault was never asking that question

We build one of those eleven managers, and it’s worth being precise about where Vauz sits in this story, because the honest answer isn’t “Vauz solves this too.” Vauz  doesn’t sync your vault to a second remote service, which means it never had the specific problem CXP exists to solve: there’s no other company’s cloud on the far end of a Vauz export for us to negotiate a secure handshake with, because there’s no cloud copy of your vault on our end to begin with. For now, moving a Vauz vault, or moving one into Vauz, is the older kind of portability problem — a file, held by one person, who is also the only one responsible for protecting it. But half the standard still applies to us. CXP assumes two providers negotiating a channel. CXF only describes what a credential should look like on its way out, and a file can be written in that shape whether or not anyone is waiting to receive it. CXF is on our timeline, as part of a broader pass over how Vauz handles imports and exports — the file we write should be one every other manager already knows how to read.

That’s a smaller problem than the one CXP solves, but it isn’t a solved one just because it’s smaller, and we’d rather show our own version of it than wave the comparison away. Exporting from Vauz asks for your V-Key or biometrics even though the vault is already unlocked, on the same reasoning behind how we rebuilt Vauz’s approval flow after the clickjacking research: an open window isn’t proof the person who opened it is still the one at the keyboard, and a file that leaves the vault and lives on your disk is a bigger decision than one an already-unlocked session should get to make on its own. Encryption is on by default for that file, and turning it off requires acknowledging, in plain language, that the result is every password in readable form. The passphrase protecting an encrypted export has to be at least twelve characters and clear a real strength check, and — like the V-Key itself — it isn’t stored anywhere and can’t be recovered if you forget it. Lose that passphrase and the file is exactly as unreadable to you as it would be to anyone else, which is the same tradeoff we’ve made everywhere else.

Importing runs the same way in reverse: each entry in an incoming file is checked individually, not trusted as a batch. Vauz tells you exactly which entries came in, which were skipped as duplicates, and which didn’t parse — a missing identifier, a field that ran too long, a domain list that grew past three — rather than silently dropping anything that didn’t fit. And if an export can’t include every entry, because one couldn’t be read back cleanly, Vauz says so directly rather than letting a partial file pass as a full one: “this file is not a complete backup” is not the sentence you want to discover on the day you actually need it, so it doesn’t get to hide. Both directions are where most of our current work goes, and the shape we’re moving them toward is the one the working group settled on — more on that below.

The gap worth saying out loud

None of that answers a question that a lot of readers evaluating password managers right now actually care about: does the tool support CXP, so that passkeys created in it can move somewhere else later. Vauz doesn’t support passkeys today, and that’s a plain limitation, not a footnote to argue around.

The CXF work is a direction, not a date, and it shouldn’t be read as one. The specifications are still working drafts, we haven’t shipped it, and if passkey portability specifically is what’s driving your decision today, checking for CXP support in a cloud-synced manager answers a question we don’t answer yet. Better to know that before choosing than to find out later.

What to actually check

Whatever you use, “can I export my data” turns out to be at least four separate questions, and CXP’s arrival is a good moment to ask all of them about your own setup: Does the export include every entry type you’ve saved, or only some — passwords but not passkeys, notes but not the TOTP secrets alongside them? Is the file encrypted by default, or does that depend on you remembering to turn it on before you need it? Does writing the file require you to prove it’s still you, or does an already-open session count as permission enough? And if you’re moving passkeys specifically, does the manager speak CXP, or does its version of “export” only work with its own other apps?

CXP is the industry’s answer to the newest and narrowest slice of that list — moving a key pair between two clouds that have never had reason to trust each other before. It’s a genuinely good answer, built by companies that mostly compete with each other, in the open, with a shared spec anyone can read. It just isn’t the whole list. The older half — is the file complete, is it encrypted, does writing it require more than an unlocked screen — was always answerable without a new protocol, by any manager willing to be specific about it. Vauz’s pricing  is where that half lives for us: free for life on the free plan, Plus and Premium for anyone who wants more from the same local-first design.