Phishing-resistant does not mean unphishable. The distinction is specific, consequential, and widely misunderstood.

FIDO2 was designed to solve a precise problem: an adversary-in-the-middle proxy cannot capture a credential that will authenticate the victim’s account on a different domain. That guarantee is cryptographic and real. A FIDO2 assertion is bound to the origin of the relying party — the authenticator’s signature is invalid if the domain doesn’t match, which means a phishing proxy sitting between the user and the real login page collects nothing usable.

That guarantee covers one specific moment in the account security lifecycle: the moment the user authenticates. The attack surface that exists before that moment, after it, and alongside it is a different question. Research published between 2024 and 2026 has mapped that surface in detail. The picture it produces is not an argument against deploying FIDO2 — it remains the strongest authentication standard available at scale. It is an argument for understanding exactly what FIDO2 protects, and what it doesn’t, before treating a deployment as complete.

FIDO2 Was Built to End Phishing. In One Specific Sense, It Did.

To understand where FIDO2 succeeds, it helps to understand the mechanism precisely. When a user initiates authentication, the relying party server generates a challenge. The browser calls navigator.credentials.get() with that challenge and a set of parameters that include the RP ID — the domain of the relying party. The authenticator signs the challenge along with a hash of the client data, which includes the origin. If the user is on a phishing site at evil.com rather than the legitimate bank.com, the browser will not release the credential. The signed assertion would be cryptographically bound to the wrong origin and would fail server-side verification even if captured.

This is why adversary-in-the-middle platforms could not crack hardware FIDO2 directly. Tycoon 2FA — a phishing-as-a-service platform that at its peak in 2025 accounted for roughly 62 percent of Microsoft-blocked phishing volume and processed over 30 million fraudulent emails in a single month — included JavaScript specifically designed to detect passkey prompts and redirect users to weaker authentication flows. It did not attempt to intercept FIDO2 assertions. The platform’s operators understood that origin binding made interception futile. They targeted the session token issued after authentication instead.

The FIDO Alliance’s designation of FIDO2 as “phishing-resistant” is accurate for this specific attack scenario. Reverse proxies, AiTM setups, and transparent MitM infrastructure cannot replay a FIDO2 assertion across domain boundaries. For the authentication ceremony itself, the security property holds. What makes this important to establish clearly is what comes next.

The Attack Surface Didn’t Disappear. It Fractured.

Attackers do not stop when one technique is closed. They identify the next available surface. The history of authentication security is a history of this process: passwords moved the attack to credential stuffing, TOTP moved it to real-time phishing of one-time codes, and FIDO2 moved it to the layers surrounding the authentication ceremony itself.

Research from 2024 through 2026 has documented four distinct attack layers, each with its own mechanism, its own body of published research, and its own defensive requirements.

The first layer is the authentication ceremony — the moment the user authenticates — where FIDO2 is strongest. The second is the fallback authentication stack: the SMS codes, authenticator apps, and password reset flows that most deployments maintain alongside FIDO2, and where most documented attacks now concentrate. The third is the session: the authenticated state that exists after login succeeds, and which is not protected by the FIDO2 assertion that created it. The fourth is account recovery: the process that runs before a user can authenticate at all when they have lost their device, and which is typically the least-protected part of any identity system.

A FIDO2 deployment that secures the first layer without addressing the other three has moved the problem. It has not solved it.

Breaking the Ceremony: Browser-in-the-Middle and XSS

The authentication ceremony is the hardest layer to attack. It is not impenetrable.

Research published in the Journal of Computer Virology and Hacking Techniques (Springer, May 2025) by Catalano, Chezzi, Barletta, and Tommasi demonstrated the first real-time bypass of hardware FIDO2 authentication during the ceremony itself. The attack — termed BitM+ — chains two techniques: a Browser-in-the-Middle proxy that routes the victim’s session through attacker-controlled infrastructure, combined with a reflected XSS vulnerability in the relying party’s login page.

To understand why this works, it helps to understand why standard BitM attacks fail against FIDO2. A conventional BitM setup proxies all traffic between the victim and the legitimate site through an attacker-controlled browser. When the authentication ceremony runs on this proxy, the origin presented to the authenticator is the attacker’s domain, not the RP’s domain. The browser will not release the FIDO2 credential for the wrong origin. The proxy collects nothing usable. The BitM+ attack resolves this by introducing an out-of-band channel.

