Android’s new Credential Transfer flow lets compatible password managers move passwords and passkeys directly on the same device, without first creating a readable CSV file. Google announced the feature on September 10, 2026, and initially identified Google Password Manager, 1Password, Bitwarden Password Manager, and Dashlane as participating providers.
Android’s new password-manager transfer
The central change is simple: instead of exporting credentials into a file and moving that file by hand, the destination password manager starts a provider-to-provider transfer coordinated by Android. The Credential Transfer APIs are designed to keep raw credentials from being exposed to Android or unauthenticated apps.
That does not make every migration automatic. Both the source and destination providers must support the transfer flow, and each provider pair determines which credential types actually move.
Which password managers participate?
Google’s initial announcement names four providers:
- Google Password Manager
- 1Password
- Bitwarden Password Manager
- Dashlane
The list describes the providers identified for the initial experience, not every password manager on Android. If a provider has not implemented the APIs, Android’s direct-transfer route does not replace that service’s existing manual import options.
How the Credential Transfer flow works
The process begins in the password manager you want to use as the destination. From its import or copy option, Android can display compatible source providers installed on the device. You then select the source, review the requested transfer and authorize it. The providers can require authentication such as a biometric check or PIN.
The workflow is built around the FIDO Credential Exchange Format, known as CXF. In practical terms, Android coordinates the handoff while the credential providers control the export and import sides of the transaction.
Why direct transfer beats a plaintext CSV
The older route creates a local file containing readable password data. It can work when a provider supports the relevant import format, but it adds several manual steps: export the credentials, locate or move the file, import it and delete the file afterward.
Android’s direct flow removes that loose-file step for compatible providers. That is a meaningful security improvement, but it is more precise to say the framework is designed not to expose raw credentials to Android or unauthenticated apps than to call the process risk-free or describe its complete cryptographic design.
| Dimension | Android Credential Transfer flow | Legacy CSV migration |
| Transfer path | Provider-to-provider exchange coordinated by Android on the same device | Export to a local file, then manually import it into the destination provider |
| Credential exposure | Designed not to expose raw credentials to Android or unauthenticated apps | Credentials are placed in a readable, unencrypted file |
| Passkeys | Supported by the announced flow when the relevant providers implement the credential type | Conventional password CSV files do not reliably represent passkeys |
| User effort | Open the destination app, choose import, select the source, review and authorize | Export, locate or move the file, import it and delete the file |
| Provider requirement | Both providers must implement the Credential Transfer APIs | The destination must support the relevant CSV format or manual import |
| Main limitation | Participation and data coverage depend on the providers | The route is broader in format support but exposes credentials during file handling |
What transfers—and what may not
Google’s announcement explicitly includes passwords and passkeys. The Android API documentation also defines categories such as addresses, payment cards, secure notes, files, TOTP secrets, SSH keys, API keys and custom fields.
Those API definitions describe what the framework can represent; they do not mean every participating app pair transfers every category. Passkeys, attachments, organization vaults, hidden fields and autofill behavior can depend on the source provider, destination provider and the particular data format they implement.
That distinction matters during a switch. A migration can successfully move passwords while leaving other saved items behind. Treat the transfer as a starting point, then inspect the destination vault and the accounts you use most often before deleting the old provider’s data.
Android version and provider limits
The official Credential Transfer documentation supports Android 8, or API level 26, and later. The feature is reported to arrive through Google Play Services rather than a full operating-system update, although the participating password-manager apps still need to support the APIs.
When a provider is not part of the direct flow, the fallback remains a manual import or an unencrypted CSV export. A CSV file containing passwords should be treated as sensitive plaintext: keep it exposed for as little time as possible and delete it after the import is complete.
A safer migration checklist
Before switching, check these points in the source and destination apps:
- Provider participation: Confirm that both apps appear as compatible source or destination providers for the transfer.
- Passkeys: Check whether the particular pair supports passkey transfer, rather than assuming that password support covers passkeys.
- Extra vault data: Review support for notes, cards, files, TOTP secrets, API keys and custom fields.
- Separate vaults: If you use personal and organization vaults, make sure both are included in the migration plan.
- Attachments and autofill: Test important entries and sign-ins after the transfer, since these behaviors can vary between providers.
- Old data: Keep the original vault until the destination contains the accounts and items you need; if you used CSV, delete the readable file immediately afterward.
Android’s transfer framework makes the safest part of switching password managers considerably less awkward: compatible providers can exchange credentials without a plaintext export file. But the short initial provider list and provider-specific data support still decide whether a migration is genuinely complete. The practical rule is clear—use direct transfer when both apps support it, and audit the details before retiring the old vault.
