Migrate Passkeys on Android: 12 Steps, 4 Apps [2026]

Sofia Lindström
September 18, 2026
21 min read

On September 10, 2026, Google quietly flipped a switch that changes how Android handles one of the most annoying chores in personal security: moving your saved logins from one password manager to another. The new system-level transfer feature, built into Android’s Credential Manager and Google Play Services, lets you move both passwords and passkeys directly between apps with no CSV file, no plaintext export, and no copy-pasting from a spreadsheet. If you have ever tried to leave one password manager for another and given up halfway through re-entering two hundred logins by hand, this is the fix. This tutorial walks through exactly how the new flow works, which apps support it today, what to do if yours does not, and how to verify the migration actually succeeded before you delete anything.

Google’s own announcement frames the change as a safety upgrade as much as a convenience one. According to Google’s blog post on the feature, the goal is “switching password managers is easy and safe on Android,” replacing a workflow that used to depend on unencrypted export files sitting in your Downloads folder. We will treat that blog post, plus reporting from TechCrunch and 9to5Google, as the primary source of truth throughout this guide, and we will flag anywhere the underlying detail is still thin.

Don’t miss new tech stories on Google

Add Tech Insider once in the Google app and our stories appear in your news suggestions.

What Google’s New Android Password Manager Switch Actually Does

Before the September 2026 update, moving credentials between password managers on Android meant one of two things. Either the source app supported exporting a CSV file of your saved logins, which you then imported into the destination app, and which sat on disk in plaintext until you remembered to delete it, or you retyped everything manually. Passkeys made this worse, not better, since a passkey’s private key is generated and stored in secure hardware and was never designed to be copied into a spreadsheet in the first place. Anyone who created passkeys in one manager was effectively locked into it.

The new flow removes the file entirely. Google describes the process in three steps in its official announcement. First, you open the password manager you want to switch to and choose an option to import or copy credentials from another provider. Second, that app hands the request to Android itself, which scans the device for compatible password managers already installed and presents them as transfer sources. Third, Android opens your existing manager so you can review exactly what is about to move and authorize the transfer with your screen lock, PIN, or biometric. Once you approve it, Google says the actual data movement happens in a matter of seconds, encrypted vault to encrypted vault, with nothing written to a temporary file in between.

It is worth being precise about what “credentials” means in this context, since the feature covers more than the traditional username-and-password pair most people picture. It includes stored passkeys, which are the FIDO2-based public-private key credentials that have been replacing passwords on sites like Google, GitHub, and a growing number of banks. It does not include one-time passcodes generated by a separate authenticator app, payment card details some managers also store, or secure notes. Those categories either do not have a standardized transfer protocol yet or were left out of the initial rollout, so budget separate time for them if your vault includes any of the above.

That last detail matters for anyone thinking about security hygiene. A plaintext CSV export is a liability the moment it exists, because anything with file-system access, a backup job, a cloud sync tool, another app with broad storage permissions, can potentially read it. Coordinating the transfer at the OS level through Android’s Credential Manager closes that gap. It is also why this feature is arriving now rather than years ago: Credential Manager itself is still a relatively young API, and getting four separate companies to agree on a shared transfer protocol took real coordination.

Prerequisites: Devices, OS Versions, and App Requirements

You do not need a Pixel or a flagship phone to use this feature, but you do need to clear a few baseline requirements. TechCrunch and AndroidHire both report that the transfer works on any device running Android 8 (Oreo) or newer, which covers the overwhelming majority of Android phones still in active use in 2026. That said, the platform minimum is not the same as the practical minimum for every app. Individual password managers can, and do, set their own higher bar. Check the table below before you start, and update every app on the list to its current release before attempting anything.

One detail worth calling out separately: this is strictly an on-device operation. Both the app you are leaving and the app you are moving to need to be installed and signed in at the same time, because Android is literally routing an encrypted handoff between two apps on the same phone. If you already deleted your old password manager before reading this, skip ahead to the fallback section later in this guide, because the OS-level flow will not help you anymore.

Which Password Managers Support the New Transfer Flow Today

This is the part readers care about most, and it is also the part most likely to change in the coming months, so treat it as a snapshot of mid-September 2026 rather than a permanent list. According to Google’s own announcement and confirmed independently by TechCrunch, 9to5Google, and Ars Technica, four providers are live launch partners: Google Password Manager, 1Password, Bitwarden Password Manager, and Dashlane. Google’s post explicitly states that more partners are expected to follow, without committing to names or dates.