The attack works in the following sequence. The victim navigates to a URL containing a reflected XSS payload — a link to the legitimate RP site with a crafted parameter that the page reflects into the DOM without sanitization. This injected JavaScript executes inside the legitimate origin, which means the browser’s origin checks pass. Meanwhile, the BitM proxy overrides the navigator.credentials.get() call with a malicious function that publishes the authentication challenge to an attacker-controlled REST API rather than processing it locally. The XSS payload, running in the legitimate origin context, polls this API, retrieves the challenge, and calls the real navigator.credentials.get() on the victim’s machine. The victim’s hardware token signs the legitimate challenge in the legitimate origin. The resulting assertion travels back through the REST API to the BitM proxy, which forwards it to the RP server. The server validates it. The attacker receives an authenticated session.

No cryptography was broken. The FIDO2 protocol performed exactly as specified. The attack exploited the API layer — specifically, the XSS vulnerability that permitted JavaScript execution inside the legitimate origin — not the authentication standard itself. The authors draw a precise parallel: Microsoft’s RDP WebAuthn Virtual Channel Protocol legitimately enables remote desktop users to authenticate with their local hardware token across a network boundary. The BitM+ attack replicates that mechanism maliciously through injected JavaScript rather than native OS infrastructure.

The attack depends on a specific prerequisite: a reflected XSS vulnerability in the relying party’s login page. XSS in authentication flows is a common finding in security assessments, but it is a discoverable and patchable vulnerability. The defensive implication is specific: XSS remediation on authentication pages, combined with a Content Security Policy that restricts script execution to trusted origins, closes the attack surface the BitM+ technique depends on. This is not new guidance — XSS has been in OWASP’s Top 10 since its inception — but the BitM+ research makes it a targeted priority for authentication flows rather than a general hygiene item.

Downgrade Attacks: Walking Around the Wall

The BitM+ attack is sophisticated and requires a specific vulnerable prerequisite. The downgrade attacks documented in 2025 require neither, and they represent the most practical threat to FIDO2 deployments currently operating in the wild.

In August 2025, Proofpoint researchers published a FIDO authentication downgrade technique built on the Evilginx adversary-in-the-middle framework. The mechanism is operationally simple: spoof a browser user agent that the relying party considers FIDO-incompatible. The researchers demonstrated this against Microsoft Entra ID by spoofing Safari on Windows — a configuration Entra recognizes as lacking WebAuthn support. When Entra detects an incompatible browser, it disables the passkey option and presents alternative authentication methods: an authenticator app, SMS codes, or a password. The victim selects one of these weaker methods. The AiTM proxy captures the response and the resulting session cookie. The attacker has full account access.

FIDO2 was never bypassed. It was never invoked. The hardware token on the victim’s keyring provided no protection because the login flow was manipulated before the token was offered as an option.

This attack class illustrates the fundamental structural vulnerability in FIDO2 deployments that maintain fallback authentication methods. Authentication chains are only as strong as their weakest link. If an SMS code or authenticator app fallback exists for any account, an attacker who can suppress the FIDO2 prompt — through browser spoofing, flow manipulation, or relying party logic exploitation — can reach the weaker link without encountering FIDO2 at all.

Proofpoint noted at publication that this technique had not been observed in active campaigns at that time. The operational logic suggests that will change as FIDO2 adoption increases. When the standard attack surface is secured, the fallback becomes the target. The timeline for that shift tracks directly with enterprise passkey rollout.

The defensive response requires operational discipline that is harder than the technical fix: eliminating fallback authentication methods for high-value accounts, or enforcing FIDO2-only authentication flows with strong policy controls. This is genuinely difficult in enterprise environments where users lose devices and helpdesk support is a real operational requirement — which is exactly why the recovery layer, addressed in the next section, matters so much.

Session Hijacking: The Login Was Real. The Session Is Stolen.

FIDO2 authentication is a point-in-time event. The session token it produces is a separate artifact with separate security properties.

When a user completes FIDO2 authentication successfully, the server issues a session token — typically a cookie stored in the browser. This token represents the authenticated state for the duration of the session. It is not cryptographically bound to the hardware authenticator. It is not origin-bound in the same way the FIDO2 assertion was. In a standard AiTM proxy arrangement, if the attacker is positioned between the user and the legitimate server, that token is capturable the moment the server sends it.

