TLDR
Even if you take nothing else away from this piece, if your organization is evaluating passkey deployments, it is insecure to deploy synced passkeys.
- Synced passkeys inherit the risk of the cloud accounts and recovery processes that protect them, which creates material enterprise exposure.
- Adversary-in-the-middle (AiTM) kits can force authentication fallbacks that circumvent strong authentication all together
- Malicious or compromised browser extensions can hijack WebAuthn requests, manipulate passkey registration or sign-in, and drive autofill to leak credentials and one-time codes.
- Device-bound passkeys in hardware security keys offer higher assurance and better administrative control than synced passkeys, and should be mandatory for enterprise access use cases
Synced Passkey Risks
Synced passkey vulnerabilities
Passkeys are credentials stored in an authenticator. Some are device-bound, others are synced across devices through consumer cloud services like iCloud and Google Cloud. Sync improves usability and recovery in low-security, consumer-facing scenarios, but shifts the trust boundary to cloud accounts and recovery workflows. The FIDO Alliance and Yubico, have both issued important advisories for enterprises to evaluate this split and to prefer device-bound options for higher assurance.
Operationally, synced passkeys expand the attack surface in three ways:
- Cloud account takeover or recovery abuse can authorize new devices, which then erodes the integrity of the credential.
- If a user is logged in on their corporate device with their personal Apple iCloud account, then passkeys created could be synced to their personal accounts; this dramatically explodes the attack surface beyond enterprise security boundaries.
- Help desk and account recovery become the real control points that attackers target because they can copy the same protected keychain onto a new, unknown, and untrusted device.
Authentication downgrade attacks
 |
| See the “captured” session. (Image source: Proofpoint) |
Proofpoint researchers documented a practical downgrade against Microsoft Entra ID where a phishing proxy spoofs an unsupported browser, such as Safari on Windows, Entra disables passkeys, and the user is guided to select a weaker method, such as SMS or OTP. The proxy then captures credentials and the resulting session cookie and imports it to gain access.
This threat vector is reliant on webAuthnpasskey’s uneven operating system and browser support and the identity provider’s (IdP) acceptance of weak authentication methods in favor of a practical UX consideration. It is a classic adversary-in-the-middle (AitM) powered by policy steering. It does not break WebAuthn origin binding because the platform never reaches a WebAuthn ceremony when a compatibility branch disables it. Your weakest authentication method defines your real security.
Immediate mediation in WebAuthn is a feature that allows sites to offer an alternative authentication method when WebAuthn is not available. This is useful for UX but can also be abused by attackers to steer users toward non-webAuthn paths if policy allows them.
Browser-based security vulnerable to extension and autofill threat vectors
SquareX researchers showed that a compromised browser environment can hijack WebAuthn calls and manipulate passkey registration or sign-in. The technique does not break passkey cryptography. It injects or intercepts the browser-side process, for example, through a malicious extension or an XSS bug, to reinitiate registration, force a password fallback, or silently complete an assertion.
Chrome documents an extension API named “webAuthenticationProxy” that can intercept navigator.credentials.create() and navigator.credentials.get() methods once attached, then supply its own responses. This capability exists for remote desktop use cases, but it demonstrates that an extension with the right permission can sit in the WebAuthn path.
Extensions also run content scripts inside the page context, where they can read and modify the DOM and drive user interface flows, which include invoking credential APIs from the page.
Independent research presented at DEF CON described DOM-based extension clickjacking that targets the UI elements injected by password manager extensions. A single user click on a crafted page can trigger autofill and exfiltration of stored data such as logins, credit cards, and one-time codes. The researcher reports that in some scenarios, passkey authentication can also be exploited and lists vulnerable versions across multiple vendors.
Device-bound credentials are the only effective enterprise solution
Device-bound passkeys are tied to a specific device, typically with private key generation and usage conducted in secure hardware components. In enterprise, hardware security keys provide consistent device signals, attestation, and a lifecycle you can inventory and revoke.
Guidance for an enterprise-grade passkey program
Policy
- Require phishing-resistant authentication for all users, and especially those in privileged roles. Accept only device-bound authenticators that generate non-exportable credentials at registration and never leave the device. Credentials should be rooted in secure hardware and verifiably tied to the physical device attempting the login.
- Eliminate all fallback methods such as SMS, voice calls, TOTP apps, email links, and push approvals. These exist to be exploited during social engineering and downgrade attacks. If a fallback exists, an attacker will force it. Make the strong path the only path.
- Ensure universal operating system and browser support for phishing-resistant, device-bound credentials. Don’t offer alternatives – yes this is possible, we’re happy to show you a demo with Beyond Identity’s identity defense platform. Universal coverage is necessary for complete defense because you’re only as protected as your weakest link.
Browser and Extension Posture
- Enforce extension allowlists in managed browsers. Disallow any extension that requests webAuthenticationProxy, activeTab, or broad content script permissions.
- Continuously monitor extension installs and usage trends for suspicious mass removals or unexplained permission escalations. Extension-level compromise is increasingly indistinguishable from a legitimate user. Lock down browser behavior as tightly as you would an endpoint.
Enrollment and Recovery
- Use high-assurance authenticators as the root of recovery. No help desk, email inbox, or call center should be able to bypass phishing-resistant controls. Recovery is often the attacker’s entry point. Eliminate social engineering vectors and force policy-compliant reproofing.
- Only allow for enrollment of device-bound credentials.
- Capture attestation metadata at registration, including device model and assurance level. Reject unrecognized or unverifiable authenticators. Trust begins at registration. If you don’t know what created the credential, you don’t control access.
Device Hygiene & Runtime Defense
- Bind sessions to trusted device context. A session cookie should never be a portable artifact. Runtime session enforcement should tie identity to continuous device posture, not just an initial authentication.
- Enforce continuous authentication. If device posture, location, or security status changes, require reauthentication or deny access. A login is not a hall pass. Risk is dynamic, authentication must be too.
- Assume authentication attempts with weak factors should be blocked by default. See how Beyond Identity customers instantly block identity attacks based on the simple fact that it is not a strong credential attempting access.
What This Looks Like in Practice
The architecture of an identity security system that offers uncompromising defense against identity, browser, and device-based attacks can be defined by these three traits:
- Device-bound credentials: Credentials never leave the device. They are non-exportable, hardware-backed, and cannot be synced or replayed elsewhere.
- Continuous trust: Authentication never stops at login. It continues throughout the session, tied to posture signals from the device.
- Universal endpoint hygiene enforcement: All endpoints are in scope. Even unmanaged devices must be evaluated in real time for risk posture and session integrity.
The bottom line
Synced passkeys are not a force field that is appropriate for defense. They improve usability for consumer use cases at the cost of enterprise access security.
See more in-action in an upcoming webinar, How Attackers Bypass FIDO: Why Synced Passkeys Fail and What To Do Instead where Beyond Identity will review how synced passkey failures happen and how leading security teams, including Snowflake and Cornell University, close these paths.
Even if you can’t join, register and you’ll get the recording!