If your combination of old app and new app both appear in that first group of four, you can follow the step-by-step walkthrough below and expect the native flow to work end to end. If you are moving to or from a provider that has not adopted the API yet, jump to the manual migration section further down, which covers the encrypted-export fallback that still works for everyone.

Native Transfer vs. the Old CSV Workflow

It helps to see the two approaches side by side before you commit to one. The old CSV workflow still works today for apps that have not adopted Credential Manager, and it is not going away anytime soon, but it carries tradeoffs the new flow was built specifically to remove. The table below lays out the practical differences you will actually notice during a migration.

The practical takeaway is simple. If both your old and new apps are on the launch list, there is no longer a good reason to use the CSV route at all. If one of them is not, the CSV path remains your only option for passwords, and passkeys on that provider will need to be manually recreated one site at a time until support arrives.

Before You Start: Back Up Your Vault the Safe Way

Even a well-tested transfer feature deserves a safety net on its first public week. Before you touch the new flow, take an encrypted backup of your current vault using the app’s own built-in export tool, not a third-party scraper or browser extension. Every major password manager has one. Bitwarden, for example, ships a documented CLI export command that produces an encrypted JSON file rather than a plaintext CSV when you pass the right flag.

bw export --format encrypted_json --output ~/vault-backup-2026-09-18.json

Store that file somewhere outside of cloud sync while you complete the migration, ideally on encrypted local storage, and delete it once you have confirmed every entry made it to the new app. This step is not required by Android’s new transfer flow, but it costs five minutes and gives you a way back if something goes wrong partway through step nine below.

Step-by-Step: Migrating Passwords and Passkeys on Android

This walkthrough assumes you are moving between two apps on the confirmed launch list. The whole process, once both apps are updated and ready, typically takes ten to twenty minutes for a vault of a few hundred entries, most of which is spent reviewing what gets transferred rather than waiting on the transfer itself.

Steps 1 through 4: Preparing Both Apps

1. Check your Android version. Open Settings, then About Phone, then Software Information, and confirm you are on Android 8 or later. Power users can check this faster from a terminal with adb, shown below.
2. Update the app you are leaving. Open the Play Store, search for your current password manager, and install any pending update. An outdated source app is the single most common reason the transfer option never appears.
3. Install and update the app you are moving to. Download it fresh from the Play Store if it is not already installed, then check for updates immediately after the first launch.
4. Sign into the new app, but do not create any passwords yet. You want an empty or near-empty vault so the incoming transfer is easy to audit afterward.

adb shell getprop ro.build.version.release
adb shell getprop ro.build.version.sdk

Output example on a device running Android 16:

16
36

If the first line returns 8 or higher, your OS version clears the baseline requirement. The second line is the API level, which some enterprise mobile device management policies check separately.

Steps 5 through 8: Running the Transfer

1. Open the new password manager app and navigate to its settings or onboarding screen. Look for wording like “Import passwords,” “Switch from another app,” or “Copy from another provider.” Every supported app phrases this slightly differently.
2. Select the option to import or copy from another provider. The app hands control to Android at this point, which is your cue that the system-level flow has kicked in rather than a manual CSV importer.
3. Choose your existing password manager from the detected list. Android scans installed apps for Credential Manager transfer support and shows only the ones that qualify. If your old app is missing from this list, it either needs an update or has not adopted the API yet.
4. Authenticate in the old app when prompted. This is the review-and-authorize step Google describes in its rollout post. You will typically see a summary of how many passwords and how many passkeys are about to move, and in some cases you can deselect individual entries before confirming.

Steps 9 through 12: Verifying and Locking In the New Vault

1. Wait for the transfer to complete. Google says this takes only a few seconds once authorized, but larger vaults with hundreds of entries can take a minute or two. Do not force-close either app during this window.
2. Open the new app and spot-check ten to fifteen entries, prioritizing your email account, banking apps, and any site where you know you have a passkey rather than a password.
3. Test at least two passkey sign-ins directly, not just a visual check in the vault list, since a passkey entry can appear present while still failing to authenticate if the transfer was incomplete.
4. Set the new app as your default autofill service in Android Settings under Passwords and Accounts, then keep the old app installed for a week or two as a passive backup before uninstalling it.

You can confirm which app Android currently treats as the default autofill provider directly from a terminal, which is useful if you manage more than one device.

adb shell settings get secure autofill_service

Expected output after a successful switch to, for example, Bitwarden:

com.x8bit.bitwarden/com.x8bit.bitwarden.autofill.AutofillService

If that command still returns your old app’s package name after you believe you switched, the autofill default did not update automatically and you need to set it manually in Settings.

How Android’s Credential Manager Actually Works Under the Hood

The transfer feature builds directly on top of Credential Manager, the same API Android apps use to create and store passkeys in the first place. Understanding the underlying mechanics helps explain both why the feature is secure and why it only works between apps that have implemented it. Android’s own developer documentation lays out the creation flow apps follow: “the steps to create a passkey can be summarized as follows: 1. Your client app requests the options required to create credentials from your app server,” as described in Android’s official passkeys documentation. A separate Android Developers guide adds that “to create the passkey, obtain details required to create the passkey from your app server, and then call the Credential Manager API, which returns a public and private key pair,” detailed in Android’s guide on creating passkeys.

That public-private key pair is the reason passkeys never traveled well through CSV exports. The private half of the pair is meant to stay bound to secure hardware and never leave the device in a form a human, or a plaintext file, could read. What changed in September 2026 is that Android now lets two trusted apps on the same device hand that key material to each other directly, through an authenticated, encrypted channel, rather than requiring it to be exported at all. Google summarized the original end-user experience for passkey creation similarly back in 2022, noting that “for the end-user, creating a passkey requires just two steps: (1) confirm the passkey account information, and (2) present their fingerprint, face, or screen lock when prompted,” a description that still holds for both creation and the new transfer flow, according to Google’s Android Developers blog.

What to Do If Your Password Manager Is Not on the Launch List

If you use Proton Pass, NordPass, or another manager that has not adopted the Credential Manager transfer API as of this writing, the native Android flow will simply not detect your app. You still have two working options. The first is each app’s own encrypted export and import format, most of which are not plain CSV files by default anymore. The second, and more tedious, option is manually recreating passkeys one at a time on each site, since passkey private keys genuinely cannot be exported in a portable, cross-vendor format the way a password string can.

For passwords specifically, most non-participating managers still support a standard export you can import elsewhere. Check the export option inside your current app’s settings menu before assuming you need to retype anything. For passkeys tied to a non-participating manager, plan on visiting each site’s security settings individually, removing the old passkey, and creating a fresh one inside your new manager. It is slower, but it is the only method that works until your provider ships support for the newer flow. Google’s post left the door open for additional partners without a timeline, so check back periodically if your app is not yet supported.

If you specifically use Samsung Pass, reporting on the Credential Manager rollout suggests Samsung is in the process of adopting the transfer APIs during September 2026, but it had not appeared as a confirmed, end-user-visible launch partner in Google’s own announcement or in TechCrunch and 9to5Google’s coverage at the time of publication. Treat Samsung Pass as a near-term candidate rather than a guaranteed option today, and check the app’s own changelog for confirmation before assuming the native flow will work. The same caution applies to any password manager built into a specific phone manufacturer’s ecosystem rather than distributed independently through the Play Store, since those integrations tend to lag behind third-party apps.

One more wrinkle worth planning around: browser-based password managers built into Chrome, Firefox, or Edge on desktop are a separate system from the Android app ecosystem this feature covers. If your actual goal is unifying passwords saved in a desktop browser with an Android password manager app, that is a sync setting inside the browser itself, not something this OS-level transfer feature touches. Google Password Manager happens to bridge both, since it is the same underlying service on Chrome and Android, but third-party managers generally require you to sign into the same account on both platforms rather than running a transfer between them.

Common Pitfalls That Break the Migration

• Starting the transfer before updating both apps. An out-of-date build on either side is the number one reason the option never shows up at all.
• Assuming CSV export still covers passkeys. It does not, and never really did, because passkey private key material is not designed to leave secure hardware in a portable text format.
• Uninstalling the old app immediately after the transfer. Do the spot checks first. Recovering an uninstalled app’s local vault after the fact is far harder than keeping it around for a week.
• Ignoring your screen lock requirements. The transfer requires biometric or PIN authorization inside the source app; if your screen lock is disabled or misconfigured, the authorization step will simply fail silently.
• Expecting unsupported apps to appear anyway. If your old or new manager is not one of the four launch partners, Android will not list it as a transfer option no matter how up to date it is.
• Migrating on a work-managed device without checking policy. Enterprise mobility management profiles can restrict cross-app credential transfer entirely, which looks identical to a bug from the user’s side.
• Forgetting that TOTP and authenticator codes are a separate migration. One-time passcodes stored in a dedicated authenticator app are not part of this transfer and need their own move, covered in our guide to setting up TOTP-based multi-factor authentication.

