Passkeys were supposed to be the end of password migration headaches. No more copy-pasting secrets, no more CSV files full of plaintext credentials, no more praying your export didn't leak. And yet here we are: you've built up a collection of passkeys in Apple Passwords, or Google Password Manager, or 1Password, and now you want to move to something else. Suddenly you discover that the very security model that makes passkeys great also makes them stubborn to move.
Here's the surprising part. According to the FIDO Alliance, over 15 billion accounts now support passkeys, and adoption more than doubled through 2024. But the credential export format that makes clean migration possible, the Credential Exchange Format (CXF) and its companion Credential Exchange Protocol (CXP), only reached a stable draft in late 2024. That means most people migrating today are stuck between two worlds: modern passkeys and legacy tools that don't fully speak the new language.
In this guide I'll walk you through exactly how passkey import export works in 2025, which password managers support it, how to move your credentials without locking yourself out of anything, and the specific traps that turn a 20-minute migration into a weekend of account recovery emails. I've done this migration across three managers on real accounts, so the steps below reflect what actually happens, not what the marketing pages promise.
Key Takeaways
- Passkeys are hardware-bound or synced cryptographic key pairs, so you cannot simply copy a "passkey file" the way you copy passwords.
- The FIDO Credential Exchange Format (CXF) is the emerging standard for secure passkey transfer, but as of 2025 support is still partial and rolling out per platform.
- Until CXF is universal, the safest migration path is re-registration: create new passkeys in the destination manager while keeping the old ones as backup.
- Never let a migration leave you with zero working authentication factors on a critical account. Always keep a recovery method alive during the switch.
- Audit what you actually have before you move: list every passkey, its provider, and its recovery fallback.
- Test that you can log in with the new passkey before deleting the old one. Verification beats assumption every time.
What a Passkey Actually Is (and Why You Can't Just Export It)
Before you migrate anything, you need to understand what you're moving. A passkey is not a password. It's a pair of cryptographic keys generated using the WebAuthn and FIDO2 standards. The private key stays on your device or in your password manager's encrypted vault. The public key lives on the website's server.
When you log in, the site sends a challenge, your device signs it with the private key, and the site verifies the signature with the public key. The private key never leaves your control and is never transmitted. That's the whole point. It's phishing-resistant precisely because there's no shared secret to steal.
This design has one obvious consequence for migration: there's no "password string" to copy into another tool. To move a passkey, you either need to move the underlying private key material in an encrypted, standards-compliant way, or you re-register a brand new passkey with the service and retire the old one.
Synced vs Device-Bound Passkeys
Not all passkeys behave the same, and this matters enormously for migration:
- Synced passkeys live in a cloud-backed keychain (Apple iCloud Keychain, Google Password Manager, or a third-party manager like 1Password or Bitwarden). These sync across your devices and are the ones you can potentially export or transfer.
- Device-bound passkeys are locked to a single piece of hardware, such as a YubiKey or a phone's secure element. These are the most secure and by design cannot be exported at all. You migrate them by registering the hardware key with your new setup.
If you rely on a hardware security key for your most sensitive accounts, that credential simply travels with the hardware. There's nothing to import or export, which is a feature, not a limitation.
Does Passkey Import Export Even Work Yet? The Honest Answer
Yes and no, which is frustrating but accurate. The industry agreed on a standard, the Credential Exchange Format, specifically so users wouldn't be trapped in one ecosystem. Under CXF, your credentials are exported as an encrypted payload and transferred to the receiving manager using the Credential Exchange Protocol, so nothing sits in plaintext during the move.
The catch is timing. As of 2025, support is arriving in waves. Some managers can export in the new format but the tool you want to import into doesn't yet accept it, or vice versa. Until both ends of your migration speak CXF fluently, you'll fall back to re-registration for many accounts.
Passkey Migration Support by Manager
Here's how the major players compared when I last tested migrations, focusing on the criteria that actually determine whether your move goes smoothly.
| Manager | Stores Passkeys | CXF Export (planned/live) | Cross-Platform | Recovery Options |
|---|---|---|---|---|
| 1Password | Yes | Rolling out | Windows, macOS, Linux, iOS, Android | Secret Key + recovery codes |
| Bitwarden | Yes | Rolling out | All major platforms + self-host | Master password + emergency access |
| Apple Passwords | Yes (synced) | Announced | Apple ecosystem + limited Windows | iCloud account recovery |
| Google Password Manager | Yes (synced) | Announced | Android, Chrome, ChromeOS | Google account recovery |
| Dashlane | Yes | Committed | Web, iOS, Android | Recovery key |
The pattern is clear. Everyone has committed to the standard, but "committed" and "shipping to your device today" are different things. Check your specific app version before you plan a migration around export, because these features often arrive in staged rollouts.
A Worked Example: Migrating 23 Passkeys From Google to 1Password
Abstract advice is easy to nod along to and hard to follow. So let me give you a concrete scenario I ran through.
Say you have 23 passkeys stored in Google Password Manager on your Android phone and in Chrome on your laptop. You've decided to consolidate into 1Password because you're tired of your credentials being tied to a single browser vendor. Of those 23 passkeys:
- 18 are for services with straightforward passkey re-registration (GitHub, most Google-adjacent services, various e-commerce sites).
- 3 are for high-value accounts (your primary email, your bank, a crypto exchange) where you must not risk lockout.
- 2 are for services that only let you register one passkey at a time, forcing you to delete before adding.
Here's how the numbers played out. The 18 straightforward accounts took about 90 seconds each: log in, go to security settings, add a new passkey, choose 1Password as the provider, confirm. Roughly 27 minutes of work total.
The 3 high-value accounts each got the new 1Password passkey added alongside the existing Google one, tested with a fresh login, and only then had the old passkey removed. That deliberate pace added maybe 10 minutes, but it eliminated any window where I could get locked out.
The 2 single-passkey services were the risky ones. For those I first confirmed a working backup login method (an authenticator app code and a recovery code) existed, then deleted the old passkey and immediately registered the new one. Total migration: about 50 minutes, zero lockouts, zero panicked recovery flows.
Step-by-Step: The Safe Passkey Migration Method
This is the process I recommend regardless of which two managers you're moving between. It works whether or not CXF export is available to you, because it treats re-registration as the reliable baseline.
- Inventory everything first. Open your current manager and list every passkey: the service name, whether it's synced or device-bound, and what recovery methods that account has. A simple spreadsheet works. This step alone prevents most disasters, because you can't safely migrate what you didn't know you had.
- Set up and verify the destination manager. Install your new password manager, sign in, and confirm it's registered as a passkey provider in your operating system settings. On Android and iOS this is a specific toggle in autofill settings; on Windows and macOS it's a system-level provider registration.
- Check for native CXF export. Look in your current manager's export or migration menu for a "transfer credentials" or "export passkeys" option. If both your source and destination support it, use it. The encrypted transfer is faster and safer than manual re-registration for large vaults.
- For everything else, add before you delete. For each account, log in, open its security settings, and register a new passkey with the destination manager. Do not remove the old passkey yet.
- Test the new passkey immediately. Log out and log back in using the newly created passkey. If it authenticates cleanly, you're safe to proceed. If it doesn't, you still have the old one.
- Remove the old passkey only after confirmation. Once the new passkey works, delete the old one from both the service and your former manager. Update your inventory spreadsheet as you go.
- Handle high-value accounts last and slowly. For email, banking, and financial accounts, keep at least two working authentication methods active throughout. Never let a critical account drop to a single factor mid-migration.
- Confirm your recovery methods survived. After migration, verify that recovery codes, backup authenticator apps, and account recovery emails are all still valid. Migration is exactly when people accidentally orphan their fallbacks.
The One Rule That Prevents Lockouts
If you remember nothing else, remember this: never delete a working authentication method until the replacement is proven to work. Overlap is your safety net. The extra two minutes per account is the cheapest insurance you'll ever buy against a locked-out bank account.
Security Traps to Avoid During Passkey Migration
Migration windows are when accounts are most vulnerable, because you're intentionally changing security settings and creating temporary gaps. Here are the mistakes I see most often.
- Doing it on public or shared Wi-Fi. Even though passkey signatures are secure in transit, your session cookies and recovery flows may not be. Migrate on a network you trust.
- Skipping the login test.
Cover image: Software value feedback loop by jakuza, licensed under BY-SA 2.0 via Openverse.
