Introduction
We are living in the golden era of passwordless authentication. By mid-2026, the transition to FIDO2 and passkeys has reached critical mass. Major enterprises, financial institutions, and consumer platforms have successfully phased out legacy passwords, drastically reducing the efficacy of classic credential harvesting and brute-force attacks. Users no longer need to remember complex strings, and security teams have celebrated the decline of traditional phishing pages.
However, cybercriminals are nothing if not adaptable. As the industry closed the door on password theft, adversaries shifted their focus to a more vulnerable target: the authentication state itself. Today, the cutting edge of cyber defense is no longer about securing the credential during login—it is about securing the active session and validating the integrity of the device holding the key. In this article, we will dissect how modern attackers bypass passkey implementations through Adversary-in-the-Middle (AitM) session hijacking and attestation relay attacks, and provide actionable defense strategies to protect your architecture.
The Illusion of Absolute Security: How AitM Bypasses Passkeys
A common misconception among system administrators is that because passkeys are cryptographically bound to a specific domain (origin-bound), they are completely immune to phishing. While it is true that a user cannot accidentally type their passkey into a spoofed website, attackers have found a clever workaround: they let the user authenticate successfully on the legitimate site, and then steal the resulting session token.
“Passkeys protect the front door, but if your session management is weak, attackers will simply climb through the window after the door has been unlocked.”
Consider a modern AitM phishing framework updated for 2026. The attacker hosts a reverse proxy that sits between the victim and the legitimate identity provider (IdP). When the victim visits the phishing link, the proxy forwards the login page to the victim. When the victim attempts to use their passkey:
- The browser detects the authentic origin requested by the proxy’s backend connection (if misconfigured) or, more commonly, the proxy coaxes the user into initiating an authentication flow that relies on a secondary, fallback mechanism (like a one-time push notification).
- If the passkey flow succeeds directly to the legitimate IdP via a federated protocol, the IdP issues a session cookie or OAuth token.
- The proxy intercepts this session token as it travels back to the user.
- The attacker imports this token into their own browser, completely bypassing the need to ever touch or spoof the passkey itself.
Because the session token is just a bearer token—meaning whoever holds it is assumed to be the authorized user—the attacker gains full access to the account without ever cracking a single cryptographic key.
The Rise of Attestation Relay and Spoofing
Another vector gaining traction is the manipulation of WebAuthn Attestation. When a passkey is registered, the relying party (your server) can request an attestation statement. This statement is a cryptographic proof generated by the authenticator (such as a YubiKey, Apple’s Secure Enclave, or Google’s Titan chip) confirming that the passkey was created inside a genuine, hardware-backed secure environment.
In an attestation relay attack, an attacker intercepting the registration phase attempts to downgrade or spoof this attestation. If your system does not strictly validate the attestation signature against a metadata service (like the FIDO Alliance Metadata Service), an attacker can register a software-emulated passkey running in a malicious virtual machine. To your server, it claims to be a high-security hardware token, but in reality, the private keys are fully exportable and vulnerable to extraction.
Actionable Defenses for 2026 and Beyond
Securing a passkey-first infrastructure requires moving beyond simple credential validation. We must cryptographically bind the active session to the physical device that performed the authentication.
1. Implement DPoP (Demonstrating Proof-of-Possession)
The most robust defense against session hijacking is DPoP (RFC 9449). Unlike traditional bearer tokens, DPoP binds the OAuth 2.0 access and refresh tokens to a unique, ephemeral private key generated by the client browser.
When the client makes an API call, it must sign the request with this private key. If an attacker steals the session token via an AitM proxy, they cannot use it because they do not possess the corresponding private key stored securely in the victim’s browser context. Implementing DPoP ensures that intercepted tokens are instantly useless to adversaries.
2. Enforce Strict Device Attestation Checks
Do not treat passkey registration as a black box. Implement strict validation of attestation statements during enrollment:
- Verify the Trust Anchor: Match the attestation certificate chain against trusted roots from the FIDO Metadata Service (MDS).
- Block Software Emulators: Configure your WebAuthn relying party library to reject “none” attestation if your threat model demands hardware-level security. Require “direct” attestation for high-privilege accounts.
- Device Binding: Use platform APIs (like Windows Hello or macOS Secure Enclave) to ensure the credential cannot be synced to untrusted, unmanaged personal devices if you are in an enterprise setting.
3. Implement Continuous Access Evaluation (CAE)
Static session lifetimes (e.g., 8-hour sessions) are highly vulnerable to token theft. By implementing Continuous Access Evaluation (CAE) under the Shared Signals Framework (SSF), your identity provider can terminate sessions in real-time if anomalous behavior is detected.
For example, if a session suddenly switches from a known corporate IP range to an anonymous VPN, or if the user-agent changes mid-session, the IdP can immediately revoke the session token and force a re-authentication flow.
Forensic Investigation: Hunting for Session Anomalies
When investigating a suspected session hijacking incident in a passkey environment, security analysts must look for specific digital footprints. Traditional indicators like “failed login attempts” will be absent because the initial login was legitimate.
Focus your forensic queries on the following telemetry:
- TLS Session ID Mismatches: Analyze your web server logs to see if the TLS session identifier changed mid-stream while utilizing the same session cookie. This is a classic indicator of a proxy-based AitM attack.
- Rapid ASN Transitions: Query your IdP logs for “impossible travel” alerts, specifically looking for shifts in Autonomous System Numbers (ASNs) within minutes of a successful passkey authentication.
- Attestation Certificate Anomalies: During passkey registration logs, audit the `transports` property. If an enterprise user suddenly registers a credential with a “soft” transport type when corporate policy mandates “usb” or “nfc” hardware keys, flag this for immediate isolation.
Conclusion
Transitioning to passkeys is a massive victory for cybersecurity, but it is not an end-state. As defenders, we must recognize that authentication is only the first step in a user’s lifecycle. By implementing DPoP, enforcing strict device attestation, and utilizing continuous session monitoring, we can ensure that our post-password future remains truly secure. The battleground has shifted from the credential to the session—and that is where we must focus our defenses.
