Why do MFA and SSO still fail against AiTM attacks?

Why This Matters for Security Teams

AiTM attacks expose a gap that MFA and SSO were never meant to close on their own: they verify the user at sign-in, but they do not continuously prove that the resulting session still belongs to that user. Once an attacker captures a valid cookie or token, downstream applications often accept it as trusted. That is why guidance from NHI research such as 52 NHI Breaches Analysis remains relevant, because session theft and token reuse are recurring patterns across identity abuse cases.

This is also why session security has become a practical control problem rather than a login problem. Modern phishing kits can proxy authentication in real time, downgrade trust signals, and replay approved sessions before defenders notice. The issue is not that MFA failed technically, but that the attacker moved past the MFA checkpoint and into the session layer where SSO trust is sticky. The same pattern shows up in broader identity abuse research, including CISA cyber threat advisories, which repeatedly emphasize that valid credentials and sessions are high-value attack paths. In practice, many security teams discover AiTM only after a mailbox, SaaS console, or admin workflow has already been used from an attacker-controlled session.

How It Works in Practice

AiTM, or adversary-in-the-middle, places a proxy between the user and the identity provider. The user sees a legitimate login flow, enters credentials, completes MFA, and receives what appears to be a normal SSO result. Behind the proxy, the attacker captures the authenticated session cookie, refresh token, or other bearer token and reuses it elsewhere. From the application’s perspective, the request looks normal because the session was issued by a trusted identity system.

That is why traditional perimeter thinking breaks down. The threat is not just password theft, but theft of the approved state that follows authentication. A better defensive model combines short-lived sessions, phishing-resistant MFA, conditional access, device binding, and step-up checks for sensitive actions. Where available, teams should prefer cryptographic or device-bound authenticators over reusable OTP flows, because a proxy can relay OTPs but cannot as easily mint a bound credential.

• Use phishing-resistant MFA for privileged and high-risk users.
• Shorten session lifetime and refresh token validity where business risk allows.
• Bind sessions to device, network, or workload context instead of trusting the token alone.
• Re-authenticate before exports, privilege changes, mailbox rules, and admin actions.

For identity and workload context, NHI teams should also read the Ultimate Guide to NHIs — Key Challenges and Risks, because the same session and token reuse logic applies when non-human identities are involved. External research from MITRE ATT&CK Enterprise Matrix is useful for mapping how initial access, credential interception, and lateral movement commonly chain together in real intrusions. These controls tend to break down when legacy SSO applications cannot enforce token binding or when long-lived refresh tokens remain valid across multiple devices and geographies.

Common Variations and Edge Cases

Tighter session controls often increase user friction and help desk load, requiring organisations to balance phishing resistance against business continuity. That tradeoff matters because not every application can support modern token binding or continuous verification, and best practice is still evolving for heterogeneous SaaS estates.

Some environments rely on SSO for convenience but still permit legacy protocols, service accounts, or long-lived browser sessions. In those cases, AiTM may not even be the first problem, because the attacker can pivot from a captured session into email forwarding rules, OAuth consent abuse, or admin delegation. Current guidance suggests treating the session as the real security boundary and not assuming MFA alone provides durable assurance. That is especially important in hybrid identity environments where on-premises and cloud trust models overlap.

For a broader threat pattern, the LLMjacking: How Attackers Hijack AI Using Compromised NHIs report shows how stolen identities can be repurposed quickly once trust is established. Where organisations use shared browsers, unmanaged devices, or weak logout hygiene, session replay remains difficult to detect because the attacker is operating inside a valid trust envelope. A second useful reference is Microsoft Midnight Blizzard breach, which reinforces how identity trust can be abused after the initial login event has already succeeded.

Related resources from NHI Mgmt Group

• Who is accountable when validated controls still fail against real attacks?
• Why do MFA codes still fail against vishing attacks?
• Why do MFA and SSO controls still fail against identity-focused intrusions?
• Why do MFA and traditional training still fail against machine-speed attacks?