Passkeys remove a major phishing weakness: there is no reusable password to type into a lookalike site. But that improvement creates a practical ownership question. If your passkeys live in one credential manager, can you move them to another without exposing private key material in a Downloads-folder export?
The answer is becoming yes, but only when the operating system and both credential managers participate. Emerging standards separate credential structure from the channel carrying it—the difference between genuine portability and a risky file.
Quick answer
Passkeys can be transferred without creating a plaintext file when the exporting and importing credential managers support a direct, authenticated exchange. The FIDO Alliance's proposed-standard Credential Exchange Format (CXF) defines what is transferred. Its Credential Exchange Protocol (CXP) is an early working draft for protecting transfer between providers, not yet a stable implementation standard. Apple also provides a system-mediated process on its version 26 platforms that uses local authentication and creates no insecure export file. None of this makes every passkey portable today: both providers must participate, and users still need a service-by-service fallback plan.
Why passkeys are not just another CSV column
A password export can place a username and reusable secret into rows of a CSV file. That is already dangerous because the file is readable until somebody encrypts or deletes it. A passkey is different. It combines a credential identifier, a relying-party ID, account metadata, and private key material used to sign challenges for one website or service.
The relying party stores the corresponding public key. During sign-in, the provider proves possession of the private key without revealing it to the site. A migration therefore has to preserve exact identifiers and key material while preventing another app, process, cloud backup, or temporary file from capturing them. Copying those fields into ordinary JSON solves syntax, not security.
CXF versus CXP: format is not transport
The FIDO Credential Exchange Format defines a common JSON-compatible data model for credentials. It covers passkeys as well as passwords, TOTP seeds, notes, identity data, SSH keys, and other types. For a passkey, the format includes fields such as the WebAuthn credential ID, relying-party ID, username, user handle, private key, and supported extension data. That common vocabulary helps an importer understand what an exporter sends.
CXF deliberately does not assume how those objects travel. That is the job of a transfer protocol. The current CXP working draft describes a confidential exchange between the exporting provider and importing provider, potentially coordinated by an operating-system orchestrator. FIDO labels that draft as early review material that may change and is not intended as an implementation basis. The CXF specification says the exporter must either encrypt the transfer or rely on the orchestrator's security guarantees, and it prefers CXP as the transfer protocol.
This distinction matters in security reviews. A provider can claim that its data matches CXF while still writing a sensitive document to disk or handing it to a weak transport. CXF interoperability is useful, but it is not proof of a fileless transfer. The implementation must also explain how the exchange is authenticated, kept confidential, protected from alteration, and prevented from being retained by the orchestrator.
Direct exchange is safer than plaintext export
Apple's credential-transfer design illustrates the intended user experience. On supported version 26 platforms, a user initiates transfer directly between participating credential manager apps and approves it with local authentication such as Face ID. Apple says the system moves the data without creating an insecure file on disk. Websites do not need to change their existing passkeys because the exchange happens between managers.
That is materially safer than exporting CSV or JSON, choosing a destination in a file picker, importing it, and remembering to remove every copy. Traditional files can be indexed, backed up, synced, attached, recovered from Trash, or read by malware. A direct exchange narrows exposure to the authorized providers and the operating-system path coordinating them.
Direct does not mean trustless. A compromised endpoint can undermine a sound protocol. Migrate on an updated, known-clean device with remote-access tools and unneeded extensions closed.
Provider participation is the real availability test
A published standard does not automatically activate migration. The source manager must export the credential correctly. The destination must import it without weakening protection or losing required fields. The orchestrator must authenticate the user and protect the exchange. A product may support passkey creation and sign-in while supporting neither CXF nor CXP.
Check both vendors' current documentation for platforms, versions, credential types, and transfer direction. “Supports passkeys” or “imports passwords” is not enough; look for transfer between the two named providers.
What happens to duplicates and revoked credentials?
A transfer is not the same as changing the credential at the website. Apple's guidance says existing passkeys remain unchanged, so the source copy may continue to work after the destination copy is tested. Do not assume “move” means the old provider securely deleted its copy. Confirm the source provider's behavior and remove old copies only after successful destination sign-ins.
Likewise, deleting a local passkey is not necessarily the same as revoking it at the service. The relying party's account-security page is the source of truth for which credentials remain accepted. If a passkey was revoked at the website before migration, copying an old record cannot make it valid again. Apple provides signaling APIs that sites can use to tell credential managers about valid credential IDs and removals, but adoption varies. Review the service's registered-passkey list after every important migration.
Fallback access is part of passkey portability
A perfect bulk transfer can still fail at one relying party because of a provider bug, an unsupported extension, account confusion, or a stale credential record. Before deleting anything, identify another tested way into each high-value account. Depending on the service, that may be a unique password, recovery code, second passkey, hardware security key, trusted device, or documented recovery process.
Prioritize email, platform accounts, financial services, domain registrars, cloud storage, and the credential manager itself. These can reset other accounts, increasing a mistake's blast radius.
A safe passkey migration checklist
- Inventory critical accounts. Record the service, username, registered passkeys, and available recovery methods.
- Verify participation. Confirm that both named credential managers support direct passkey transfer on your OS and app versions.
- Update first. Install current OS and credential-manager releases before starting.
- Use a known-clean device. Avoid public computers, remote-control sessions, and devices under suspected compromise.
- Prefer direct authenticated exchange. Do not improvise with readable CSV, JSON, screenshots, clipboard data, or email attachments.
- Move a small test set. If the provider allows selection, test a low-risk account before a bulk operation.
- Test destination sign-in. Use a fresh browser session and confirm the correct account, not an existing session cookie.
- Review the service. Check its registered-passkey list for expected, duplicate, unknown, or revoked credentials.
- Retain fallback access. Keep recovery codes, secondary factors, and the source provider until critical accounts work.
- Retire deliberately. Remove stale source copies and revoke unwanted credentials service by service only after verification.
Krypt's answer: secure storage now, honest migration boundaries
Krypt supports creating, storing, listing, deleting, and using website passkeys through Android Credential Manager on Android 14 and later. Passkeys live inside the unlocked real vault, and create or sign operations require fresh Android user verification. They are for third-party websites and services; they do not sign in to Krypt or unlock a Krypt vault.
Krypt does not currently advertise or implement CXF or CXP passkey transfer, and it does not offer passkey migration through an ad hoc readable export file. That avoids one obvious exposure path, but it also means Krypt users should not assume bulk passkey portability today.
The practical answer is service-by-service preparation. Use Krypt as a zero-knowledge password manager to keep each account's canonical URL, fallback password, recovery codes, hardware-key notes, and migration status organized in an encrypted vault. Register or transfer passkeys only through provider-supported flows, verify the new sign-in, and preserve fallback access until the relying party confirms the final credential set.
FAQ
Can I export passkeys to a CSV or JSON file?
Do not treat a normal plaintext CSV or JSON export as a safe passkey migration method. A passkey includes private key material and relying-party metadata. Prefer an authenticated, direct exchange between participating credential managers. If that path is unavailable, register a new passkey service by service and verify it before removing the old one.
What is the difference between CXF and CXP?
CXF is the Credential Exchange Format: the proposed-standard data model for passkeys, passwords, TOTP seeds, and other credentials. CXP is the Credential Exchange Protocol: an early working draft for confidential transfer between an exporting provider and an importing provider. CXP may change and is not yet an implementation standard. Supporting the format alone does not prove that a provider uses a secure, fileless transport.
Does Krypt support CXF or CXP passkey transfer?
No. Krypt supports website passkeys through Android Credential Manager on Android 14 and later, but it does not currently advertise or implement CXF or CXP transfer. Plan migration service by service and keep fallback passwords, recovery codes, or other account-recovery methods until every destination sign-in is verified.
Technical references
The FIDO Alliance's Credential Exchange Specifications overview explains the goal of transferring passwords, passkeys, and other credentials securely. The March 2026 Credential Exchange Format Proposed Standard defines the data model and passkey fields. FIDO's Credential Exchange Protocol Working Draft documents the proposed transfer roles, confidentiality properties, orchestrator model, and its early-draft status. Apple's What's new in passkeys session describes direct transfer between participating credential managers, local authentication, fileless exchange, credential-status signals, and the fact that existing passkeys remain unchanged.
Use Krypt to organize website passkeys, fallback passwords, recovery codes, and migration notes inside a local-first encrypted vault.
