Phishing-resistant factors such as passkeys are origin-bound, so the authentication exchange cannot be transparently relayed to an attacker domain in the same way as OTP or push-based methods. That makes them materially harder to proxy. The key difference is not convenience but whether the credential can be presented outside its intended origin.
Why origin-bound factors change the attack path
Phishing-resistant factors change the attacker’s job from stealing a reusable code to defeating the browser or authenticator’s binding to the real site. That matters because an adversary in the middle can proxy many OTP flows with little resistance, but cannot simply replay an origin-bound assertion into a different origin without breaking the trust properties that make the factor useful.
This is why the control is about protocol properties, not user discipline. If the factor can only be presented to the intended origin, the attacker loses the transparent relay advantage that makes AiTM so effective against OTP and push workflows.
For a broader comparison of factor classes and bypass modes, the MFA Guide explains how relay attacks, token theft, and phishing-resistant sign-in differ in practice.
Why OTP codes remain proxyable
OTP codes are usually short-lived secrets that the user types into a web form. That makes them convenient, but it also means the code can be captured, forwarded, and consumed in near real time by a malicious proxy. The code proves possession at a moment in time, but it does not strongly prove that the browser session is talking to the genuine origin.
That weakness shows up in common failures such as OTP relay, MFA fatigue, and fake login pages. When the factor is human-entered and not cryptographically tied to the relying party, the attacker only needs to interpose themselves between the user and the service long enough to harvest and replay the value.
The Workforce Identity Security Guide and the Identity Provider and SSO Security Guide both show how relay-resistant authentication depends on the full sign-in path, not just the factor itself.
What changes in real-world AiTM defense
In practical terms, phishing-resistant factors reduce AiTM risk by removing the attacker’s ability to stand in the middle and still end up with a valid credential artifact. Passkeys, security keys, and similar methods bind the authentication ceremony to the legitimate origin, so a stolen response is not just hard to get, it is often useless outside the intended context.
That is a major shift in defense posture. The remaining risks move away from simple credential relay and toward account recovery abuse, device compromise, help desk override, session theft after login, or weaker fallback paths. So the control is strongest when phishing-resistant sign-in is paired with strong recovery governance and reduced legacy fallback.
The difference is visible in breach patterns. The Twilio 0ktapus breach 2022, Change Healthcare breach 2024, and CitrixBleed exploitation 2023 all illustrate that OTP or equivalent second factors do not meaningfully help if the attacker can proxy, reuse, or steal the live session path.
Risk and Threat Considerations
AiTM succeeds when the defender treats “two factors” as the same as “phishing-resistant.” OTP and push methods can still be relayed, socially engineered, or consumed through a fake sign-in flow, so the residual exposure is not theoretical, it is an authentication design issue.
Failure mechanism: The attacker inserts a proxy between the user and the service, captures the OTP or push response, and forwards it quickly enough to establish a live session before the code expires.
Impact: The attacker gets authenticated access that may look legitimate to the service, enabling account takeover, session theft, internal pivoting, or downstream fraud even though the user believed they completed MFA.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Defines phishing-resistant authenticators and origin binding for the exact comparison |
| Recommendation — Use phishing-resistant authenticators and require origin-bound verification for high-risk sign-in flows. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Covers stronger user authentication for accounts exposed to AiTM phishing |
| IA-5 — Authenticator Management | Addresses lifecycle control for OTPs, tokens, and authenticators that can be abused in relay attacks | |
| Recommendation — Require strong authentication for organizational users and phase out relayable second factors. Manage authenticator issuance, rotation, and revocation so fallback factors do not weaken phishing resistance. | ||
| OWASP ASVS | V10 — OAuth and OIDC | Supports phishing-resistant federation and assertion handling for browser-based sign-in |
| Recommendation — Verify federation and token flows resist interception, replay, and token substitution. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Supports reducing exposure from weak or legacy sign-in paths |
| Recommendation — Remove legacy authentication paths and enforce stronger access control for exposed accounts. | ||
Practitioner Guidance
What to prioritise: Treat phishing-resistant authentication as the default for high-value users, admin roles, and externally exposed sign-in paths. The main decision is whether the factor can be replayed outside the intended origin; if yes, it is still proxyable and should not be your top protection against AiTM.
What to verify: Confirm that the deployed method is truly origin-bound end to end, including enrollment, recovery, and step-up flows. A strong front-end factor can be undermined if fallback options still allow OTP, help desk resets, or legacy auth.
Common mistake: Calling any MFA “phishing-resistant” because it is not a password. OTP still reduces some attack paths, but it does not solve the core AiTM problem unless the factor is cryptographically tied to the legitimate origin.
Practitioner takeaway: If the authentication artifact can be typed, copied, or relayed into a different site, assume AiTM remains viable, and prefer factors that fail closed when moved outside the intended origin.
Related resources from NHI Mgmt Group
- Why do FIDO2 and passkeys reduce phishing risk more effectively than OTP codes?
- Why do phishing-resistant MFA methods reduce account takeover risk more than codes or SMS?
- Why do phishing-resistant credentials reduce man-in-the-middle risk?
- How should security teams reduce the risk of MFA bypass through AiTM phishing?