How to Safely Import & Export Passkeys

Passkeys were supposed to end the era of copying credentials around. No more exporting a plaintext CSV of 300 logins, no more emailing yourself a backup vault. And yet here you are, staring at your password manager, wondering how to get your passkeys out of one app and into another without breaking anything or, worse, quietly leaking your entire identity.

Here is the uncomfortable truth: the passkey ecosystem promised portability years before it delivered it. The FIDO Alliance only published its Credential Exchange Protocol (CXP) and Credential Exchange Format (CXF) drafts in late 2024, and most managers still do not support them in production. That means a real-world "passkey import export" today is a patchwork of syncing, re-registration, and a few genuinely secure transfer paths that almost nobody explains properly.

This guide fixes that. I have moved passkeys between 1Password, Bitwarden, Apple's iCloud Keychain, and Google Password Manager over the last year, and I will walk you through what actually works, what silently fails, and how to do it without exposing yourself. You will get a step-by-step migration, a comparison table of the major managers, and a threat model you can actually reason about.

Key Takeaways

Passkeys are not like passwords: in most cases you do not "export" them at all. You either sync them through a provider or re-register a new passkey with each service.

The FIDO Credential Exchange Format (CXF) is the only sanctioned way to move passkeys between managers, and adoption is still early in 2025.

Never accept a passkey "export" that hands you a readable file. If the private key leaves an encrypted, authenticated channel in the clear, walk away.

Device-bound passkeys (hardware keys, some platform keys) cannot be exported at all. You must enroll a second one.

Keep at least two passkeys or a recovery method per critical account so a migration mistake never locks you out.

Audit which apps and extensions can touch your credentials before you migrate anything.

What "Passkey Import Export" Actually Means

First, a definition, because the word "export" causes most of the confusion. A passkey is a public-private key pair created for a specific website. The website stores the public key. Your device or password manager stores the private key, and that private key is the secret you are trying to protect.

With passwords, exporting is trivial and dangerous: you dump plaintext into a CSV. With passkeys, the private key is designed to be hard to extract. That is the whole point. So "passkey import export" splits into three very different operations:

Syncing — the same passkey exists on multiple devices because your provider (Apple, Google, 1Password) replicates it through an end-to-end encrypted cloud. No file ever leaves your hands.
Transferring — you move a passkey from Manager A to Manager B using the FIDO Credential Exchange Format, an encrypted, authenticated handoff. This is the true "import export."
Re-registering — you log in with an existing credential, then create a brand-new passkey in the new manager and delete the old one. No secret is copied at all.

Most people who search for how to migrate passkeys actually need re-registration or syncing, not a file export. Knowing which category you are in saves hours of frustration.

Why you cannot just download a passkey file

If a tool offers to export your passkeys as a plain .json or .csv you can read, treat it as a red flag. A passkey's security model assumes the private key stays inside an encrypted store. The sanctioned FIDO transfer format wraps everything in an ephemeral encryption layer negotiated between the two managers so the raw key never sits on disk in readable form. Anything else is either non-standard or a downgrade to password-era risk.

The FIDO Credential Exchange Format Explained

The reason this whole topic used to be impossible is that there was no standard. Each manager stored passkeys its own way, and the FIDO WebAuthn spec deliberately discouraged extraction to prevent theft. In 2024 the FIDO Alliance published two related specs:

CXF (Credential Exchange Format) — the data structure describing credentials, including passkeys, passwords, TOTP seeds, and metadata.
CXP (Credential Exchange Protocol) — the secure handshake two managers use to encrypt CXF data during transfer so it is never exposed at rest.

The important design decision: during a CXF export, the source manager encrypts the payload to the destination manager using keys agreed on the spot. The user authenticates on both sides. The file, if one is created at all, is useless without the paired session. This is genuinely different from a password CSV, and it is why I am comfortable recommending it.

