Passkeys and the phishing relay: why origin binding beats one-time codes
Phishing kits that sit between a user and a genuine login page have become one of the most reliable ways to defeat multi-factor authentication. The victim types a one-time code, the kit relays it to the real site within seconds, and the attacker keeps the session that comes back. A passkey breaks this relay in a way no code-based method does: there is simply nothing on the screen to copy.
How AiTM kits eat one-time codes
The mechanics are documented in detail by Microsoft, which tracked a campaign hitting more than 10,000 organizations from September 2021 onward. The attacker runs a reverse proxy that serves a pixel-perfect copy of the real sign-in page on its own domain, holding two TLS sessions: one with the victim, one with the genuine site. Passwords and session cookies flow through the middle, and the attacker signs in as the user. Microsoft stressed that this is not a vulnerability in MFA; the code is genuine, the login is genuine, and the kit simply keeps what the user hands over (Microsoft). The technique has not faded. In January 2026, Microsoft researchers described a multi-stage adversary-in-the-middle campaign against energy-sector organizations that arrived through abused SharePoint links and ended in business email compromise (Microsoft). A year of Kaspersky telemetry published in August 2026 counted over 390,000 phishing pages on legitimate cloud platforms, many using open-source proxy libraries and browser-in-the-browser windows to fake the address bar (Kaspersky). The modern kit relays the code, the push approval and the resulting cookie in real time. Everything except the URL is real.Origin binding: the domain is part of the credential
WebAuthn, the standard behind passkeys, works differently. At registration, the site and the browser create a public-private key pair scoped to a relying party ID, which in practice is the site's domain. The private key never leaves the device, and the browser only offers a credential when the page's origin matches that ID. Mozilla's documentation puts the consequence plainly: an attacker who builds a fake login website cannot log in as the user, because the signature changes with the origin of the website (Mozilla). The FIDO Alliance describes passkeys as unique per website or application, which is also what starves credential-stuffing of material (FIDO Alliance). Cisco Talos demonstrated what this means for proxy kits: a victim who lands on a fake domain impersonating their bank cannot complete the WebAuthn ceremony at all, because the browser will not offer a credential scoped to the real domain on the fake one. Authentication fails before any secret is transmitted (Cisco Talos).A proxy kit can relay anything the user types. It cannot relay a credential the browser never offers.Even where the ceremony does run, nothing reusable crosses the wire. The server sends a large random challenge, the authenticator signs it with the private key, and the signature proves possession without revealing any secret, as Mozilla's specification notes. A proxy can forward that signature, but the genuine site then sees a response claiming an origin it did not serve, with a credential tied to a relying party ID it checks for exactly this case. There is no code racing a thirty-second timer and no cookie minted on the attacker's side.