FIDO Is Not Enough for Enterprise Security

TLDR

Even if you take nothing else away from this piece, if your organization is evaluating passkey deployments, it is irresponsible and insecure to deploy synced passkeys with FIDO.

• 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 FIDO 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

FIDO passkey risks

Synced passkey vulnerabilities

Passkeys are FIDO 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 our partner, 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:

1. Cloud account takeover or recovery abuse can authorize new devices, which then erodes the integrity of the credential.
2. 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.
3. 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

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 FIDO, 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 FIDO’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 FIDO 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 FIDO 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 page context where they can read and modify the DOM and drive user interface flows, which includes 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 is 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. 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 re-authentication 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:

1. Device-bound credentials: Credentials never leave the device. They are non-exportable, hardware-backed, and cannot be synced or replayed elsewhere.
2. Continuous trust: Authentication never stops at login. It continues throughout the session, tied to posture signals from the device.
3. 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

FIDO is a foundation, not a force field that is appropriate for defense. Synced passkeys improve usability for consumer use cases at the cost of enterprise access security. Downgrade attacks push users off the FIDO path despite the administrator's intentions. Malicious extensions and autofill abuse can steer or hijack the process inside the browser. 

Enforce device bound passkeys universally, remove every escape hatch that attackers can choose, and rein in extensions with the same discipline you apply to software on servers.

If a session isn’t originating from a known device, with a verified credential, and continuous enforcement, it isn’t trusted. It’s actually as simple as that. Check out a demo and let us show you these principles in action.