Because the attacker does not need to crack the vault or guess the password. They only need to relay the login flow in real time, capture the authenticated session, and reuse it. If the second factor can be proxied, the control is vulnerable even when the user followed the expected steps.
Why vaults do not stop real-time phishing relays
Vaults protect stored secrets, but adversary-in-the-middle phishing targets the session and the authentication exchange itself. The attacker proxies the login in real time, captures the authenticated context, and then reuses it before normal checks can distinguish the relay from the user. That means the vault can remain uncompromised while the session is already lost.
In practice, the weak point is not “where the password lives” but whether the authentication method resists relay. A vault can reduce exposure to leaked credentials and improve rotation discipline, yet it does not automatically prevent token theft, cookie replay, MFA relay, or help-desk-assisted takeover.
Why MFA still breaks when the second factor is proxied
MFA only helps when the factor proves something the attacker cannot forward in real time. If the adversary can relay the code, push approval, or browser session through a phishing kit, the user still completes a valid sign-in and the attacker inherits the result. The control failed at the point of authentication, not because the user skipped a step.
That is why classic MFA strength depends on the specific method. SMS, OTP apps, and approval prompts can all be relayed or socially engineered. Phishing-resistant methods, especially NIST SP 800-63 Digital Identity Guidelines aligned authenticators such as WebAuthn and FIDO2, are designed to bind the credential to the origin and make relay materially harder.
What actually closes the gap against AiTM phishing
The strongest defense is layered: reduce usable secrets, bind authentication to the legitimate origin, and limit what a stolen session can do. Workforce Identity Security Guide and MFA Guide both map to this problem because they focus on phishing-resistant sign-in, session theft, and bypass patterns rather than just MFA enrollment. Where sign-in and session controls are the issue, the right question is whether the control resists relay and replay, not whether an MFA box is checked.
For application and platform teams, Identity Provider and SSO Security Guide is especially relevant because many AiTM attacks succeed after the IdP issues a valid session. Monitoring unusual federation behavior, tightening recovery paths, and protecting token signing material matter because a stolen session or forged token can bypass the front door entirely.
Risk and Threat Considerations
AiTM phishing is dangerous because it converts a one-time login into reusable access. The user may enter the right credentials and still hand the attacker a live session, which makes the compromise look legitimate to many downstream controls.
Failure mechanism: The phishing proxy relays the authentication exchange in real time, captures the session cookie or token, and replays it from the attacker’s environment before the session expires or is challenged.
Impact: Attackers can bypass password policy and conventional MFA, access email, SaaS, VPN, or admin portals, and then move into reset, token, or authorization abuse if the session grants broad privilege.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST SP 800-63, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | AiTM phishing defeats user authentication flows for workforce access. |
| IA-5 — Authenticator Management | Vaults and MFA fail when authenticators, session artifacts, or recovery factors are reusable or relayable. | |
| IA-9 — Service Identification and Authentication | Session and token abuse can extend beyond users into federated and service-mediated access paths. | |
| Recommendation — Require phishing-resistant authentication for organizational users. Harden authenticator lifecycle and replace relayable factors. Bind service authentication to strong, non-replayable trust. | ||
| NIST SP 800-63 | Digital Identity Guidelines | The question centers on why some authenticators resist relay while others do not. |
| Recommendation — Use phishing-resistant authenticators for high-value sign-in. | ||
| OWASP ASVS | V6 — Authentication | The failure is in authentication assurance, especially relayable MFA methods. |
| V7 — Session Management | AiTM commonly steals or reuses authenticated sessions rather than cracking passwords. | |
| V10 — OAuth and OIDC | Federated sign-in and token issuance are common paths for session capture and replay. | |
| Recommendation — Verify authentication methods resist phishing relay attacks. Protect session tokens against theft, replay, and fixation. Bind federation tokens to secure, non-relayable sign-in flows. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account recovery, dormant access, and privileged accounts shape AiTM blast radius. |
| Recommendation — Remove stale accounts and tighten recovery for exposed identities. | ||
Practitioner Guidance
What to prioritise: Treat phishing resistance as a sign-in property, not an MFA enrollment metric. If the control can be proxied, it should not be your primary barrier for high-value access.
What to verify: Confirm that the protected flow is bound to the origin or device, and that recovery paths, push approvals, and session lifetimes do not reintroduce relay-friendly shortcuts.
Common mistake: Teams often harden the vault while leaving browser sessions, IdP recovery, and legacy factors exposed. That leaves the attacker’s easiest path untouched even though “MFA is enabled.”
Practitioner takeaway: Against AiTM phishing, the decisive control is not secret storage, it is whether the authentication ceremony and resulting session are resistant to relay, replay, and token theft.
Related resources from NHI Mgmt Group
- Why do OTP based MFA flows still fail against modern phishing and adversary in the middle attacks?
- Why do phishing-resistant methods still fail against man-in-the-middle attacks?
- Why do phishing-resistant MFA controls still fail against social engineering?
- Why do legacy MFA methods fail against adversary-in-the-middle attacks?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org