A synced passkey and a device-bound passkey can lead to different recovery dependencies. Choose by asking where the credential can exist, what remains available after a device is lost, and who controls the route back into the account. The label alone cannot answer all three questions.

Conceptual illustration of device synchronization beside a separate security key

Conceptual illustration, not an actual product screen or experimental result.

Separate the credential from the device

FIDO distinguishes synced passkeys from credentials bound to one device. FIDO

That is a question about the credential, not simply whether you hold a phone or a physical key. W3C distinguishes backup eligibility from current backup state: permission to back up does not establish that a backup currently exists. Its authenticator attachment categories describe how an authenticator connects to a client. W3C WebAuthn

In a hypothetical account inventory, give each entry a service name, credential location and what you have actually checked. “On my laptop” is useful as a starting observation, but does not yet explain whether the credential can become available elsewhere. Leave the backup column unknown until the provider's information or a supported check resolves it.

Name the provider recovery dependency

FIDO's March 2022 specialist paper explains that synced credential availability and security depend on the underlying provider account and its process for restoring access after all old devices are lost. This is architectural analysis, not a current product recovery promise. FIDO paper

Consider a hypothetical move in which your only phone disappears and your laptop remains. Ask separately whether the laptop already has a usable credential and whether you can regain access to the provider. These questions may have different answers. Do not call an untested provider recovery option a working backup simply because its name appears in a settings screen.

For this exercise, write the procedure's official location, the prerequisites you understand and the parts you have not verified. Record whether the instructions assume another signed-in device. This produces a dependency map, rather than a list of reassuring product names.

Distinguish another login from recovery

NIST's government guidance encourages two separate means of authentication. It distinguishes binding another authenticator while an existing one works from account recovery after control is lost; recovery can involve codes, contacts or renewed identity proofing, and may take time. NIST event management

In your hypothetical inventory, put an already registered spare authenticator in a different row from “contact support.” A spare that has been registered for the service is a different proposition from a proposed registration you hope to perform later. Likewise, a copy available through the same provider should prompt a question about shared dependencies, rather than an automatic assumption of independence.

Ask the service what its own recovery path requires. Avoid improvising a recovery sequence from unrelated providers' documentation. The map should identify decisions still to make, not pretend that every service permits the same alternatives.

Keep assurance claims in context

In NIST's government framework, syncing may support AAL2 subject to requirements, but conflicts with AAL3 non-exportability. These are authenticator assurance levels, not consumer product scores. Device-bound alone does not prove compliance. NIST assurance guidance

Phishing resistance concerns the authentication protocol's handling of impostor verifiers, not immunity for the entire account. NIST authenticator guidance

For a workplace account, ask which credentials policy accepts and who owns recovery. For a personal account, ask which routes you can maintain. A policy answer and a convenience preference address different needs; neither substitutes for checking the actual service.

Make the loss plan usable

Google's implementation explanation includes server checks of origin, relying-party identifier, challenge and signature. Browser success still needs server verification. Google implementation

For the hypothetical move, finish the map with actions: which official instructions to keep, which registered alternative to verify, and where to report a lost credential. Do not delete your only working method merely to simulate device loss. A plan should also say what remains uncertain and when to check it again. This is a planning example, not a production security checklist or a guarantee of recovery.

Sources