Compare password-manager passkeys with a repeatable test

01 · decision point

Define the capability before marking a product supported

A single ‘passkeys: yes’ cell hides at least four capabilities: saving a new passkey for another service, using it across supported devices, protecting the manager account with a passkey, and moving a stored passkey to another provider. Provider documentation can support one claim and explicitly limit another. This matrix records only the feature described by a current official page and leaves unverified cells unknown rather than filling them from reputation or an older review.

Platform scope also matters. Browser extensions, iOS credential-provider APIs, Android credential management, desktop apps, and web vaults can expose different functions. A manager may save and use a passkey on mobile but require a browser extension on desktop. Another may export passwords in CSV while passkeys require JSON or a native credential-exchange route. Always attach the claim to the platform and source date.

02 · decision point

Read export language with precision

1Password's current save-and-use page says that when exporting data with its desktop apps, users should create new passkeys on each website where a passkey was stored. That is not the same as a working cross-provider passkey export. Bitwarden documents stored passkeys in JSON exports and current native Credential Exchange Protocol routes on supported mobile platforms when the destination also participates. The format and transport path must both be compatible.

Dashlane's current export documentation describes Credential Exchange for moving passwords, passkeys, and verification codes between participating managers on supported iOS and Android devices. It separately warns that passkeys visible after reimporting a secure DASH file will not work. Proton documents saving and using passkeys across supported devices, but its general export page reviewed here does not establish cross-provider passkey export. That cell remains unverified instead of inferred.

03 · decision point

Run the same harmless protocol for every provider

Create a test account on a service that supports multiple authenticators and has a separate password or recovery route. Record the operating system, app version, browser or extension, manager plan, and policy state. Save a new passkey in the manager, sign out, and use it again. If testing sync, use a second device. If testing exchange, start only from the official source and destination apps and note the credential types the interface offers.

After import or restore, complete a fresh sign-in at the relying party. Inspect the service's authenticator list and confirm the expected account. Do not test with the only passkey for email, a domain registrar, financial access, or an administrator identity. Delete the test credential from the relying party after the run, then remove it from both managers. The result applies only to the recorded versions and should be retested after major updates.

04 · decision point

Choose a provider with recovery and exit in the same decision

Saving passkeys in a manager makes that manager's account recovery and device authorization part of every stored credential's availability. Evaluate how a new device is linked, whether a family or business administrator can recover the user, which second factors protect the vault, and whether emergency material exists outside it. A convenient sync model can be appropriate, but it should not be the only route to the email account that recovers the manager.

An exit plan is not only a downloadable file. It includes destination compatibility, organization-owned items, shared vaults, attachments, TOTP secrets, and passkeys that may require service-side re-enrollment. Keep the old manager active during the overlap, use a migration ledger, and rotate or remove the old authenticator at each service only after the new credential works. Price and autofill quality matter, but they do not substitute for a verified recovery and departure process.

05 · decision point

Maintain the matrix as dated evidence, not a permanent verdict

Provider documentation reviewed on 2026-08-20 can change with operating-system releases and new FIDO credential-exchange support. Each row below states the observed documentation boundary rather than awarding a winner. A missing or unverified capability can become available later; a beta pathway can also change. Recheck the linked primary page before migrating or buying a plan for one required feature.

For procurement, add the organization's actual browser, mobile OS, device management, SSO, shared-vault, and export requirements to the protocol. Require a witnessed proof on those platforms. Preserve screenshots or a non-secret test log, not exported passkey data. The useful matrix is the one tied to a reproducible test and a checked date, not the one with the most green checkmarks.

Practical sequence

Run the passkey manager verification protocol

1. 01

   Record provider, plan, operating system, app or extension version, browser, and policy state.

2. 02

   Create a harmless relying-party test account with an independent recovery method.

3. 03

   Save and use the test passkey once on the original device and once through the intended sync path.

4. 04

   Use only a provider-documented exchange or export route and record which credential types are offered.

5. 05

   Complete a fresh relying-party sign-in after import; do not accept an imported-vault label as proof.

6. 06

   Delete test data and schedule retesting after major provider or operating-system releases.

Original research element

Documentation status as checked on 2026-08-20

This original evidence matrix separates storage from verified cross-provider migration; it is not a product ranking.

Continue on login.com

Related independent guidance

• Understand the standards and proof behind passkey movement
• Test the recovery plan behind a household credential provider
• Include passkeys in an employee departure ledger
• Handle TOTP migration as a separate credential project