Because the risk shifts from proving identity at login to preserving trust throughout the live session. If the attacker can capture the authenticated session, the organisation may have perfect MFA telemetry and still be vulnerable to abuse through that stolen session.
Why MFA does not end the attack after login
A successful MFA prompt proves an authenticator event, not that the whole session remains trustworthy. In AiTM attacks, the adversary sits between the user and the real service, captures the login exchange, and can often steal the resulting session artefact. That means the defender is no longer dealing with failed authentication, but with a live, valid session that may outlive the login itself.
MFA is still valuable, but it protects only one point in the journey. If the adversary captures cookies, tokens, or a session token after the user completes MFA, the attacker can behave like the user until the session expires, is revoked, or is otherwise detected. This is why post-login protections matter as much as the sign-in challenge itself.
For teams comparing sign-in strength, phishing-resistant methods such as passkeys and hardware-backed authenticators reduce the opportunity for relay-style interception, but they do not remove every session-risk path. The control objective is not just stronger login, it is stronger trust continuity after login, including session binding, short lifetime, and reauthentication for sensitive actions. See NIST SP 800-63 Digital Identity Guidelines for the underlying assurance concepts, and Passwordless and Passkeys Guide for rollout considerations that reduce phishing relay risk.
Where the real exposure sits in an AiTM chain
The exposure usually comes from the gap between successful authentication and session use. AiTM tooling is designed to proxy the victim’s browser, capture the session token, and then reuse that token from another device or location. Once the session is established, the attacker may not need to trigger another MFA prompt at all, which is why the compromise can look like ordinary user activity in the identity logs.
That creates a practical detection problem. If defenders only watch for MFA failures, they miss the far more important question: did the session come from a trusted device, a normal network, and a normal browser fingerprint, and did it behave like the user after sign-in? Session theft, token replay, and cookie reuse are the failure modes to treat as first-class risks.
Incidents that combine phishing, MFA fatigue, or token theft show how quickly a “good login” can become a bad session. NHIMG’s CitrixBleed exploitation 2023 and Twilio 0ktapus breach 2022 both illustrate how the authentication step can succeed while the attacker still walks away with durable access.
How organisations reduce post-login trust failure
The control answer is to make the session harder to replay and easier to invalidate. That means using phishing-resistant sign-in methods, limiting session duration, requiring step-up checks for privileged actions, and revoking access quickly when anomalous behaviour appears. The session should also be treated as an object with its own trust properties, not as a permanent by-product of MFA success.
For identity teams, a useful design rule is to separate “proved at sign-in” from “trusted for the rest of the session.” A user may prove identity once, but sensitive actions should still be gated by device trust, transaction context, risk scoring, or additional verification. MFA Guide and Workforce Identity Security Guide are useful for understanding the practical difference between sign-in protection and broader session defense.
When the business depends on remote access, browser-based portals, or SSO-heavy workflows, the highest-value improvement is usually not adding another factor, but reducing the value of a stolen session through tighter token lifetime, better revocation, and continuous risk evaluation. Change Healthcare breach 2024 and Colonial Pipeline ransomware attack both reinforce that access paths with weak session governance can become enterprise-scale exposure points.
Risk and Threat Considerations
AiTM attacks matter because they turn a successful login into a persistence mechanism. Once the attacker has the session, the organisation may face account abuse, internal access, data exfiltration, and lateral movement without any further authentication alerts.
Failure mechanism: The proxy captures the victim’s authenticated session artefact, then reuses it from an attacker-controlled environment while the service still treats the session as valid.
Impact: The organisation can see a legitimate MFA success and still suffer unauthorised actions, with incident response delayed because the compromise looks like normal user activity.
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 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | MFA login assurance depends on authenticating the user at sign-in. |
| IA-5 — Authenticator Management | AiTM attacks exploit credentials, tokens, and session material that need lifecycle control. | |
| AC-12 — Session Termination | Session hijack risk makes controlled session expiry and revocation central to the answer. | |
| Recommendation — Verify strong user authentication and step-up controls for sensitive access. Manage authenticators, tokens, and session material with tight issuance and revocation. Set short session lifetimes and terminate sessions promptly on risk or inactivity. | ||
Practitioner Guidance
What to verify: Confirm whether your controls distinguish initial authentication from ongoing session trust. If your monitoring ends at MFA success, you are blind to token replay, cookie theft, and session hijack.
Decision rule: If the application exposes high-value actions through long-lived sessions, treat session binding, rapid revocation, and step-up checks as priority controls, even when MFA is already deployed.
What practitioners underestimate: The hardest part is often not proving the user at login, but deciding when a session should stop being trusted. That is where AiTM attacks win.
Practitioner takeaway: MFA raises the cost of initial compromise, but it does not guarantee post-login trust. Defend the session as aggressively as the sign-in, or AiTM will simply move the attack one step later.