Category: FIDO & Passkeys

Synced Passkey

Also known as: Multi-device passkey, Cloud-synced passkey

Simply put

A synced passkey is a passwordless sign-in credential whose private key is stored and copied ('synced') across a user's devices through a cloud service, password manager, or device keychain. Because the credential is available on multiple devices, a person can sign in from any of their devices rather than being limited to the single device where the passkey was first created. This differs from a passkey that stays permanently bound to one piece of hardware.

Formal definition

A synced passkey is a discoverable FIDO credential in which the private key is created, encrypted, and replicated to a cloud-based passkey provider (for example, a device platform keychain or a password manager) so it can be used across multiple devices associated with the same account. In contrast to a device-bound passkey whose private key never leaves the authenticator hardware, a synced passkey's key material is portable across the provider's ecosystem, which affects device visibility and recovery characteristics. Synced passkeys retain the phishing-resistant, public-key authentication properties of the underlying passkey model; the term describes the credential's storage and portability characteristics rather than a distinct protocol. Specific behavior, such as which providers are supported, how syncing is encrypted, and whether an environment permits synced versus device-bound passkeys, depends on the relying party configuration and the passkey provider, and enterprise platforms may allow administrators to restrict credential types.

Why it matters

Synced passkeys address one of the most persistent barriers to passkey adoption: the recovery and portability problem. A passkey whose private key never leaves a single authenticator delivers strong assurance, but it also means that losing or replacing that device can lock a user out of every account tied to it. By replicating the private key across a user's devices through a cloud provider, password manager, or device keychain, synced passkeys let a person sign in from any enrolled device and recover access when a device is lost, which materially improves usability for large user populations.

Crucially, synced passkeys retain the phishing-resistant, public-key authentication properties of the underlying passkey model. According to Microsoft's documentation, synced passkeys provide strong phishing resistance, whereas many traditional authentication methods offer no device visibility and remain susceptible to phishing. For identity teams evaluating passwordless rollouts, this means the security benefit of eliminating shared-secret credentials is preserved even as the credential becomes portable across an ecosystem.

The trade-off that identity and governance leads must weigh is where trust boundaries now sit. Because key material is portable across a provider's ecosystem rather than bound to a single piece of hardware, the security of the credential depends in part on the provider's syncing encryption, the strength of the account protecting the sync, and the recovery paths that provider exposes. Whether an environment should permit synced passkeys, device-bound passkeys, or both is a policy decision that depends on assurance requirements and the relying party's configuration.

Who it's relevant to

IAM engineers and identity architects

Teams designing passwordless authentication need to decide whether to permit synced passkeys, device-bound passkeys, or both, and to configure relying party policy accordingly. The portability of the private key across a provider's ecosystem changes device visibility and recovery characteristics compared with hardware-bound credentials, so these trade-offs should be modeled against the assurance level a given application requires.

Security and compliance leads

Because synced passkeys retain phishing-resistant, public-key authentication while introducing dependence on the provider's syncing and recovery model, compliance teams evaluating authentication assurance should account for where key material resides and how it is protected. In enterprise platforms, administrators may be able to restrict credential types, which is relevant when policy demands device-bound credentials for higher-assurance scenarios.

System administrators and helpdesk teams

Synced passkeys reduce lockout and re-enrollment burdens because a credential saved in a credential manager or device keychain becomes automatically available on a user's other enrolled devices. Administrators should understand which providers are supported in their environment and how syncing behaves so they can support users and set appropriate expectations about recovery.

End users adopting passwordless sign-in

For users, a synced passkey means they can sign in from any of their devices rather than only the device where the passkey was first created, and it offers a recovery path if a device is lost. The credential is saved securely in a trusted password manager or device keychain and copied across devices through the provider's cloud service.

Inside Synced Passkey

Passkey (FIDO2/WebAuthn credential)

A synced passkey is a discoverable FIDO2 credential based on WebAuthn and the CTAP specifications, consisting of an asymmetric key pair where the private key is used to sign authentication challenges and the public key is registered with the relying party. It provides phishing-resistant authentication as an inherence- or possession-based factor depending on how the authenticator is unlocked.

Cloud synchronization

