Category: Identity & Access Management
Syncable Authenticators
Also known as: passkeys
Simply put
A syncable authenticator is a login credential, such as a passkey, whose underlying cryptographic key can be copied and synchronized across multiple devices, often through a cloud service. This lets a user sign in from more than one device without setting up a new credential on each one. In practice these credentials still require the user to unlock or activate them, for example with a biometric or PIN, before they can be used.
Formal definition
A syncable authenticator is a software or hardware cryptographic authenticator that permits its authentication private key to be cloned, exported, and synchronized to other storage or devices, typically via the cloud, rather than remaining bound to a single hardware device. NIST addresses these authenticators, commonly implemented as passkeys, in supplementary guidance to the Digital Identity Guidelines (SP 800-63B, revision 4 draft). Per that guidance, syncable authenticators require the user to input an activation secret to initiate the cryptographic authentication protocol; the syncable property distinguishes them from device-bound authenticators whose keys cannot be exported or cloned. The ability to copy authentication secrets to the cloud, and from there to additional authenticators, is the defining characteristic and also the primary consideration when evaluating them against assurance-level requirements.
Why it matters
Syncable authenticators, most commonly implemented as passkeys, matter because they resolve a long-standing tension between security and usability in authentication. Phishing-resistant credentials have historically been device-bound, meaning a user had to enroll each device separately and could lose access entirely if a single device was lost. By allowing the underlying cryptographic private key to be cloned and synchronized across devices, typically through a cloud service, syncable authenticators make strong, phishing-resistant authentication practical for everyday users at scale while preserving the requirement that the user unlock or activate the credential with a biometric or PIN.
Who it's relevant to
Security and identity leaders evaluating passkey adoption
Leaders deciding whether to deploy passkeys need to understand that the syncable property is both the usability benefit and the central risk consideration. Evaluating them against the organization's target assurance level, and against NIST's supplementary guidance where applicable, helps determine whether syncable or device-bound authenticators fit a given use case. This is a governance decision informed by the organization's threat model and maturity, not a purely technical toggle.
Virtual and fractional CISOs advising on authentication strategy
A vCISO or fractional CISO typically advises on and directs authentication strategy, including whether syncable authenticators meet an organization's assurance and risk requirements, and helps frame the trade-offs between usability and the expanded trust boundary introduced by cloud sync. Their role is strategy, governance, and executive-level guidance; hands-on implementation, tool administration, and identity operations generally fall outside the engagement unless explicitly contracted. Accountability for the resulting authentication decisions remains with the client organization.
Compliance and risk stakeholders mapping to standards
Those responsible for aligning authentication controls with guidance such as NIST SP 800-63B should note that the revision 4 draft addresses syncable authenticators explicitly and treats their exportability as a key factor in assurance-level evaluation. Supporting readiness against such guidance is distinct from guaranteeing that any particular authenticator satisfies a specific assurance level, which depends on how the credential and its sync mechanism are configured and governed.
Inside Syncable Authenticators
Syncable credential (passkey)
The private key or passkey that is permitted to be replicated across devices, most commonly implemented as a FIDO2/WebAuthn credential.
Synchronization fabric
The cloud service, platform keychain, or third-party credential manager that securely stores and distributes the credential to the user's other devices.
Syncing account and trust boundary
The user account securing the sync service, which becomes part of the credential's trust boundary because access to that account can grant access to the credential.
Device-bound contrast
The alternative model in which the private key is generated in and never leaves a single hardware authenticator, useful for understanding what distinguishes syncable authenticators.
Recovery mechanism
The account-based process that allows a user to regain access to a synced credential after device loss, which reduces lockout risk but ties recovery security to the sync account.
Common questions
Answers to the questions practitioners most commonly ask about Syncable Authenticators.
Does making an authenticator syncable mean it is no longer phishing-resistant?
Not inherently. A syncable authenticator can still rely on cryptographic credentials bound to the origin, which preserves resistance to phishing at the point of authentication. What syncing changes is where the private key material can exist: rather than being confined to a single hardware device, it can be replicated across a provider's ecosystem. That shifts part of the trust model from the device to the sync provider's account security and recovery process. The phishing-resistance of the authentication ceremony and the assurance of key isolation are separate properties, and this is a distinction an assessor would insist on keeping clear.
Is a syncable authenticator the same as a hardware security key?
No, and treating them as interchangeable is a common error. A device-bound hardware security key keeps the private key on the physical token and does not export it, which is why it is often preferred where the highest key-isolation assurance is required. A syncable authenticator is designed so that credentials can be copied across devices through a sync mechanism. Both can support the same authentication protocols and both can be phishing-resistant, but they differ in how key material is stored, replicated, and recovered. The right choice typically varies by the assurance level an organization needs and its risk tolerance.
How should we decide whether syncable authenticators meet our assurance requirements?
Start by mapping the requirement to the applicable guidance or policy your organization is subject to, since some frameworks distinguish between authenticators that are device-bound and those that can be replicated. Then assess the sync provider's account protections, recovery pathways, and any enterprise controls that let you constrain syncing. In many engagements the outcome depends on organizational maturity and the sensitivity of the systems being protected, so the decision is often segmented: syncable authenticators for broad workforce access and device-bound keys for privileged or high-risk roles.
Who should own the rollout of syncable authenticators, and where does accountability sit?
Rollout is typically coordinated by identity and access management or IT operations, while a security leader such as a virtual or fractional CISO can advise on policy, scope, and risk acceptance. It is important to separate this advisory role from accountability: the decision to accept the residual risk of a syncing model, and the organizational accountability for that decision, generally remain with the client organization and its officers. A vCISO can help structure the evaluation and document the rationale, but does not usually assume liability for the outcome unless a contract specifies otherwise.
What controls should we consider when enabling syncable authenticators for a workforce?
Consider whether your identity platform lets you enforce or restrict syncing by role, group, or risk tier, and whether you can require device-bound authenticators where higher assurance is needed. Review the recovery and re-enrollment process, since that is often where weaknesses concentrate. Establish logging and visibility so you can see which authenticators are in use and how they were registered. These controls depend heavily on client cooperation and the capabilities of the underlying platform, so scope should be defined before rollout.
What is commonly out of scope when a security advisor helps with syncable authenticator adoption?
An advisory or virtual CISO engagement typically focuses on strategy, policy, risk evaluation, and program guidance rather than hands-on operational tasks. That means activities such as administering the identity platform, performing the technical enrollment of users, or running day-to-day help-desk recovery are generally out of scope unless explicitly contracted. The value of the engagement often depends on defined scope, access to the relevant stakeholders, and the maturity of the existing identity program.
Common misconceptions
Syncable and device-bound authenticators are the same thing and offer identical assurance.
They differ in where the private key can live. A device-bound key never leaves its hardware, while a syncable key is replicated across devices, which expands the trust boundary and can affect how the authenticator is evaluated for assurance in guidance such as NIST's.
Because they are phishing-resistant passkeys, syncable authenticators eliminate account-related risk.
The security of a syncable credential depends in part on the account and cloud service that synchronizes it. If that syncing account is weakly protected, its exposure can undermine the credential, so the syncing account's own controls remain a critical consideration.
Adopting syncable authenticators is purely a technical rollout decision.
The trade-off between usability, recovery benefits, and an expanded trust boundary is a governance and risk-acceptance decision that typically belongs in authentication policy, not solely in engineering.
Best practices
Document in your authentication policy whether syncable or device-bound authenticators are acceptable for a given system, and align that decision with the assurance level you need.
Evaluate the security of the syncing account and its recovery mechanism as part of the credential's trust boundary, not just the credential itself.
Reserve device-bound authenticators for the highest-assurance use cases where limiting the private key to a single hardware device is a stated requirement.
Weigh the usability and lockout-reduction benefits of syncable passkeys against the expanded trust boundary explicitly, and capture the outcome as a documented risk acceptance.
Treat the choice as a governance decision by involving relevant stakeholders and recording it in policy rather than leaving it to individual engineering teams.
Confirm that account recovery paths for syncable credentials are protected to a level consistent with the sensitivity of the systems those credentials protect.