How should security teams stop adversary-in-the-middle attacks on MFA-protected accounts?

Why This Matters for Security Teams

Adversary-in-the-middle attacks defeat the assumptions behind legacy MFA by intercepting the live login ceremony and replaying the resulting session in real time. That means security teams cannot rely on one-time codes, push approvals, or even “MFA enabled” as a meaningful control if the factor can be proxied. Phishing-resistant methods and session hardening must be treated as the baseline, not the exception, especially for privileged and cloud-linked accounts. This is why NHI Management Group consistently frames identity security as a session integrity problem, not just an authentication problem, as reflected in The 52 NHI breaches Report and the CISA cyber threat advisories on modern phishing tradecraft. The practical failure point is often not the initial compromise, but the assumption that a successful MFA event means the account is now trustworthy. In practice, many security teams encounter the problem only after an attacker has already established a durable session rather than through intentional validation of login provenance.

How It Works in Practice

Security teams should combine three layers: phishing-resistant authentication, device-bound conditional access, and continuous session evaluation. Passkeys based on WebAuthn or FIDO2 help because the assertion is origin-bound, which makes simple relay attacks much harder than with OTP or push approvals. Pair that with device trust signals, network context, and risk-based policy so that a login from an unmanaged device does not gain the same access as a managed endpoint. A workable implementation usually includes:

• Require WebAuthn or FIDO2 for all privileged users and any account that can administer cloud, SaaS, or CI/CD.
• Block legacy MFA flows where possible, especially SMS, TOTP-only, and approve/deny push for sensitive paths.
• Use conditional access to require managed device posture, compliant browser state, and step-up checks for high-risk actions.
• Shorten session lifetime, re-evaluate token use continuously, and revoke refresh tokens when risk changes.
• Log and correlate authentication, device, and token events so session hijack indicators can be detected quickly.

This is aligned with the direction of NIST Cybersecurity Framework 2.0 and the identity guidance in MITRE ATLAS adversarial AI threat matrix when identity abuse is part of a broader adversarial workflow. The same logic applies in environments where identity abuse is chained into cloud compromise, as discussed in Microsoft Midnight Blizzard breach and Top 10 NHI Issues. These controls tend to break down when legacy applications cannot consume modern tokens or when contractors and shared admin flows still depend on browser-based MFA exceptions because those paths preserve the attacker’s ability to proxy authentication.

Common Variations and Edge Cases

Tighter authentication controls often increase operational friction, so organisations have to balance user experience against the cost of a hijacked session. That tradeoff is real, especially for executive, help desk, and third-party access paths where speed has historically been prioritised over assurance. Current guidance suggests treating those exceptions as temporary and risk-scoped, not as permanent policy. A few edge cases matter. First, some environments support passkeys but still leave backup factors enabled, which creates a weak fallback an attacker can target. Second, federated SSO can give a false sense of safety if the IdP session itself is not continuously evaluated. Third, shared service accounts and break-glass accounts need their own controls, because they do not behave like normal user identities and often bypass standard conditional access. For teams mapping this work to broader identity maturity, Ultimate Guide to NHIs — Key Challenges and Risks and Anthropic — first AI-orchestrated cyber espionage campaign report show how quickly identity abuse becomes an operational foothold once a session is trusted. Best practice is evolving, but the direction is clear: authenticate the origin, constrain the device, and continuously re-check whether the session still deserves access.

Related resources from NHI Mgmt Group

• How should security teams stop help desk based MFA bypass attacks?
• Why are NHIs a critical concern for security teams?
• What steps should security teams take to prevent Shadow AI risks?
• Why is the abuse of NHIs a priority for security teams?