Verifying the Transfer Worked: What Success and Failure Look Like

A clean transfer produces a specific, checkable signature in the destination app. You should see the same total entry count as your old vault, give or take a few duplicates the app may flag automatically, and every passkey entry should show a working “sign in with passkey” option rather than a generic placeholder icon. Here is what a healthy post-transfer summary screen typically reports, based on the step sequence Google describes in its rollout documentation.

Transfer complete
Passwords copied: 214
Passkeys copied: 9
Items skipped: 0
Source: com.x8bit.bitwarden
Destination: com.dashlane.pass
Completed in: 6 seconds

If instead you see an “Items skipped” count greater than zero, open the old app and check which specific entries did not move. This usually points to a single malformed entry, often an old passkey tied to a site that has since changed its authentication requirements, rather than a systemic failure. Isolate and manually recreate just that entry instead of retrying the entire batch.

Troubleshooting: 8 Common Issues and How to Fix Them

For deeper debugging, adb’s logcat can surface Credential Manager errors that never make it to the app’s own UI, which is useful if you are troubleshooting on behalf of a less technical family member.

adb logcat | grep -i "CredentialManager"

Security Rationale: Why On-Device Transfer Beats Cloud-Mediated Migration

Some competing approaches to credential portability route data through a cloud relay, encrypting it in transit and decrypting it on the other end. That model is not unsafe by definition, but it does introduce a third party, the relay server, into a process that previously involved only your device. Android’s approach skips that hop entirely. The handoff happens between two apps running on the same physical phone, authenticated by your screen lock, with Google Play Services acting as the local broker rather than a network intermediary. Nothing about your vault contents needs to touch Google’s servers, or anyone else’s, for the transfer to complete.

This also explains a limitation that trips people up: you cannot migrate a vault from an old, broken, or already-uninstalled phone using this feature, because there is no cloud relay to fall back on. The source and destination apps both need to be alive and reachable on the same device at the same moment the transfer runs. If your old phone is gone, you are back to whatever cloud backup or recovery mechanism your password manager offers independently of this feature, which is a separate topic from the OS-level transfer covered in this guide.

Advanced Tips: Hardening Your Vault After the Move

Once the migration itself is done, treat it as an opportunity rather than a finished task. Switching password managers is one of the few moments you can audit your entire credential footprint at once, so it is worth spending an extra half hour on the following before you consider the job complete.

Rotate your master password on the new vault even if it matches your old one, since reusing the same master password across two apps briefly doubles your exposure if either provider is ever breached. Enable emergency access or account recovery inside the new app immediately, not weeks later, because this is the setting people forget most often right after a migration. If your new provider supports it, add a hardware security key as a second factor on the vault itself, a step we cover in more detail in our guide to setting up a FIDO2 hardware security key. Finally, review your passkey coverage across your most sensitive accounts and consider adding passkeys anywhere you are still relying on a password alone, since the FIDO Alliance’s 2026 State of Passkeys report puts global passkey usage at 5 billion active passkeys, evidence that the ecosystem has crossed from early adopter territory into mainstream use.

Building a Repeatable Migration Checklist for Multiple Devices

If you are helping a family member switch, or you manage a small team’s devices, doing this migration once is easy but doing it consistently across five or ten phones invites mistakes. The following checklist turns the steps above into something you can reuse, plus a short script that audits app versions across a batch of connected devices before you start any transfers.

#!/bin/bash
# audit-password-manager-versions.sh
# Run against each connected device before starting a bulk migration

for pkg in com.x8bit.bitwarden com.agilebits.onepassword com.dashlane com.google.android.gms; do
  version=$(adb shell dumpsys package "$pkg" | grep versionName | head -n 1)
  echo "$pkg -> $version"
done

android_release=$(adb shell getprop ro.build.version.release)
echo "Android release: $android_release"

Run this once per device before you begin, and hold off on any device that reports an Android release below 8 or a password manager package that returns no version at all, since that usually means the app is not installed or is running a version old enough to lack the transfer entry point. Pair the script output with this five-item checklist for each device you migrate:

• Both apps updated to their current Play Store release
• Encrypted backup exported and stored outside cloud sync
• Screen lock confirmed working before starting the transfer
• Post-transfer entry count matches the source vault, minus any intentional duplicates
• New app set as the default autofill service and confirmed with adb

