For decades, the standard process of password manager migration was one of the most perilous security hazards in personal computing. If a user wished to reclaim their data sovereignty and move their digital vault from a monolithic ecosystem to a privacy-focused, open-source alternative, they had to navigate a minefield. The standard operating procedure required exporting highly sensitive credentials into an unencrypted, plaintext CSV file. For a brief, terrifying window, every password, username, and security note sat completely exposed in local storage, ripe for harvesting by any rogue process or malicious script running on the machine. This security gap was not merely an inconvenience; it was a structural vulnerability that compromised the very security these vaults were designed to protect.
With the rise of passkeys as the modern gold standard of phishing-resistant authentication, this friction point escalated from a security hazard to an absolute brick wall. Passkeys, by design, are cryptographically bound to the credential provider that generated them. Unlike a string of characters that can be copy-pasted, a passkey relies on a unique public-private key pair where the private key is securely stored within a provider’s software or hardware boundary. Historically, moving these passkeys was practically impossible. Users attempting to switch managers were forced to undergo the grueling process of manually re-registering their passkeys across every single website they frequented. This absolute lack of portability created a massive “walled garden” lock-in, leaving users trapped within whatever ecosystem they first adopted.
That era of forced lock-in is officially drawing to a close. With the rollout of Google Play Services version 26.21, Android has introduced native support for securely importing and exporting both traditional passwords and next-generation passkeys between Google Password Manager and compatible third-party applications. This monumental shift is built upon the open Credential Exchange Protocol (CXP) and Credential Exchange Format (CXF) standards pioneered by the FIDO Alliance. By integrating these specifications directly into the operating system, Android has established a secure, standardized bridge that eliminates insecure intermediary files and unleashes true credential portability.
Democratizing Credential Mobility: A New Era for Password Manager Migration
The core objective of the FIDO Alliance’s Credential Exchange specifications is to redefine how credentials move. Instead of relying on proprietary, ad-hoc export formats, CXP and CXF provide a unified, secure, and cross-platform framework. Understanding why this update is a quantum leap forward requires looking at the complementary relationship between these two standards:
- Credential Exchange Format (CXF): This specification defines what is being exchanged. It standardizes the data structures and representation of credentials into an extensible, unified JSON schema. Whether the item is a legacy alphanumeric password, a passkey public-private key pair, a Time-based One-Time Password (TOTP) seed, an SSH key, or a secure note, CXF ensures that all metadata—such as tags, folders (collections), and usage history—is preserved and interpreted correctly by the importing manager.
- Credential Exchange Protocol (CXP): This specification defines how the exchange happens. It outlines the secure, encrypted cryptographic handshake required to transport the CXF-formatted payload directly from the Exporting Provider to the Importing Provider without exposing the data to intercepting third parties, local filesystems, or cloud relays.
By marrying CXF and CXP, Google has eliminated the need for unencrypted local exports. When a user initiates a password manager migration on Android, the operating system orchestrates a direct, in-memory transfer. The sensitive cryptographic material is packaged into a secure bundle, encrypted end-to-end, and handed directly to the importing app’s memory space. At no point in this process is any plaintext data written to the local storage or the Android filesystem, successfully neutralizing the primary vector for local credential-harvesting malware.
Under the Hood: The Cryptography of CXP and CXF
To fully appreciate the robustness of this system, we must examine the underlying cryptographic architecture. CXP does not merely wrap data in basic SSL/TLS during transit; it employs state-of-the-art cryptographic primitives to establish an ephemeral, zero-knowledge trust channel between the exporting and importing providers.
1. Ephemeral Diffie-Hellman and HPKE
The transfer protocol leverages Hybrid Public Key Encryption (HPKE) (as defined in IETF RFC 9180) built upon an ephemeral Diffie-Hellman key exchange. When the user requests a migration, the importing application (the recipient) generates a one-time asymmetric key pair and sends an import request containing its public key and a unique cryptographic challenge. The exporting application (the sender, such as Google Password Manager) uses this public key along with its own ephemeral key to derive a shared “migration key.” This shared key is then used to encrypt the payload using high-performance symmetric algorithms.
2. The CXF JSON Schema
The exported payload is formatted as a standardized JSON structure defined by CXF. The architecture is elegantly simple yet incredibly robust:
- Header: Contains crucial metadata, including the schema format version, the unique exporter Relying Party ID, and a high-precision cryptographic timestamp to prevent replay attacks.
- Accounts: Groups credentials by the user’s identities. Each account contains collections (folders/vaults) and items.
- Items: Individual entries containing the actual secrets. For a passkey, the item includes WebAuthn parameters, credential ID, and the private key, packaged securely. For a password, it contains the plaintext value and associated history.
The complete CXF bundle is typically compressed into a ZIP archive, where individual JSON files represent accounts or collections, and each file is encrypted as a JSON Web Encryption (JWE) object. This ensures that even if a malicious actor could dump the device’s RAM during the transfer, they would only encounter highly encrypted blocks of data that are useless without the ephemeral private key held inside the importing app’s isolated memory space.
Android’s Native OS Intermediary: Play Services 26.21
While the FIDO standards define the theoretical framework, Google Play Services 26.21 provides the crucial physical integration on Android. The operating system acts as the Authorizing Party, serving as a trusted, secure runtime environment that supervises the transaction. This native implementation introduces several critical security safeguards designed to prevent malicious applications from exploiting the new migration APIs.
First, Android enforces strict, cryptographically verified app identity checks. Before Google Password Manager will initiate an export handshake, Play Services verifies the digital signature of the calling import application against Google’s FIDO-aligned database. If an app attempts to initiate a transfer but lacks a verified signature, or if its package identity has been tampered with, Android immediately terminates the process.
Second, Google has baked explicit user-consent barriers into the system UI. A migration cannot occur silently in the background. The user must explicitly authorize the transfer using their device’s biometrics (fingerprint or face unlock) or system PIN. If the importing application fails to meet strict security compliance standards, the OS halts the transaction entirely and displays a prominent warning: “Export blocked for your protection.” This prevents malicious or poorly designed “clone” applications from phishing for a user’s entire digital vault.
A Unified Future: Breaking the Walled Gardens
The implementation of native credential exchange on Android is a watershed moment for the broader cybersecurity industry. Historically, tech giants had little incentive to make it easy for users to leave their ecosystems. By adopting CXP and CXF, Google has signaled a commitment to open standards that prioritize user choice over vendor lock-in. This aligns Android with Apple, which has also actively contributed to the FIDO specifications and implemented same-device credential transfers in iOS and macOS.
The beneficiaries of this new paradigm are not just individual consumers, but the entire open-source and privacy-focused utility ecosystem. Trusted password managers like Bitwarden, 1Password, Dashlane, and Proton Pass have actively co-authored and supported these standards. With Google Play Services 26.21 lowering the barrier to entry, users can transition to end-to-end encrypted, zero-knowledge managers with unprecedented ease. They are no longer bound to a platform simply because they have accumulated hundreds of logins and passkeys over a decade; they can move their digital identity freely, knowing their security remains intact.
Ultimately, the native integration of the Credential Exchange Protocol and Format on Android represents the final piece of the passkey puzzle. By making passkeys truly portable, the industry has removed the final major objection to passwordless adoption. As these standards become universally deployed, users can finally enjoy a seamless, secure, and sovereign digital existence—completely free of plaintext CSVs, and completely in control of their own credentials.