TLDR
Even if you don’t learn anything else from this part, if your organization is evaluating passkey deployment, it’s not safe to deploy synchronized passkeys.
Synchronized passkeys inherit risk from cloud accounts and the recovery processes that protect them, posing a significant risk to businesses. Adversary-in-the-middle (AiTM) kits can force authentication fallbacks that bypass strong authentication altogether. Malicious or compromised browser extensions can hijack WebAuthn requests, manipulate passkey registration or sign-in, and drive autofill to leak credentials or one-time codes. Device-bound passkeys in hardware security keys provide higher assurance and greater administrative control than synchronized passkeys, making them a must-have for enterprise access use cases.
Risks of synced passkeys
Synchronized passkey vulnerability
A passkey is a credential stored in an authentication system. Some are device-dependent, while others are synced across devices through consumer cloud services like iCloud or Google Cloud. Synchronization improves ease of use and recovery in low-security consumer scenarios, but moves the trust boundary to cloud accounts and recovery workflows. Both FIDO Alliance and Yubico have issued important recommendations for enterprises to evaluate this split and prioritize device-dependent options for higher guarantees.
Operationally, synchronized passkeys expand the attack surface in three ways:
Cloud account takeover and recovery exploits can allow new devices to authenticate, compromising the integrity of credentials. If a user uses a personal Apple iCloud account to log in to their corporate device, the passkey created may be synced to their personal account. This dramatically expands the attack surface beyond the corporate security perimeter. Help desk and account recovery are real control points for attackers, as they can copy the same protected keychain to a new, unknown, untrusted device.
Authentication downgrade attack
See “captured” session. (Image source: Proofpoint)
Proofpoint researchers have documented practical downgrades to Microsoft Entra IDs where phishing proxies impersonate unsupported browsers such as Safari on Windows, Entra disables passkeys, and prompts users to choose weaker methods such as SMS or OTP. The proxy then captures the credentials and the resulting session cookie and imports them to gain access.
This threat vector relies on webAuthnpasskey’s uneven operating system and browser support and identity provider (IdP) acceptance of weaker authentication methods for practical UX considerations. This is a classic man-in-the-middle attack (AitM) with policy steering. When a compatibility branch disables WebAuthn, the platform never reaches the WebAuthn ceremony, so WebAuthn origin bindings are not broken. The weakest authentication method determines the actual security.
WebAuthn instant mediation is a feature that allows sites to provide an alternative authentication method when WebAuthn is unavailable. While this is useful for UX, it can also be exploited by attackers to direct users to non-WebAuthn paths, if allowed by policy.
Browser-based security is vulnerable to extension and autofill threat vectors
SquareX researchers have shown that a compromised browser environment can hijack WebAuthn calls and manipulate passkey registration and sign-in. This technology does not break passkey encryption. It injects or intercepts browser-side processes, such as through malicious extensions or XSS bugs, to restart registration, enforce password fallback, or silently complete assertions.
Chrome has a documented extension API named “webAuthenticationProxy” that can intercept connected navigator.credentials.create() and navigator.credentials.get() methods and provide your own response. Although this functionality exists for remote desktop use cases, it demonstrates that extensions with appropriate permissions can reside in the WebAuthn path.
The extension also runs content scripts within the page context. This allows you to read and modify the DOM and perform user interface flows such as calling the Credentials API from your page.
An independent study presented at DEF CON describes DOM-based extension clickjacking that targets UI elements injected by password manager extensions. A single user click on a crafted page could trigger autofill or disclosure of stored data such as login, credit card, and one-time codes. Researchers report that passkey authentication can be exploited in some scenarios and list vulnerable versions across multiple vendors.
Device-bound credentials are the only effective enterprise solution
Device-bound passkeys are tied to a specific device, and private key generation and use typically occur on a secure hardware component. For enterprises, hardware security keys provide consistent device signaling, authentication, and an inventory and revocable lifecycle.
Guidance for enterprise-grade passkey programs
policy
Require phishing-resistant authentication for all users, especially those with privileged roles. Generate non-exportable credentials during enrollment and only accept device-bound authenticators that never leave the device. Credentials must be routed to secure hardware and verifiably associated with the physical device on which you attempt to log in. Eliminate all fallback methods such as SMS, voice calls, TOTP apps, email links, and push approvals. They exist to be exploited during social engineering and downgrade attacks. If a fallback exists, the attacker forces it. The only way is to be strong. Ensure universal operating system and browser support for phish-resistant device-bound credentials. Don’t offer an alternative – yes, this is possible. We would be happy to show you a demo using Beyond Identity’s identity defense platform. Complete protection requires universal coverage because only the weakest link is protected.
Browser and extension status
Enforce extension allowlisting on managed browsers. Prevent extensions that request webAuthenticationProxy, activeTab, or extensive content scripting permissions. Continuously monitor extension installation and usage trends for suspicious mass deletions or unexplained privilege escalations. Extension-level compromises are becoming indistinguishable from legitimate users. Strictly lock down browser behavior as well as endpoints.
Registration and recovery
Use a high-assurance authenticator as the root of recovery. Help desks, email inboxes, and call centers must not be able to bypass phish-resistant controls. Recovery is often an entry point for attackers. Eliminate social engineering vectors and enforce policy-compliant proofreading. Allows only enrollment of credentials bound to the device. During registration, capture authentication metadata such as device model and assurance level. Reject unrecognized or unverifiable authenticators. Trust begins with registration. If you don’t know who created the credentials, you can’t control access.
Device health and runtime protection
Bind the session to a trusted device context. Session cookies should not be portable artifacts. Runtime session enforcement requires tying identity to ongoing device state, not just initial authentication. Force continuous authentication. Require reauthentication or deny access if the device’s state, location, or security status changes. Login is not a hall pass. Because risk is dynamic, authentication must also be dynamic. Assume that weak factor authentication attempts should be blocked by default. Learn how Beyond Identity customers can instantly block identity attacks based on the simple fact that they are not strong credentials attempting to gain access.
what actually happens
Three characteristics define the architecture of an identity security system that provides uncompromising protection against identity, browser, and device-based attacks:
Credentials bound to the device: Credentials never leave the device. They cannot be exported, are hardware supported, and cannot be synced or played elsewhere. Continuous trust: Authentication never stops at login. This continues throughout the session in conjunction with posture signals from the device. Universal endpoint hygiene enforcement: All endpoints are in scope. Even unmanaged devices must be evaluated for risk posture and session integrity in real time.
conclusion
A synchronized passkey is not a force field suitable for defense. These improve usability for consumer use cases at the expense of enterprise access security.
See more in action in our upcoming webinar, “How attackers can bypass FIDO: Why synchronized passkeys fail and what to do instead.” Beyond Identity reviews how synchronized passkey failures occur and how leading security teams, including Snowflake and Cornell University, close these passes.
Even if you can’t attend, you can still receive the recording by registering!
Source link
