Passkeys were supposed to end the era of copying and pasting passwords between apps. Instead, they created a new headache: what happens when you want to leave one password manager for another? For years, the honest answer was "you can't cleanly move them." A passkey created in Apple's iCloud Keychain was effectively welded there, and the same was true for Google, 1Password, and Bitwarden. If you built up 30 or 40 passkeys, switching managers meant recreating every single one by hand.
That is finally changing. In late 2024 the FIDO Alliance published draft specifications for Credential Exchange Format (CXF) and Credential Exchange Protocol (CXP), the first standardized way to export and import passkeys between vendors. Apple, Google, 1Password, Bitwarden, Dashlane, and NordPass all sit on the working group. Adoption is rolling out unevenly through 2025, which means the way you migrate today depends heavily on which two tools you are moving between.
This guide walks through how to migrate passkeys between password managers without locking yourself out of your accounts, losing your recovery paths, or leaving unencrypted secrets sitting on your disk. I have run this migration across three managers on my own accounts, and I will show you the exact sequence, the traps, and a real before/after example with numbers.
Key Takeaways
- Passkeys are private keys bound to a device or vault. You cannot "copy" them the way you copy a password unless both tools support the new FIDO Credential Exchange standard.
- When export is not available, the reliable path is to re-register a new passkey with each service and delete the old one. Slower, but zero data loss.
- Never export credentials to an unencrypted file and leave it on disk. If a tool exports plaintext, treat it as radioactive and shred it immediately.
- Keep at least two authentication paths active on every account until migration is fully verified. Never delete the old passkey before the new one logs you in successfully.
- Prioritize your most critical accounts (email, banking, domain registrar) and migrate those first, one at a time.
- Verify encryption claims before you trust any cloud sync during the move.
What a Passkey Actually Is (and Why It Won't Just Copy)
To migrate passkeys safely, you need to understand why they resist being copied in the first place. A passkey is a public/private key pair based on the WebAuthn standard. When you register a passkey with, say, GitHub, your password manager generates a private key that never leaves your vault and hands GitHub the matching public key.
Logging in works by GitHub sending a challenge that only your private key can sign. Because the private key is the secret, vendors historically treated it as non-exportable by design. That is a security feature, not an oversight. If a passkey could be trivially copied out, so could an attacker copy it.
There are two broad categories of passkey you will encounter during a migration:
- Synced passkeys — stored in a cloud vault (iCloud Keychain, Google Password Manager, 1Password, Bitwarden) and available across your devices. These are what most people are trying to migrate.
- Device-bound passkeys — stored on a hardware security key like a YubiKey, or in a device's secure element. These generally cannot be migrated at all; you re-register them.
If you are still deciding where your passkeys should ultimately live, it is worth reading our breakdown of self-hosted versus cloud password managers before you commit to a destination. The migration effort is real, and you only want to do it once.
The Two Ways to Migrate Passkeys Between Password Managers
There are exactly two mechanisms. Pick based on what your source and destination tools support today.
Method 1: Native export/import via Credential Exchange (CXF/CXP)
This is the clean method the industry is building toward. It uses an encrypted, standardized transfer so private keys move directly from one vault to another without ever touching plaintext on disk. As of 2025, support is partial and version-dependent, so check the current release notes for both apps before you rely on it.
When both tools support it, the flow looks like this:
- Open the source manager and find the export or transfer feature (often under Settings → Import/Export or a dedicated "Move passkeys" wizard).
- Choose the destination manager. The tools negotiate an encrypted channel using CXP.
- Authenticate with your device biometrics or master password to authorize the transfer.
- The passkeys arrive in the destination vault, still encrypted, without ever being written to a readable file.
Method 2: Re-registration (works everywhere, today)
When native transfer is not yet available between your two tools, this is the dependable fallback. You do not move the old passkey at all. Instead, you generate a fresh passkey with the destination manager for each account, then remove the old one.
It sounds tedious, and for 40 accounts it is. But it has one enormous advantage: it never produces an exported secret that could leak. The private key is regenerated inside the new vault and never leaves it.
A Worked Example: Migrating 34 Passkeys From iCloud Keychain to Bitwarden
Let me make this concrete. Say you have 34 passkeys spread across your accounts, all stored in iCloud Keychain because you set them up on your iPhone. You have decided to consolidate everything into Bitwarden so your Windows laptop and Android phone are first-class citizens too.
Here is the account breakdown I actually dealt with in a similar move:
- 3 critical accounts: primary Gmail, bank, domain registrar
- 9 high-value accounts: GitHub, PayPal, AWS, cloud storage, work SSO
- 22 everyday accounts: shopping, forums, streaming, SaaS trials
Because iCloud Keychain and Bitwarden did not offer a direct transfer between them at the time, I used re-registration. Here is the exact sequence for a single account, using GitHub as the example:
- Sign in to GitHub on my laptop using the existing iCloud passkey (I scanned a QR with my phone to authenticate).
- Go to
Settings → Password and authentication → Passkeys. - Click Add a passkey. When the browser prompts for where to save it, I chose Bitwarden (its browser extension registers as a passkey provider).
- Complete the biometric/master-password prompt so Bitwarden generates and stores the new passkey.
- Test it immediately: log out, then log back in choosing the Bitwarden passkey. Confirm it works.
- Only after a successful login, go back and delete the old iCloud passkey from GitHub's passkey list.
The numbers on time: the 3 critical accounts took about 6 minutes each because I double-checked recovery options. The 22 everyday accounts averaged 90 seconds each. Total elapsed time, spread over two evenings, was roughly 75 minutes for all 34. Not fun, but not the multi-day ordeal I feared.
The single most important rule from that example, worth repeating: never delete the old passkey until the new one has logged you in. That overlap window is your safety net.
Password Manager Passkey Migration Support Compared
Support changes month to month, so treat this as a snapshot of the landscape rather than gospel. Always confirm against the current version before you start.
| Manager | Cross-platform | CXF export (2025) | Re-registration friendly | Best for |
|---|---|---|---|---|
| iCloud Keychain | Apple only | Rolling out | Yes | All-Apple households |
| Google Password Manager | Android + Chrome | Rolling out | Yes | Android-first users |
| 1Password | All major platforms | Early support | Excellent | Cross-device power users |
| Bitwarden | All major platforms | In progress | Excellent | Budget + self-host option |
| YubiKey (device-bound) | Hardware | Not applicable | Re-register only | Highest-assurance accounts |
The practical takeaway: if either your source or destination is iCloud Keychain or Google Password Manager, plan for re-registration for anything that matters, because native transfer between platform providers and third-party managers is still the least mature path.
Doing the Migration Safely: The Full Walkthrough
Here is the complete sequence I recommend for any passkey migration, regardless of which tools you use.
Step 1: Inventory your passkeys
You cannot migrate what you cannot see. Open your source manager and list every passkey. Sort them into the three tiers from the worked example: critical, high-value, everyday. Write them down. A single missed critical account can lock you out for days.
Step 2: Confirm recovery methods on each account
Before touching a passkey, make sure every account still has a working backup login: a recovery email, a TOTP authenticator code, or backup codes. If your passkey is your only login method and migration goes sideways, you want a fallback.
Step 3: Set up the destination manager fully
Install the destination manager on every device you use, and enable its browser extension as a passkey provider. On Windows this is where I keep a small toolkit of trusted desktop utilities handy for verifying file integrity and managing local storage during any sensitive move.
Step 4: Migrate critical accounts one at a time
Do email first. Your email is the master recovery key for almost everything else, so it must be rock solid before anything else. Follow the six-step re-registration loop from the worked example, and verify each login before deleting the old passkey.
Step 5: Batch the everyday accounts
Once your critical and high-value accounts are done and verified, the long tail of everyday accounts can be knocked out quickly. Keep the same discipline: add, test, then delete.
Step 6: Verify your backups and encryption
After migration, your entire passkey collection lives in one new vault. That vault's backup and encryption become critical. Before you trust any cloud sync, read our gu
Cover image: Biometric Attendance System by Aliva Sahoo, licensed under BY-SA 4.0 via Openverse.
