Passkey portability is a provider capability, not a guarantee

01 · decision point

Separate syncing from moving between providers

Syncing makes a passkey available on devices connected to the same credential provider. It does not, by itself, establish that the credential can leave that provider. Migration is a different event in which an exporting manager, an importing manager, and often the operating system coordinate an authorized transfer. A passkey that works on a phone and laptop may still be non-exportable if both devices rely on one provider's sync fabric.

Device-bound credentials create another case. A hardware security key or platform authenticator may hold private key material that is intentionally not exportable. That can be a security property, not a defect. Portability planning therefore begins with an inventory: identify the relying-party account, where each passkey is stored, which devices can use it, whether another authenticator is registered, and whether the provider currently exposes an authenticated import or export flow.

02 · decision point

Know what the credential-exchange work standardizes

The FIDO Alliance Credential Exchange Format defines representations for credential data, including passkeys, while the related protocol work describes how participating providers can transfer that data securely. A format is not a promise that every device or manager has shipped the same user interface. Provider documentation and operating-system availability still determine whether a person can perform an exchange today.

Apple's Authentication Services documentation now exposes import and export management interfaces for participating credential-provider apps and identifies its importable passkey type as a representation of the FIDO format. That is strong evidence of an ecosystem pathway, but it does not make an older phone, browser extension, enterprise policy, or third-party manager compatible automatically. Check both endpoints and the operating-system version at the moment of migration.

03 · decision point

Use the relying party as the final source of truth

A password-manager screen can report that a credential was imported, but only the website or application that registered the public key can prove the migrated private credential works. Open the service independently, start a new sign-in, and select the imported passkey. Confirm the expected account and domain. If the service records authenticator names or last-used dates, inspect that list after the test.

Do not delete the original credential during the first successful test. Keep it until the destination has worked on the devices you actually use and another recovery route is documented. If the imported key fails, re-register a new passkey from an authenticated service session rather than uploading a private key file to an unverified converter. A normal service can issue another public-key credential without ever asking you to reveal private key material.

04 · decision point

Plan for mixed portfolios instead of one migration claim

Real vaults contain passwords, TOTP seeds, notes, attachments, passkeys, and organizational items with different export rules. A provider can support passkey exchange while excluding attachments or shared organization data. Another can export a JSON record whose passkey field is useful only when imported back into the same product. Read the specific export format and destination support rather than relying on a generic ‘export available’ label.

Migrate in cohorts. Begin with low-impact accounts that have a password or second passkey fallback, then verify important email and identity accounts individually. Keep an exception list for credentials that must be re-enrolled. The goal is not a perfectly clean old vault on day one; it is a verified destination and a controlled retirement process that never removes the only working authenticator.

Practical sequence

Run a passkey migration proof without exposing keys

1. 01

   Inventory each passkey's service, provider, devices, and independent recovery route.

2. 02

   Confirm that both managers and the operating system document the same exchange path.

3. 03

   Start export and import only inside the trusted applications, never through a converter website.

4. 04

   Complete a fresh relying-party sign-in with the imported passkey.

5. 05

   Record exceptions that require service-side re-enrollment.

6. 06

   Retain the original authenticator until the destination and backup have both been tested.

Original research element

Distinguish four meanings of ‘portable’

This original proof matrix ties each portability claim to a different verification event.

Continue on login.com

Related independent guidance

• Compare current provider documentation with a repeatable protocol
• Keep household recovery independent of one passkey provider
• Map the provider and device dependencies behind each credential
• Plan authenticator migration separately from passkey movement