Tycoon 2FA operated on this principle at industrial scale. The platform proxied authentication sessions between victims and their real accounts, allowed FIDO2 authentication to complete normally on the side of the session where it would succeed, and captured the session token issued by the legitimate server on the attacker’s side. The hardware token performed correctly. The session it authenticated was then replayed from a different device. The platform generated over 30 million fraudulent emails in its peak month and processed victims across Microsoft 365 and Google Workspace environments. Microsoft, Europol, Cloudflare, SpyCloud, and partner organizations dismantled the Tycoon 2FA network in March 2026, seizing over 300 domains. Successor infrastructure was operational within weeks.

The session is the new credential. This has been true since session cookies replaced per-request authentication in web architecture, but the shift in attacker focus from credential theft to session theft has accelerated as FIDO2 closes the credential attack. The defenses at this layer are different from the defenses at the ceremony layer. Session token lifetimes should be short for high-sensitivity operations. Session tokens should be bound to device characteristics where the architecture permits. Continuous Access Evaluation Protocol (CAEP) enables session tokens to be revoked in real time when a risk signal changes — a new device, a new location, a threat intelligence indicator — without requiring re-authentication from scratch. These are not FIDO2-adjacent recommendations. They are independent security requirements that FIDO2 deployments must address alongside the authentication standard itself.

Account Recovery: The Door No One Is Guarding

Apple stated at the FIDO Authenticate conference in 2025: phishing resistance is a property of the entire authentication chain, not just the strongest method in the chain.

Every FIDO2 deployment must address what happens when a user loses their authenticator. Hardware tokens are lost, damaged, or forgotten. Devices enrolled as platform authenticators are wiped or replaced. The recovery process that handles these situations is, in most deployments, less secure than the primary authentication it recovers access to. It is also not protected by FIDO2.

The MGM Resorts breach in 2023 is the most cited example of this attack pattern at scale. Attackers social-engineered the MGM helpdesk, impersonating an employee and requesting account resets through a ten-minute phone call. The primary authentication system — which included MFA — was never touched. The recovery process was the entry point. Estimated disruption exceeded $100 million. MGM did not have FIDO2 deployed, but the attack vector applies to any authentication architecture: the security of primary authentication is irrelevant if the recovery process can be bypassed through social engineering against helpdesk staff who are trained to be helpful.

Attacker tooling has adapted to target recovery flows specifically. Phishing kits documented in 2025 included templates for simulated helpdesk interactions — scripts designed to social-engineer account reset approvals through convincing impersonation of legitimate employees or contractors. The Tycoon 2FA platform included components specifically addressing recovery flow exploitation as a fallback when primary authentication proved resistant.

PoisonSeed, a technique explored by researchers in mid-2025, demonstrated a different angle: initiating a cross-device authentication flow that generated a QR code on the real service’s login page, which an attacker could capture before the victim completed the scan. Subsequent analysis found the attack impractical at scale due to physical proximity requirements, and The Hacker News reported it was ultimately not a FIDO bypass in the intended sense. But the research is useful as a map of the conceptual surface — recovery and device enrollment flows create interaction opportunities that motivated attackers will continue to probe.

Phishing-resistant account recovery requires phishing-resistant recovery factors. Backup passkeys registered on secondary devices, hardware tokens as recovery credentials rather than SMS or knowledge-based verification, and identity document verification with liveness detection for scenarios where no registered backup factor exists. These are operationally heavier than the default alternatives, which is why they remain underdeployed. The gap between the security properties of a FIDO2 primary authentication and a knowledge-based recovery flow is the gap most likely to be exploited.

Not All Passkeys Are Equal

The term passkey covers two meaningfully different security architectures.

Device-bound passkeys — hardware security keys and platform authenticators with strong attestation — store the private key in a hardware-protected element that never leaves the device. The key cannot be exported, synchronized, or extracted through software. If the physical device is secure, the key is secure.

Synced passkeys, which include credentials that synchronize across iCloud Keychain and Google Password Manager, operate differently. The private key is generated on one device and encrypted for synchronization across all devices enrolled in the user’s account. This is what makes synced passkeys operationally convenient: a user can access their passkeys on a replacement phone without re-registering at every relying party. It is also what expands the attack surface.

A synced passkey exists in multiple places: every enrolled device, and the cloud infrastructure that holds the encrypted synchronization data. The cloud provider must be compromised for the key material itself to be at risk, and major providers invest significantly in this infrastructure. The more practical concern is attestation: synced passkeys cannot provide the same attestation guarantees as device-bound hardware, because the RP cannot cryptographically verify the security properties of every device where the key may exist across the sync ecosystem.

