Why do AiTM attacks still matter if organisations already use MFA?

Why This Matters for Security Teams

AiTM attacks remain effective because MFA does not automatically guarantee session integrity. If an attacker can relay the authentication flow in real time and capture the session token, the login succeeds from the user’s point of view while the attacker inherits access. That shifts the problem from password theft to token theft, which is why phishing-resistant authentication and tighter token binding matter. Current guidance from CISA cyber threat advisories consistently treats session hijacking as a live operational threat, not a legacy edge case.

This issue is especially relevant for SaaS, identity federation, and remote work environments where a single valid session can expose email, files, admin consoles, and downstream systems. The lesson from The 52 NHI breaches Report is that credential compromise rarely stays contained to the first account; it often becomes a platform-wide foothold once a trusted identity is hijacked. In practice, many security teams encounter session abuse only after mailbox rules, OAuth grants, or admin actions have already been changed, rather than through intentional detection of the relay step.

How It Works in Practice

An AiTM attacker places themselves between the user and the real identity provider, then proxies the full login flow. The user completes MFA, the provider issues a valid session, and the attacker captures the resulting cookie or token set. From there, the attacker may not need the password at all. This is why MFA alone is not a complete control; it confirms a user authenticated, but it does not always prove that the resulting session is protected against interception.

Security teams reduce this risk by focusing on controls that raise the cost of replay and token theft. Practical measures include phishing-resistant authenticators, device-bound or proof-of-possession tokens where supported, conditional access based on device and risk context, and tighter session lifetimes for sensitive applications. Identity standards and threat research increasingly point in the same direction. The Anthropic report on AI-orchestrated cyber espionage shows how quickly adversaries operationalise automation once a foothold exists, while NHIMG’s key challenges and risks guidance highlights how trust in one credential often cascades across systems.

• Use phishing-resistant MFA for privileged and high-risk users first.
• Shorten session duration for sensitive apps and require re-authentication for step-up actions.
• Prefer device-bound or sender-constrained tokens where the platform supports them.
• Monitor for impossible travel, token reuse, unusual user-agent patterns, and new mailbox or OAuth behaviours.
• Treat login success as one signal, not the final trust decision.

These controls tend to break down when legacy identity stacks, broad federation trust, and long-lived browser sessions are combined in one environment because token replay can survive the initial MFA challenge.

Common Variations and Edge Cases

Tighter session controls often increase user friction, so organisations must balance takeover resistance against operational convenience. That tradeoff is real, especially for customer-facing systems and BYOD populations where aggressive re-authentication can drive workarounds. Guidance is still evolving on how much step-up friction is acceptable before productivity suffers, so current practice is to reserve the strongest controls for privileged access, finance, HR, and admin workflows.

Some environments are harder to protect than others. Legacy protocols, thick-client applications, long-lived refresh tokens, and federated identity setups can all weaken the value of MFA because they extend trust after the initial login. This is where Top 10 NHI Issues is useful: token sprawl, overbroad trust, and weak lifecycle control are recurring failure modes across both human and non-human identities. The same pattern appears in Microsoft Midnight Blizzard breach coverage, where identity abuse became dangerous because trust boundaries were broader than the initial compromise suggested.

For most teams, the practical answer is not “remove MFA” but “make MFA harder to replay and easier to contain.” Where there is no universal standard for session binding yet, best practice is evolving toward shorter sessions, stronger token controls, and real-time detection for anomalous session use.

Related resources from NHI Mgmt Group

• Why do still-valid secrets matter after public disclosure?
• Should organisations still use one-time passwords for MFA?
• Why do AI-driven phishing attacks still succeed when organisations use modern authentication?
• Why do MFA fatigue attacks still work when MFA is already deployed?