Android now has a route for moving passkeys between password managers

Changing password managers has long exposed an awkward split. Saved passwords could often leave through a file, although that file then had to be handled as a collection of account secrets. Passkeys were designed around cryptographic keys held by a credential provider, so moving them between providers was a much harder handover.

Android now has a route across that gap. Google’s June 2026 system-services notes say Google Password Manager can import and export passwords and passkeys with third-party password managers using the Credential Exchange standard. The useful word is “route”. This is not a promise that every manager, phone or account can complete the move today.

Google’s note confirms the new capability in Google Play services version 26.21, released on 1 June 2026. It does not name participating third-party managers, list a universal Android version or publish a complete consumer workflow on that page.

That makes the receiving manager as important as Google Password Manager. Credential Exchange describes a handover between credential-providing applications. If one application offers an export control but the other does not support the same exchange, the standard cannot manufacture compatibility on its own.

The FIDO Alliance’s current specification page shows why careful wording still matters. It lists Credential Exchange Format 1.0 as a Proposed Standard dated 9 March 2026. That format defines the structures used when credentials are passed or referenced between applications. The companion Credential Exchange Protocol, which defines how credentials move between providers, is still labelled a Working Draft on the same page.

This is real product progress attached to a standard that is still maturing. It is not yet a universal migration button. A reader considering a switch should look for current import and export documentation from both providers, rather than assuming that the presence of passkeys in each app means the pair can exchange them.

The distinction becomes clearer when the parts of a passkey are separated. Android’s developer documentation says a service keeps the public key, while the private key is stored by a credential provider such as a password manager. At sign-in, the provider uses the private key to sign a fresh challenge after the user consents through the device unlock. The private key is not sent to the website as a reusable password.

Credential Exchange concerns the relationship between credential providers. Cross-device authentication solves a different problem. Google’s supported-environments guide says a person can use a passkey stored on another phone by choosing that option, displaying a QR code on the device requesting the sign-in, then approving the request on the phone that already holds the passkey. That lets the credential stay where it is.

Choosing a provider is different again. The same Google guide says Android 14 or later lets users select other password managers as passkey providers in system settings. That choice determines where a new passkey may be created or which provider can supply a credential. It does not prove that an existing collection has been copied from the old manager.

Those three actions are easy to collapse into one vague promise about portable passkeys. They are better understood separately: choose where future credentials live, use an existing passkey from another device, or transfer a stored collection between compatible managers.

A transfer control is only the start of a migration. Password managers can hold passwords, passkeys and other record types, while websites decide which sign-in and recovery methods they support. An exchange may therefore face differences in credential type, account policy or provider implementation.

The practical evidence is the inventory after the transfer. Are the expected passwords and passkeys present in the destination? Can a sample of important accounts sign in through the destination provider? Does the old manager still contain credentials that were not accepted? Has a recovery method been checked before the source collection is removed?

Those are verification questions, not evidence that Credential Exchange is unsafe. They are what turns a product claim into an observable handover. FIDO’s earlier announcement framed the standard around transfers that are secure by default rather than credentials moving in the clear. The current Google release note brings that aim into Android’s system services, but it does not remove the need to confirm what each provider actually supports.

The change also does not make every website passkey-ready. It cannot repair a forgotten account, bypass a service’s recovery policy or convert a password into a passkey. It gives compatible credential managers a common route for records that already exist.

Passkeys are easier to accept when choosing one manager does not feel permanent. The ability to move them can reduce a practical form of lock-in, especially for people who want one credential manager across several operating systems or who are changing their security setup.

The sober interpretation is narrower than “passkeys are now fully portable”. Google Password Manager has added a standards-based exchange route. The FIDO format has reached Proposed Standard status, while the transfer protocol remains a Working Draft. Compatible providers still have to implement both ends, and users still need to verify the result.

That may sound less dramatic than a universal switch. It is also more useful. Password-manager portability is becoming a real handover that can be inspected, rather than a promise inferred from two apps using the same word.