Enterprise and Family Account Considerations

Shared and managed accounts add a layer the individual walkthrough above does not cover. On a work-managed Android device, IT administrators can restrict which apps are allowed to participate in Credential Manager transfers, and a blocked transfer on a managed device will look identical to a bug from the end user’s perspective, silent, with no error message. If you administer devices for an organization, coordinate the switch through your mobile device management console rather than asking employees to self-serve, and confirm your MDM policy explicitly allows the destination app before rolling this out at scale.

Family sharing plans behave a bit differently, since shared vault entries, like a household streaming login, may be owned by whichever family member originally created them. Test the transfer on one non-critical shared entry first before migrating an entire family vault, and confirm every family member’s device independently rather than assuming a single successful transfer on one phone means the rest will behave the same way. This matters more than it sounds, since stale or duplicated session credentials left behind after a partial migration can become an easy target if a device is later lost or compromised.

Why This Matters Beyond a Single App Switch

The broader story here is portability. Passwords have always been portable in a crude way, you could always retype one somewhere else, but passkeys were not, and that lock-in was becoming a real argument against adopting them at all. A security upgrade that traps you with one vendor is a weaker upgrade than one that does not. By building credential portability directly into the OS rather than leaving it to each app to solve independently, Google is addressing the single biggest practical objection users raised about passkeys: what happens if I want to leave. With four major providers on board at launch and, per Google’s own statement, more expected to follow, this feature looks less like a one-off convenience update and more like infrastructure the rest of the password manager market will need to match.

It also shifts the competitive dynamics between password manager vendors in a subtle way. Historically, switching costs were a real, if rarely discussed, part of how these companies retained subscribers. A user who spent an afternoon manually re-entering three hundred logins into 1Password was unlikely to repeat that ordeal a year later just because Bitwarden shipped a cheaper family plan or Dashlane added a feature they wanted. Once switching takes a few minutes instead of a few hours, that retention lever weakens, and vendors will need to compete more on price, features, and trust than on the sheer friction of leaving. That is a better outcome for users even if it makes the market slightly more volatile for the companies involved.

The timing also lines up with a broader industry shift toward passwordless authentication that has been building for several years. As passkey adoption climbs, the argument for password managers as a category shifts from “a tool that remembers strings for you” to “a tool that manages your cryptographic identity across every service you use.” A feature like this one, which treats passkeys as portable, first-class citizens rather than a bolt-on to the older password model, is a reasonable signal that Google expects that shift to keep accelerating through the rest of 2026 and beyond.

For a broader look at how identity and account protection are evolving across the industry, see our guide to phishing-resistant MFA setup and our roundup of 2026 cybersecurity threats.

Frequently Asked Questions

Do I need to root my phone to use the new Android password manager transfer?
No. This is a standard Android feature built into Credential Manager and Google Play Services, and it works on unmodified, non-rooted devices running Android 8 or later.

Will my passwords be exposed as a plaintext file during the transfer?
No. Google’s announcement describes the transfer as happening directly between encrypted vaults, coordinated by Android, without generating a CSV or other plaintext export file at any point.

Can I transfer from Proton Pass or NordPass right now?
Not through the native OS flow as of this writing. Neither app appears in Google’s launch coverage. Use each app’s own encrypted export feature as a fallback, or wait for a future update, since Google has said more partners are expected.

Does the transfer move my saved authenticator codes too?
No. TOTP codes stored in a separate authenticator app are not part of this password manager transfer and need to be migrated independently through that app’s own account transfer process.

What happens if I lose connection partway through a transfer?
Force-stop both apps, confirm Google Play Services is fully updated, and retry the transfer on a stable connection. Google’s own guidance frames the transfer as completing in a matter of seconds once authorized, so a stalled transfer usually indicates it needs to be restarted rather than resumed.

Is this feature available on iPhone as well?
This specific system-level transfer flow is an Android feature built on Android’s Credential Manager. Apple has its own separate mechanisms for passkey and password portability on iOS that follow a different implementation.

Should I keep my old password manager installed after switching?
Yes, for at least a week or two. Keep it installed and signed in as a passive backup until you have manually verified your most important accounts, especially any with passkeys, work correctly in the new app.

How many passwords and passkeys can I move in a single transfer?
Google has not published a hard cap, and Ars Technica’s reporting on the rollout does not mention entry limits. For very large vaults, expect the review step to take longer simply because there is more to check, not because the transfer itself is restricted.