Synced passkeys work for most users, but not every role

At a glance

What this is: This article explains the security and assurance difference between synced and device-bound passkeys, and why the private key’s portability determines where each belongs.

Why it matters: IAM teams need this distinction because passkey type, recovery flow, and fallback authentication must align to role risk, device control, and assurance level.

Context

Passkeys shift authentication away from shared secrets and toward device-backed cryptographic proof. The key governance question is not whether passkeys are phishing-resistant, but whether the private key can move, be recovered, or be shared.

For identity programmes, that difference changes assurance, recovery, and rollout policy. Synced passkeys fit some workforce and customer use cases, while device-bound passkeys are a better fit for privileged access and tightly controlled environments.

Key questions

Q: How should security teams decide where to use syncable passkeys versus device-bound keys?

A: Use syncable passkeys where usability and scale matter most, but keep device-bound keys for privileged access, regulated workflows, and any application where the organisation must preserve a stronger device-to-credential binding. The decision should be based on assurance requirements, not user preference alone. If the workflow tolerates credential portability, syncable passkeys are reasonable. If it does not, hardware binding should stay mandatory.

Q: What breaks when passkey recovery is not governed properly?

A: The programme falls back to the weakest legacy recovery path, which attackers often target first. If help-desk verification, device replacement, or fallback login is inconsistent, the user can still be phished or socially engineered even when the primary login is passkey-based.

Q: Why do privileged accounts usually need device-bound passkeys?

A: Privileged accounts need the strongest practical binding between the authenticator and the device or token carrying it. Device-bound passkeys prevent export, reduce account recovery exposure, and fit better with attestation and managed-device controls. That makes them more suitable for administrators, remote critical systems, and other high-impact access paths.

Q: How do managed devices change passkey governance for the workforce?

A: Managed devices let identity teams pair passkeys with a known hardware and policy boundary, which makes synced credentials safer for some staff but still unsuitable for others. Once users operate on shared workstations, personal cloud accounts, or unmanaged endpoints, the passkey policy has to tighten or shift to device-bound authentication.

Technical breakdown

Why key portability changes passkey assurance

A passkey is a FIDO2 key pair, where the service stores the public key and the user controls the private key. Device-bound passkeys generate that private key inside one device or secure element and do not export it. Synced passkeys copy the private key through a cloud sync service to other devices, which improves usability but adds a second trust boundary. The authentication strength therefore depends not only on the cryptography, but on the security of enrolment, recovery, and the sync account itself.

Practical implication: decide passkey type by the trust boundary you can actually govern, not by the convenience of cross-device sign-in.

Why recovery and fallback paths are the weak point

The cryptography of passkeys is not the usual failure point. Attackers target the surrounding process: account recovery, device enrolment, and any phishable fallback that remains enabled. If a user can recover a synced passkey through a weaker channel, the recovery path becomes the real authentication path. That is why assurance collapses when SMS, email links, or unsupported browser fallbacks remain available for high-risk accounts. The control problem is not the key pair itself, but the weakest re-entry route into the identity record.

Practical implication: treat recovery and fallback channels as part of authentication policy and remove weak paths from high-risk groups.

Why managed accounts matter for workforce passkeys

For enterprise use, where the passkey lives matters as much as how it is generated. NIST’s guidance ties synced passkeys to AAL2 conditions and requires agency-managed accounts on managed devices for US federal staff. That means a personal cloud account is not an acceptable home for a work credential when the credential supports regulated or privileged access. Device-bound keys remain the cleaner model when the role demands non-exportable credentials, strong attestation, or a hard link to a specific workstation or token.

Practical implication: align passkey storage to the account type and device ownership model before extending passkeys to workforce authentication.

Threat narrative

Attacker objective: The attacker wants to bypass phishing resistance by exploiting the trust boundary around recovery, fallback, or synced account enrolment.

1. Entry begins with enrolment or account recovery, where an attacker can target the sync service or a phishable fallback instead of the passkey itself.
2. Credential access occurs when the weaker recovery path or fallback method yields a usable login, even though the passkey cryptography remains intact.
3. Impact follows when the attacker reuses the recovered account against higher-value services that assumed passkey strength alone was sufficient.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Passkey policy is now an assurance policy, not a login preference. The real decision is which roles can tolerate a recoverable private key and which roles require an uncompromisable authenticator. Synced passkeys increase usability, but device-bound keys preserve a stronger assurance boundary for privileged and regulated access. Practitioners should stop treating passkey rollout as a single enterprise standard and instead define assurance tiers by role.