As of this writing, support is arriving but uneven. Apple demonstrated import/export in iOS 18 and macOS Sequoia, 1Password and Bitwarden have committed to it, and Google is building toward it. If your two managers both support CXF, use it. If not, fall back to re-registration.

Passkey Manager Comparison: Portability and Recovery

Before you migrate, know what you are working with. Here is how the major options stack up on the things that matter for moving credentials safely. I have used all of these on real accounts.

Manager	Cross-platform sync	CXF export (2025)	Recovery method	Device-bound keys
iCloud Keychain	Apple only	Rolling out	iCloud + recovery contact	Optional
Google Password Manager	Android, Chrome	Planned	Google account recovery	Optional
1Password	All major platforms	Committed / early	Secret Key + Emergency Kit	No (syncs)
Bitwarden	All major platforms	Committed	Master password + recovery code	No (syncs)
Hardware key (YubiKey)	Universal via USB/NFC	Not applicable	Enroll a backup key	Yes (never exports)

The pattern is clear: cross-platform managers give you the most portability, hardware keys give you the most isolation but zero export, and platform managers (Apple, Google) lock you into their ecosystem unless you re-register elsewhere. If you jump between Windows, macOS, Android, and iOS, a cross-platform manager saves you real pain. If you want to understand the deeper tradeoff between these tools and traditional passwords, our breakdown of passkeys versus password managers after the breaches is a useful companion read.

A Worked Example: Moving 23 Passkeys From Google to 1Password

Let me make this concrete. Say you have 23 passkeys stored in Google Password Manager, accumulated across Amazon, GitHub, PayPal, your bank, and a mix of smaller services. You are switching to 1Password because you bought a Windows laptop and are tired of Chrome being the only place your passkeys live. Here is the realistic process, because at the time of writing full CXF transfer between these two is not yet live.

Inventory first. In Chrome, go to chrome://settings/passkeys and list every site. Write down all 23. Assume the migration will take about 3 to 5 minutes per account, so budget roughly 90 minutes.
Install and set up 1Password on both your phone and the new laptop, and make it the default passkey provider in your OS and browser settings. On Windows this is under Settings > Accounts > Passkey settings.
Prioritize by blast radius. Do your email, bank, and password recovery accounts first. If something goes wrong, you want those solid before the low-stakes logins.
For each site, log in using the existing Google passkey, then open the site's security settings and choose "Add a passkey." Your OS will now offer 1Password as the provider. Create the new passkey there.
Verify the new passkey works by signing out and signing back in with it before touching the old one.
Remove the old passkey from the site's security page, and delete it from Google Password Manager. Never delete before you have confirmed the replacement.
Repeat for all 23. Keep a checklist. Cross off each one only after successful re-login with the new key.

Before: 23 passkeys trapped in one ecosystem, no Windows access. After: 23 passkeys in a cross-platform vault you control, each verified working, with the old copies cleanly revoked. No secret was ever exported to a file. That is the point.

When to use CXF instead

If both your managers support the Credential Exchange Format (for example, Apple to a supporting third-party manager), skip the re-registration marathon. Trigger the export from the source manager, authenticate, and the destination will pull the encrypted bundle directly. It takes seconds for all 23 at once. Until that support is universal, re-registration is your dependable fallback.

How to Do It Without Leaking Everything

Migration is exactly the moment attackers love. You are logged into everything, disabling security prompts, and rushing. Slow down and lock the environment first.

1. Clean up your access surface before you start

Before touching a single passkey, audit which third parties can already reach your accounts. Old OAuth grants and shady browser extensions are the most common quiet leaks. Our guide on how to detect and revoke risky OAuth app grants before a breach walks through this, and if you use a lot of extensions, learn to vet browser extensions before they become AI data leaks. A malicious extension can read what you type into a login form during migration.

2. Migrate on a trusted device only

Never migrate on a shared, public, or work-managed machine you do not fully control.
Make sure the OS and browser are fully updated so the WebAuthn stack is current.
Disable screen sharing and remote access tools for the duration.