The distinguishing characteristic of a synced passkey, as opposed to a device-bound passkey, is that the private key material is backed up and replicated across a user's devices through a credential provider's cloud service (for example a platform vendor's keychain or a third-party password manager). This typically enables recovery and multi-device availability without re-registering the credential.

Credential provider / sync fabric

The service that stores, encrypts, and propagates the passkey across devices, usually tied to a user's platform account. The security of the synced credential depends significantly on the protection of this account and the provider's encryption of the synced material, which varies by provider and configuration.

Relying party (RP) and RP ID

The service or application that registers the public key and later verifies signed assertions during authentication. The passkey is scoped to an RP ID, which contributes to its phishing resistance because the authenticator will only produce assertions for the matching origin.

Authenticator and user verification

The component that stores or accesses the private key and performs user verification, typically via a knowledge factor (PIN) or inherence factor (biometric) to unlock use of the key. User verification unlocks the credential locally and is distinct from the possession of the synced key itself.

Common questions

Answers to the questions practitioners most commonly ask about Synced Passkey.

Is a synced passkey the same as a device-bound passkey?

No. Both are FIDO2/WebAuthn credentials, but they differ in how the private key is handled. A device-bound passkey has its private key generated and confined to a single authenticator (for example, a hardware security key or a device's secure element) and cannot be exported. A synced passkey has its private key replicated across a user's devices through a provider's credential manager (such as a platform or password-manager cloud), so it becomes usable on multiple devices. They are not interchangeable, and the distinction matters for assurance decisions.

Does using a synced passkey make my authentication less secure than a password?

A synced passkey remains a public-key credential that is phishing-resistant and not vulnerable to credential replay or server-side password database theft in the way a shared secret is. The relevant trade-off is not passkey versus password but synced versus device-bound: syncing broadens the trust boundary to the provider's account and sync infrastructure, whereas a device-bound key keeps the private key on a single authenticator. Which is appropriate depends on your risk tolerance and assurance requirements, not on a blanket claim that synced passkeys are weak.

How can a relying party tell whether an authentication used a synced or device-bound passkey?

During WebAuthn registration and authentication, signals such as attestation data and, in many implementations, backup-eligibility and backup-state indicators can inform a relying party about whether a credential is capable of being synced. Availability and reliability of these signals vary by platform, authenticator, and configuration, so relying parties should not assume a definitive determination is always possible. Treat this as a policy input to be evaluated per deployment rather than a guaranteed capability.

Should I allow synced passkeys for high-assurance or privileged access?

This depends on your assurance policy. Some organizations restrict privileged or high-assurance flows to device-bound authenticators to keep the private key on a single controlled device, while permitting synced passkeys for broader workforce or consumer convenience. In many deployments a tiered approach is used, combining passkey type signals with step-up authentication for sensitive operations. Define the acceptable authenticator characteristics in policy rather than treating all passkeys uniformly.

What account recovery considerations apply when relying on synced passkeys?

Because a synced passkey's availability is tied to the user's provider account and sync ecosystem, recovery planning typically centers on that dependency. If a user loses access to their sync provider account, they may lose access to the synced credentials, so relying parties usually need a defined re-enrollment or alternate authentication path. Avoid designing recovery flows that reintroduce phishable fallbacks that undermine the passkey's phishing resistance.

How does synced passkey use affect the sharing of a credential across users?

Syncing is designed to replicate a credential across a single user's own devices, but some provider ecosystems also offer mechanisms to share passkeys with other people. Whether this is possible and how it works depends entirely on the provider and configuration. Organizations concerned about a credential being usable by someone other than the enrolled individual should evaluate the specific provider's sharing behavior and reflect it in their access and identity governance policies.

Common misconceptions

A synced passkey and a device-bound passkey are the same thing.

Both are FIDO2/WebAuthn credentials, but they differ in how private key material is handled. A synced passkey is replicated across devices through a credential provider's cloud, whereas a device-bound passkey's private key typically never leaves the hardware authenticator. This distinction affects recovery, portability, and the threat model, so they should not be treated as interchangeable.

Because passkeys use public key cryptography, a synced passkey is authenticating the user directly by itself.

The signed WebAuthn assertion proves possession of the private key to the relying party, and local user verification (PIN or biometric) unlocks that key on the device. Whether this constitutes strong user authentication depends on user verification being enforced and on the security of the syncing account; the credential alone demonstrates possession, and the assurance level depends on configuration.

Syncing a passkey to the cloud exposes the user's private key to the provider or weakens phishing resistance.

Phishing resistance derives from the origin/RP ID binding of the WebAuthn credential and is generally preserved regardless of syncing. The confidentiality of synced key material depends on how the provider encrypts and protects it, which varies by provider; syncing changes the recovery and account-compromise threat model rather than removing the credential's origin-binding property.

Best practices

Decide between synced and device-bound passkeys based on your assurance requirements; where the highest assurance or non-repudiation is needed, consider requiring device-bound authenticators, since synced credentials inherit the security posture of the syncing account.

Enforce user verification (PIN or biometric) in your WebAuthn relying party configuration rather than relying on possession of the synced credential alone, and confirm the authenticator flags indicate user verification was performed.

Protect and harden the credential provider account that syncs passkeys, including strong authentication on that account, because compromise of the sync account can extend to the passkeys it holds.

Register more than one authenticator per user and define account recovery paths that do not silently fall back to weaker, phishable factors, so that loss of a synced credential does not force insecure recovery.

Validate the origin and RP ID binding server-side on every authentication to preserve phishing resistance, and verify signatures against the registered public key.

Document, in your IGA and access policies, which authenticator types are acceptable for which resources, treating passkey assurance level as an authentication policy decision separate from authorization and access provisioning.