How should security teams reduce the risk of MFA bypass through AiTM phishing?

Why This Matters for Security Teams

aitm phishing changes the control problem from “did the user enter a code?” to “what can an attacker do with the resulting session?” Once an adversary relays authentication in real time, MFA can be satisfied while the attacker still captures a usable token, cookie, or browser session. That means the real risk sits after authentication, where access can persist until the session is revoked or expires. Current guidance from the NIST Cybersecurity Framework 2.0 supports continuous risk management, but many teams still anchor too heavily on login events instead of session integrity. The issue is compounded in environments where cloud apps, OAuth grants, and browser-based access are already fragmented, which is why NHIMG’s The State of Non-Human Identity Security highlights how visibility gaps and weak monitoring remain common across identity programs. A useful parallel appears in the Microsoft Midnight Blizzard breach, where post-authentication abuse and token theft drove impact rather than a simple password failure. In practice, many security teams encounter mfa bypass only after a session has already been hijacked, rather than through intentional testing of the authentication chain.

How It Works in Practice

Reducing AiTM risk requires treating authentication as one step in a longer chain of session validation, token protection, and revocation. Phishing-resistant authenticators such as FIDO2/WebAuthn help because they bind the credential exchange to the legitimate origin, but they do not eliminate every post-login risk. Security teams should pair them with conditional access, device posture checks, and session telemetry that can detect impossible travel, unusual token use, or abnormal browser transitions. Where possible, identity systems should shorten token lifetimes and require reauthentication for sensitive actions, not just at sign-in. Practical controls usually include:

• Phishing-resistant MFA for privileged users and high-risk applications.
• Continuous session monitoring for new device, location, or user-agent anomalies.
• Immediate session and refresh-token revocation when compromise is suspected.
• Step-up verification before access to sensitive data, admin consoles, or payment flows.
• Brokered access to reduce direct exposure of long-lived credentials and cookies.

NHIMG’s Top 10 NHI Issues is relevant here because attackers increasingly target session material, API tokens, and delegated access rather than only passwords. That pattern also aligns with identity guidance in NIST CSF 2.0, which emphasizes protective and detective measures across the full access lifecycle. A practical takeaway is that MFA should be treated as a gate, not a shield. These controls tend to break down when legacy SaaS applications cannot expose session telemetry or support rapid token revocation because the attacker can keep using the authenticated session even after the original login event is flagged.

Common Variations and Edge Cases

Tighter session control often increases user friction and operational overhead, so organisations need to balance resilience against support load and business continuity. There is no universal standard for how aggressively session revocation should be enforced across all applications, and current guidance suggests risk-based tuning rather than one fixed timeout. For example, customer-facing apps may tolerate longer sessions, while admin portals, finance tools, and identity providers should use much shorter lifetimes and stricter reauthentication rules. A second edge case is that some environments rely heavily on trusted device signals or persistent browser sessions. Those signals help, but they are not proof that a session is safe if the browser has already been proxied through an attacker-controlled relay. This is why the Ultimate Guide to NHIs — Why NHI Security Matters Now is useful context: identity risk increasingly extends beyond initial authentication into how access is retained and reused. The best practice is evolving toward continuous evaluation, tighter token scoping, and explicit session kill-switches for privileged workflows. Teams should also remember that phishing-resistant MFA is strongest when paired with app-level protections, because some legacy protocols and embedded web views still weaken origin binding and create bypass paths.

Related resources from NHI Mgmt Group

• How should security teams reduce phishing risk when attacks blend into normal work?
• How should security teams reduce phishing risk in MFA without creating more user friction?
• How should security teams reduce MFA bypass risk in high-risk login flows?
• How should teams reduce the risk of exposed AI credentials being abused?