Recovery has become the new credential lifecycle risk. A synced passkey is only as trustworthy as the sync account, the device enrolment path, and the identity proofing that supports replacement. That is an NHI-style lifecycle problem applied to human authentication, because the credential’s control plane now extends beyond the device. The implication is that recovery processes must be governed with the same rigor as issuance and revocation.

Weak fallback methods erase the value of phishing-resistant authentication. If SMS, email links, or browser downgrade paths remain available for sensitive groups, the organisation has preserved an easier attack path behind a stronger front door. The passkey itself may still be secure, but the authentication stack is not. Security teams should treat fallback removal as part of the passkey programme, not as a later hardening task.

Managed-device context is the hidden control that decides where synced passkeys fit. On shared workstations, personal cloud accounts, or unmanaged endpoints, synced credentials create governance ambiguity that device-bound tokens avoid. That matters for control rooms, healthcare stations, administrators, and other roles where the user is not the only variable. The practitioner conclusion is simple: the more constrained the environment, the more the passkey should remain physically bound to the device or token.

Device-bound passkeys remain the clearest fit for high-assurance enterprise access. They reduce recovery complexity, narrow the trust surface, and align better with attestation and privileged workflows. That does not make synced passkeys wrong, but it does make them role-dependent rather than universal. Identity architects should design passkey policy around assurance requirements, not around a single convenience default.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• eBay's passkey data shows 55-60% of passkey adoption happens on mobile, against around 20% on desktop.
• Read next: Passwordless and Passkeys Guide

What this signals

Passkey assurance is now a lifecycle choice. Identity teams should map every passkey use case to an assurance tier before rollout, because the credential type, recovery route, and device state all shape the real control boundary. What looks like a login preference is actually a governance decision about where trust can move and where it must stay fixed.

Fallback removal is the hardening step most programmes delay. As long as phishable recovery and downgrade paths remain open, passkeys only reduce attack surface instead of closing it. Organisations that want meaningful improvement need to govern the whole authentication path, not just the primary factor.

Device-bound credentials still matter wherever shared or unmanaged endpoints exist. Shared stations, control rooms, and privileged access workflows create conditions where portability becomes a liability rather than a convenience. That makes passkey policy part of endpoint governance as much as identity governance.

For practitioners

• Segment users by assurance requirement Classify accounts into customer, workforce, privileged, shared-workstation, and restricted-device groups before assigning synced or device-bound passkeys.
• Remove weak fallback methods Disable SMS, email links, and other phishable fallbacks for admin, critical-system, and regulated-access groups so recovery does not undercut passkey strength.
• Treat recovery as authentication Require identity re-checks and a second authenticator before issuing replacement credentials, because recovery now functions as part of the login path.
• Use device-bound keys for privileged access Reserve non-exportable passkeys for administrators and remote critical-system access, where attestation and device control materially reduce compromise risk.

Key takeaways

• Synced passkeys improve usability, but their assurance depends on the sync account, recovery path, and device trust boundary.
• Device-bound passkeys remain the better fit for privileged access and other roles that need non-exportable credentials.
• Passkey programmes fail when weak fallback methods survive alongside strong authenticators, because the weakest route still defines the login risk.

Key terms

• Synced Passkey: A synced passkey is a FIDO credential that can be replicated across multiple devices through a cloud account and recovery system. It can improve usability, but it also shifts trust from a single device to the sync provider, recovery workflow, and account protections surrounding the credential.
• Device-Bound Passkey: A device-bound passkey is a FIDO credential tied to one physical device and generally stored in hardware-backed secure components. The value for enterprise security is lifecycle control, because the credential is easier to inventory, constrain, and revoke without relying on cloud sync paths.
• Phishing-Resistant Authentication: Phishing-resistant authentication proves identity without relying on a user to approve a prompt or reveal a reusable secret. It typically binds access to a device, key, or cryptographic proof that an attacker cannot easily reuse or coerce. This approach reduces reliance on human judgment at login time.
• Authentication recovery: Authentication recovery is the process used when a user cannot complete primary sign-in and needs access restored. It matters because recovery pathways can be weaker than the main authentication stack, especially for privileged accounts, and attackers often target those fallback controls when they are under-governed.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.