Research presented at DEF CON 2025 demonstrated practical attacks against synced passkeys, including JavaScript injection techniques and what researchers termed “Signed Assertion Hijacking” — exploiting the synchronization layer to redirect or intercept passkey assertions. CVE-2025-26788 documented a passkey authentication bypass in StrongKey FIDO Server resulting from implementation errors in the WebAuthn validation flow, demonstrating that relying party implementation quality introduces its own attack surface independent of the passkey type in use. A peer-reviewed comparative analysis published on arXiv (2501.07380) provided a systematic evaluation of security differences between synced and device-bound credentials, finding meaningful gaps at the attestation and revocation layers.

The practical guidance is calibrated, not binary. For most users and most accounts, synced passkeys represent a substantial security improvement over passwords and TOTP-based MFA. The comparison is against the realistic alternative, not the theoretical ideal. For enterprise high-value accounts — administrators, executives, privileged access roles — device-bound hardware tokens provide meaningfully stronger guarantees: the private key cannot be synchronized, exported, or extracted through any software mechanism. For these accounts, the operational overhead of hardware token issuance is the right trade.

What the Map Requires

The FIDO2 attack map produces specific defensive requirements, not a reason to reconsider passkey adoption. The recommendation to deploy FIDO2 has not changed. The argument is for understanding what deploying FIDO2 actually secures — and building the corresponding controls for what it does not.

The authentication ceremony is now the strongest layer. Origin binding permanently closes credential phishing by AiTM proxies, a closure that is cryptographic and durable. This is the correct starting point and the most important individual control in the stack.

The fallback layer is the most actively exploited. Eliminating fallback authentication methods for high-value accounts, or enforcing strict FIDO2-only flows with policy controls that cannot be manipulated through browser spoofing, closes the downgrade attack surface. This requires solving the lost-device problem with phishing-resistant recovery rather than weaker authentication alternatives.

The session layer requires independent controls. Short-lived tokens, device-bound session credentials, and continuous access evaluation address session hijacking without depending on the FIDO2 authentication that initiated the session. CAEP integration enables real-time revocation when risk signals change — a capability that sits entirely outside the authentication ceremony but covers the session period that follows it.

The recovery layer is the most underinvested. Backup passkeys on secondary devices, hardware tokens as recovery factors, and identity verification with liveness detection for break-glass scenarios replace recovery flows that social engineering has consistently exploited. The MGM breach did not require a technical attack. It required a convincing phone call.

The relying party implementation matters. XSS vulnerabilities in authentication pages are the specific attack surface the BitM+ research depends on. A Content Security Policy that restricts script execution to trusted origins, combined with thorough XSS remediation on auth flows, closes this vector. For synced passkey deployments, attestation validation at the RP and careful attention to WebAuthn implementation quality address the implementation-layer risks CVE-2025-26788 illustrates.

FIDO2 moved the attack surface. It did not eliminate it. The map is not a reason for pessimism about passkeys — the controls are known, the attack prerequisites are specific, and each layer has a tractable defense. It is a reason to treat authentication as a system rather than a method. The ceremony is one component. The session, the fallback stack, the recovery flow, and the implementation are the rest.

Sources

  1. Catalano, Chezzi, Barletta & Tommasi, Defeating FIDO2/CTAP2/WebAuthn using browser in the middle and reflected cross site scripting, Journal of Computer Virology and Hacking Techniques, Springer, May 2025
  2. Proofpoint Threat Research, Don’t Phish-let Me Down: FIDO Authentication Downgrade, August 2025
  3. Elastic Security Labs, Tycoon 2FA AiTM Detection for Entra ID and Google, 2025
  4. Microsoft, Europol et al., Tycoon 2FA Phishing Platform Takedown, March 2026
  5. Apple, Passkeys Aren’t the Finish Line: Eliminating Fallbacks and Fixing Recovery, FIDO Authenticate Conference, 2025
  6. Mandiant / various, MGM Resorts Social Engineering Breach, 2023
  7. SquareX Research, Signed Assertion Hijacking and Synced Passkey Attacks, DEF CON, 2025
  8. CVE-2025-26788, Passkey Authentication Bypass in StrongKey FIDO Server, 2025
  9. Lassak et al., Device-Bound vs. Synced Credentials: A Comparative Evaluation of Passkey Authentication, arXiv:2501.07380, 2025
  10. The Hacker News, PoisonSeed Attack Turns Out to Be Not a FIDO Bypass After All, July 2025