TL;DR: Synced passkeys copy the private key across devices through a cloud service, which expands the attack surface and enables bypass techniques such as JavaScript injection and signed assertion hijacking, according to Versasec’s analysis. Device-bound FIDO2 keys avoid that syncing risk by keeping the private key on a single hardware token.
At a glance
What this is: This is an analysis of why synced passkeys create a broader passwordless MFA attack surface than device-bound FIDO2 keys.
Why it matters: IAM and security teams need to understand the trust difference between synced and device-bound passkeys before treating passkeys as a uniform phishing-resistant control.
Context
Passkeys are meant to replace passwords with cryptographic authentication, but the security model changes when the private key is synchronised through a cloud service instead of staying on a single device. That distinction matters for identity governance because the control boundary moves from a hardware token to an ecosystem of synced endpoints.
For IAM programmes, the practical question is not whether passkeys are modern enough, but whether the deployment preserves device-bound assurance. Once the private key can be copied, the organisation has to treat the passkey estate more like a distributed credential system than a single-device authenticator.
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: Why do synced passkeys create more risk than many teams expect?
A: Synced passkeys shift trust to the cloud account, recovery process, and browser environment that protect them. That means account takeover, recovery abuse, or browser compromise can undermine the credential without breaking the underlying FIDO standard. The risk is architectural, because the weakest recovery path often defines the real assurance level.
Q: What breaks when passkey authentication depends on a synced cloud path?
A: The assumption that one authenticator equals one physical trust anchor breaks down. Attackers can target the sync path, session, or local client rather than the cryptographic algorithm itself. That means the control no longer behaves like a single-device credential with deterministic containment.
Q: When should organisations require hardware-bound keys instead of synchronised passkeys?
A: Require hardware-bound keys for privileged access, regulated operations, and any workflow where origin assurance and device binding matter more than convenience. Synchronised passkeys can work for lower-risk user populations, but they should not be treated as equivalent when the business impact of account compromise is high.
Technical breakdown
Synced passkeys and the cloud sync trust boundary
A passkey is a public and private key pair used for authentication. In a device-bound model, the private key stays on one hardware token or secure device and never leaves it. In a synced model, the private key is replicated through a cloud service so users can sign in from multiple devices. That replication creates a broader trust boundary because compromise of the sync ecosystem, a connected endpoint, or the local session can weaken the original hardware assurance. The authentication ceremony may still look phishing-resistant, but the underlying credential portability changes the threat model.
Practical implication: Treat synced passkeys as a distributed credential architecture, not as the same control as a hardware-bound authenticator.
JavaScript injection and signed assertion hijacking against passkeys
Versasec cites research and demonstrations showing that attackers can target the syncing mechanism rather than the cryptography itself. JavaScript injection can manipulate the browser session, while signed assertion hijacking can abuse authentication material during the login flow. These attacks do not break asymmetric cryptography directly. Instead, they exploit the runtime environment around the passkey, where the user, browser, device, and sync service all participate in the trust chain. The key lesson is that stronger crypto does not remove the need to secure the session and the endpoint that carries the assertion.
Practical implication: Harden browser sessions and endpoint controls wherever passkey authentication depends on a synced runtime path.
Device-bound FIDO2 keys as a narrower identity control
Device-bound FIDO2 keys keep the private key on a single physical token, such as a USB key or smart card, and prevent export or synchronisation. That narrower model removes the cloud copy problem and sharply limits where the credential can be intercepted or replayed. It also aligns better with managed issuance, revocation, and lifecycle control because the identity artefact remains anchored to one device. For organisations that want passwordless MFA without expanding the credential footprint, the architectural difference is not cosmetic. It is the difference between one protected secret and many replicated ones.
Practical implication: Prefer device-bound keys where you need a tighter credential footprint and more deterministic revocation.
Threat narrative
Attacker objective: The attacker wants to impersonate a legitimate user and gain access through a passkey flow that was assumed to be phishing-resistant.
- Entry begins when an attacker reaches the browser or client session that participates in synced passkey authentication, rather than attacking the cryptography directly.
- Escalation occurs when the attacker exploits the sync path or assertion flow to capture usable authentication material through techniques such as JavaScript injection or signed assertion hijacking.
- Impact is impersonation of the user across trusted devices, which can turn a passwordless sign-in flow into a broader account takeover path.
Breaches seen in the wild
- Twilio 0ktapus breach 2022: SMS phishing of employees exposed 209 Twilio customers and 1,900 Signal users, part of the 0ktapus campaign against 130+ firms.
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
Synced passkeys create identity portability that changes the control boundary. Passwordless MFA is strongest when the authenticator remains bound to one device, one secure element, and one revocation path. Once the private key is synchronised, the organisation is no longer governing a single credential artefact but a replicated trust chain across endpoints and cloud services. The practical implication is that passkey policy has to distinguish portability from assurance, not treat them as the same thing.
Device-bound assurance is the named concept that matters here. A device-bound passkey keeps the private key on a single token, which preserves the assumption that the authenticator can be tied to one physical trust anchor. Synced passkeys break that assumption by design because the secret must exist in more than one place. That is why the control question is not whether passkeys are phishing-resistant in principle, but whether the deployment preserves a non-exportable private key.
Browser-session abuse becomes part of the authentication threat model. When login depends on a synced passkey path, attackers can target the surrounding session rather than the cryptographic primitive. JavaScript injection and signed assertion hijacking illustrate that authentication assurance can be weakened by the runtime environment even when the key material itself is protected. The implication for practitioners is that passwordless MFA cannot be evaluated only at the identity provider layer; endpoint and browser trust now matter.
Credential lifecycle governance must follow the authenticator model. A cloud-synced passkey estate behaves more like a distributed secret than a single hardware credential, which complicates issuance, revocation, and recovery assumptions. That creates a governance gap when teams assume all passkeys can be administered the same way. For identity programmes, the choice between synced and device-bound keys is a lifecycle decision, not just a user-experience choice.
Phishing resistance is not a binary label. The article reinforces a broader pattern: a control can remain resistant to classic password phishing while still becoming more exposed to sync-layer abuse, session interception, or endpoint compromise. Security teams should therefore evaluate passkeys by their actual deployment architecture, not by the label alone. The practitioner conclusion is to separate strong authentication from strong containment.
From our research library:
- eBay's passkey data shows 55-60% of passkey adoption happens on mobile, against around 20% on desktop.
What this signals
Device-bound keys remain the cleaner governance model for high-assurance authentication. The closer the authenticator stays to a single physical device, the easier it is to reason about issuance, revocation, and blast radius. Passkey programmes should therefore be segmented by assurance requirement, not rolled out as one uniform control.
Synced credentials should be assessed like distributed secrets. Once a private key can be replicated, the programme inherits the same governance questions that apply to shared or portable credentials: where it exists, who can recover it, and what runtime paths can expose it. That is an IAM design problem, not just an authentication feature choice.
For practitioners
- Differentiate passkey classes in policy Separate synced passkeys from device-bound FIDO2 keys in your identity standard so risk acceptance, revocation, and assurance levels are not treated as interchangeable.
- Inventory sync-dependent authentication paths Map where passkey authentication depends on cloud sync, browser sessions, or managed endpoint state so you can see where the trust boundary expands beyond one device.
- Require hardware-bound options for higher risk roles Use non-exportable FIDO2 hardware tokens for administrators, finance users, and other high-impact accounts that need tighter credential containment.
- Harden the browser and endpoint layer Apply session protection, endpoint monitoring, and browser isolation where authentication still relies on synced passkeys, because the attack surface shifts into the runtime environment.
Key takeaways
- Synced passkeys change the trust model by making the private key portable across devices through a cloud service.
- Device-bound FIDO2 keys keep the secret on one hardware token, which narrows the attack surface and improves containment.
- Practitioners should classify passkeys by assurance and lifecycle properties before treating them as a single passwordless control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-63 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Synced passkeys raise authentication assurance questions because the private key is no longer device-bound. |
| NHI-08 — Environment Isolation | Browser and endpoint runtime paths become part of the passkey trust boundary when sync is involved. | |
| Recommendation — Classify synced passkeys under NHI-04 and separate them from non-exportable hardware-bound authenticators. Use NHI-08 thinking to isolate high-risk authentication flows from compromised browser and endpoint contexts. | ||
| NIST SP 800-63 | SP 800-63B — Authentication and Lifecycle Management | The article is about authentication assurance and how the authenticator is bound to the device or sync ecosystem. |
| Recommendation — Apply SP 800-63B to distinguish authenticator binding strength and assurance requirements. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Passkey deployment changes how access is granted and governed across devices and sessions. |
| Recommendation — Use PR.AA-05 to align access assurance with the actual passkey deployment model. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | The bypass discussion centres on authentication being subverted through the surrounding flow, not the cryptography itself. |
| Recommendation — Treat passkey bypass paths as broken authentication conditions and validate the full login flow. | ||
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.
- Signed Assertion Hijacking: Signed assertion hijacking is an attack pattern that abuses the authentication assertion or login flow after the user has initiated passkey-based sign-in. It targets the runtime path around the authenticator, not the underlying asymmetric cryptography, and can enable user impersonation.
- Phishing-Resistant MFA: Phishing-resistant MFA uses authentication factors that cannot be easily replayed, intercepted, or socially engineered. In regulated environments, this usually means device-bound or cryptographic methods rather than push prompts or SMS codes, because the control must hold up under realistic attack conditions.
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on July 11, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org