Google has launched the Credential Transfer API within Android's authentication framework, Credential Manager, enabling secure, direct transfer of credentials between different password manager apps on the same device.
Switching password management apps has traditionally relied on exporting unencrypted plaintext CSV files or manually re-entering data. This approach carried the risk of leaving plaintext credential files on the device, and it had a structural limitation: it couldn't migrate "passkeys," which have been rapidly gaining adoption in recent years. Because passkeys are based on public-key cryptography and protect their private keys within secure hardware enclaves, they simply cannot be exported as plaintext files like traditional passwords. As a result, once a passkey was created, it remained locked to a specific app or service, stripping users of the freedom to switch to better services.
The new mechanism adopts the industry-standard FIDO CXF (Credential Exchange Format v1.0), developed by the FIDO Alliance, and uses Android's OS-level functionality as an intermediary to let apps exchange data directly on-device without creating any external files. How does this resolve vendor lock-in—long considered the biggest bottleneck to passkey adoption—as a standard platform feature? Let's examine the technical architecture and its impact on the ecosystem.
Breaking Free from Plaintext CSVs and Lock-In: Android's New Standard for Password Migration
Migrating between password manager apps has long been a persistent headache for security professionals and privacy-conscious users alike. The standard format used when exporting data from an old app has been the unencrypted CSV file.
This CSV file records, in plaintext, every website URL a user has logged into, their login IDs, and every password except the master password. Once such a plaintext file is saved to a device's downloads folder or local storage, it becomes an easy target for unauthorized access by other apps or malware, and it risks being automatically synced to cloud storage, creating secondary exposure. Even if the file is deleted immediately after use, traces may remain in storage caches or trash folders that can't be completely eliminated.
An even more serious issue has been the rise of passkeys, the next-generation, phishing-resistant authentication method now being widely adopted. Passkeys rely on public-key cryptography, with private keys strictly protected either within secure hardware enclaves or inside each password manager's encrypted vault. Since there's no way to export them as plaintext text files, traditional CSV import/export simply couldn't transfer passkeys to a different management app.
This specification effectively trapped users: once they started using a particular password management service, they could never truly leave it. Even users who wanted to adopt passkeys to improve their security were often deterred by the fear that doing so would make switching services impossible—a major barrier to adoption.
The Credential Transfer API was designed to solve both problems at once. The entire migration process takes place within protected memory space and secure communication channels on the device itself, without ever creating a plaintext file in storage. By formally supporting the transfer of passkeys alongside passwords, it gives users the freedom to switch tools on their own terms, without sacrificing security.
FIDO CXF-Compliant P2P Design, and the FileProvider Structure That Bypasses Binder's Size Limit
This secure migration experience is powered by the architecture of the Credential Transfer API, implemented through Android's Jetpack library, androidx.credentials:providerevents.
The system operates through two clearly defined roles: the "Exporter," which serves as the source of the migration, and the "Importer," which serves as the destination. The entire process proceeds as a peer-to-peer (P2P) exchange, mediated by the OS's core functionality.
To begin a migration, the user opens the new password manager they want to switch to and launches its import feature. When the importer app calls ProviderEventsManager.importCredentials(), the Android system displays a native selector screen, listing available exporter candidates from among the compatible apps installed on the device.
The exporter app pre-registers its own account metadata along with a cryptographically generated unique secret identifier, "secretEntryId," with the system in advance (registerExport). When the user selects the source app on the system screen, the exporter app's dedicated activity (androidx.identitycredentials.action.IMPORT_CREDENTIALS) is invoked.
At this point, the exporter app verifies the requesting package name (callingAppInfo.packageName) and simultaneously checks whether the received identifier strictly matches the "secretEntryId" it stored itself. This dual verification is designed to reliably block attacks where a malicious third-party app sends a fake import request to steal data.
Once the legitimacy of the caller is confirmed, the exporter app prompts the user for biometric authentication (Biometric Prompt) or a device PIN. Unless the user personally passes this explicit identity verification, decryption or handover of the credentials never proceeds.
One notable technical detail is how large volumes of data are transferred. Android's standard inter-process communication (IPC) mechanism, Binder, imposes a strict 1MB limit per transaction. A password vault containing thousands of IDs, passwords, certificates, and metadata entries easily exceeds this 1MB ceiling, risking a TransactionTooLargeException that would break the process.
To avoid this, the Credential Transfer API doesn't send large data payloads directly through Binder. Instead, it adopts a handoff method using temporary cache files accessed through a secure Content URI (FileProvider). Data is temporarily written to a protected cache area on the device and passed to the importer through a secure file descriptor handshake. Since the temporary file is discarded once the process completes, there's no risk of persistent plaintext data remaining in storage.
Furthermore, a WebAssembly (WASM) module is used to determine data type compatibility between providers. A common "credential_transfer_matcher.wasm" module is bundled by default, safely matching the intersection of credential types supported by both parties. Developers can also incorporate custom WASM modules as needed, allowing them to run their own dynamic filtering or permission logic within a sandboxed environment.
Covering 17 Data Types, From Passkeys to SSH Keys: Building an Ecosystem
The data format handled by the Credential Transfer API isn't a proprietary Google format—it fully complies with the FIDO Alliance's FIDO CXF (Credential Exchange Format v1.0) standard.
The FIDO Alliance's Credential Provider Special Interest Group includes not only platform companies like Google, Apple, and Microsoft, but also major password management services such as 1Password, Bitwarden, and Dashlane. By adopting a standard specification agreed upon across the industry, the API ensures open interoperability that doesn't depend on any single company.
Based on the FIDO CXF specification, Android's Credential Transfer API supports as many as 17 distinct credential data types.
- basic-auth: Traditional login ID and password
- passkey: Public-key credentials based on FIDO2 and WebAuthn
- totp: Time-based one-time password seeds used by authenticator apps
- address / credit-card: Address information and credit card details for autofill
- note: Encrypted secure text notes
- ssh-key: SSH public/private key pairs used for server authentication
- wifi: Wi-Fi network SSIDs and connection passphrases
- api-key / drivers-license / passport / identity-document: Various developer tokens and official identity documents
Modern password management tools have evolved beyond simple browser password vaults into comprehensive "digital asset vaults" that manage everything from developers' SSH keys and two-factor authentication seeds to everyday payment information and secure notes. By covering these 17 comprehensive data types alongside password and passkey transfers, users can now safely move their entire accumulated digital vault to a new environment without losing anything.
The ecosystem has also gotten off the ground quickly. Alongside this feature's launch, Android's built-in Google Password Manager as well as major third-party apps—1Password, Bitwarden, and Dashlane—have all completed initial support.
With leading apps that hold significant market share implementing the API in lockstep, users switching between these apps on Android devices can immediately benefit from direct migration. The fact that adoption of the standard didn't remain merely nominal, and that it's functioning as a practical migration ecosystem from day one, carries real significance.
Rolled Out Widely to Android 8.0 and Above: Remaining Challenges and the Path to Cross-Platform Support
One particularly notable aspect of this feature's rollout is the breadth of its reach. The Credential Transfer API doesn't require a major Android OS update—it's delivered through Google Play Services (Google Play developer services).
It's supported on all Google-certified devices running Android 8.0 (API level 26) or later. Thanks to Google Play Services' broad support infrastructure, this new feature becomes available on virtually every Android device currently in active use in the market. The ability to deliver security features instantly to hundreds of millions of users, without waiting for a new OS version update, is one of the Android ecosystem's major strengths.
That said, several practical considerations and future challenges remain.
First, to carry out a direct transfer, both the source and destination password manager apps must be installed on the same device. Both apps need to coexist on the device until the migration is complete, and each must be updated to a version that supports the latest API. For apps that haven't yet added support, or for desktop-only tools, users will still need to rely on traditional plaintext CSV exports or manual entry.
Second, there's the question of how to handle the old vault after migration is complete. The Credential Transfer API securely duplicates and hands off data, but it doesn't automatically erase the original data in the source app or cancel the associated account. After confirming that migration has completed successfully, deciding how to safely clean up or delete data in the old app remains a task left to the user's own judgment.
The biggest focus going forward is progress on cross-platform integration that goes beyond the boundaries of a single mobile OS.
The CXP (Credential Exchange Protocol) and CXF specifications being developed by the FIDO Alliance are originally intended to enable credential transfer across platform boundaries. While the current Credential Transfer API is limited to app-to-app migration within a single Android device, what users truly want is a seamless migration experience that spans different operating systems and devices—"from Android to iPhone," or "from a browser on Mac or Windows to a smartphone."
Google taking the lead in completing FIDO standard implementation on Android, with industry leaders like 1Password and Bitwarden responding in kind, marks a decisive step toward correcting the long-standing security failures surrounding password migration. The key question going forward is how other major platforms, including Apple, will align themselves with the FIDO CXF/CXP standards. The struggle for leadership over credential portability, and the progress of standardization, will be the next critical turning point to watch.