Why do OTP and push approvals fail against adversary-in-the-middle attacks?

Why This Matters for Security Teams

OTP and push approvals are often deployed as if they authenticate the site, but they mostly authenticate user presence or intent. That distinction matters because an adversary-in-the-middle (AiTM) proxy can relay the real login flow in real time, capture the approval, and immediately reuse the resulting session token or cookie. Current guidance from CISA cyber threat advisories and NHIMG’s 52 NHI Breaches Analysis shows that token theft and session replay are now routine follow-on actions after initial credential interception.

This is not a weakness in the OTP itself so much as a mismatch between the control and the threat model. OTP and push can still reduce opportunistic password reuse, but they do not bind the authentication event to a trusted origin or an attacker-resistant device context. In practice, teams that treat MFA as the endpoint of assurance often discover that the session is already compromised while the login still appears successful. In practice, many security teams encounter this only after a valid session has already been hijacked, rather than through intentional detection of the proxy.

How It Works in Practice

An AiTM attack inserts a proxy between the user and the legitimate service. The user sees a real-looking login page, submits their password, and then completes an OTP or push approval. The attacker forwards each step to the real service, which issues a valid session because the factors were entered correctly. The core failure is that the service cannot tell whether the approval came directly from the user’s device path or through a hostile relay.

That is why static, reusable second factors are weaker against modern phishing kits than they are against basic password theft. A push notification confirms a human tapped approve, but it usually does not prove the authentication ceremony occurred on an unmodified, trusted channel. Security architectures are moving toward phishing-resistant methods that bind the authentication to the origin and device, such as FIDO2/WebAuthn, certificate-based device trust, or conditional access that evaluates risk at request time. NIST’s guidance on phishing-resistant authentication and zero trust principles supports this direction, and NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks reinforces how quickly valid credentials can be abused once a session is obtained.

• Use phishing-resistant MFA where possible, especially for privileged and remote access.
• Bind authentication to device, browser, or platform attestation when the environment supports it.
• Shorten session lifetimes and re-check risk before sensitive actions, not just at login.
• Monitor for token replay, impossible travel, and new session fingerprints after MFA success.

For agents and automation, the same lesson applies even more strongly: authentication should prove workload identity and policy context, not just that a factor was approved. When the environment depends on legacy OTP or push flows for high-value access, these controls tend to break down when a real-time proxy can preserve the entire login conversation because the service still sees a legitimate, completed transaction.

Common Variations and Edge Cases

Tighter authentication often increases user friction and support overhead, so organisations have to balance usability against phishing resistance. That tradeoff becomes especially visible in helpdesk resets, legacy VPNs, and BYOD access, where full device trust may not be available. Best practice is evolving, and there is no universal standard for every application, but the trend is clear: the more valuable the session, the less acceptable a factor that can be relayed in real time.

Some environments still rely on OTP or push as a step-up control for low-risk apps, internal portals, or break-glass access. That can be reasonable when paired with stronger downstream controls, but it should not be mistaken for proof of site authenticity. Hardware-backed authenticators, passkeys, and origin-bound WebAuthn flows reduce relay risk much more effectively than codes or approvals alone. For a broader threat view, NHIMG’s Ultimate Guide to NHIs — Why NHI Security Matters Now and the OWASP NHI Top 10 show how session theft and credential replay sit inside a larger identity failure pattern, not a single MFA flaw.

Where MFA is tied to legacy SSO, long-lived sessions, or weak conditional access, the control often fails after initial approval because the attacker keeps the session and the user never sees the proxy again.

Related resources from NHI Mgmt Group

• Why do phishing-resistant methods still fail against man-in-the-middle attacks?
• Why do OTP-based step-up flows fail for sensitive access?
• Why do MFA controls fail against token-based SaaS attacks?
• How should security teams stop adversary-in-the-middle attacks on MFA-protected accounts?