Why do push approvals and OTPs fail against modern MFA attacks?

Because both rely on something a user can be tricked into giving away or approving. Attackers use reverse-proxy phishing, MFA fatigue, SIM swaps, and OTP interception to turn the second factor into a liability. Once the factor is replayable or socially engineerable, it no longer provides strong assurance.

Why This Matters for Security Teams

Push approvals and OTPs fail because they still assume the human can reliably distinguish a legitimate prompt from a deceptive one. Modern attackers do not need to break encryption to win; they trigger fatigue, intercept codes, or relay a valid session through a reverse proxy until the user approves access for them. That is why identity teams now treat MFA bypass as an operational reality, not an edge case, especially when exposed credentials or session tokens are involved.

The pattern shows up repeatedly in NHI incidents too, where stolen secrets and abused access paths let attackers move faster than defenders can react. NHI Management Group’s The State of Secrets in AppSec highlights how exposed credentials remain a persistent weakness, and the same lesson applies to human MFA: if an attacker can reach the factor, they can often turn it into consent. For broader attack-chain context, see the CISA cyber threat advisories and the Microsoft Midnight Blizzard breach.

In practice, many security teams encounter MFA compromise only after a trusted session has already been established, rather than through intentional detection of the attack path.

How It Works in Practice

Push and OTP failures are usually the result of a broken trust model, not a broken authenticator. A push prompt can be spammed until the user approves out of confusion. An OTP can be phished in real time, relayed by an attacker-controlled proxy, or intercepted through SIM swap and device compromise. Once the code or approval is replayable, it is no longer a meaningful assurance signal.

Current guidance increasingly favors phishing-resistant authentication, but there is no universal standard for every environment yet. FIDO2 and passkeys reduce replay risk because the authenticator binds the challenge to the origin, while device-bound credentials make interception much harder. For high-risk workflows, security teams should also combine MFA with conditional access, transaction signing, and continuous session evaluation so the second factor is not treated as a one-time gate. The 52 NHI Breaches Analysis shows how quickly stolen access artifacts can be weaponized once they are outside the intended trust boundary.

• Prefer phishing-resistant factors over SMS OTPs and approval prompts for privileged access.
• Bind authentication to device, origin, and risk context wherever possible.
• Limit approval fatigue by reducing prompt volume and adding number matching or challenge detail.
• Detect anomalous relays, impossible travel, and repeated failed prompts as active attack signals.

For implementation patterns, the MITRE ATT&CK Enterprise Matrix helps map phishing, proxying, and session hijacking techniques to defensive detections, while NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls provides control families for authenticator management and session protection.

These controls tend to break down when legacy VPN, VDI, or helpdesk reset workflows still allow a single approval or code to unlock broad enterprise access.

Common Variations and Edge Cases

Tighter MFA controls often increase user friction and support load, requiring organisations to balance stronger assurance against login usability and recovery complexity. That tradeoff matters because many bypasses happen during exceptions, not normal sign-in. If recovery paths are weak, an attacker simply shifts from MFA abuse to account recovery abuse.

For low-risk applications, OTPs may remain acceptable as a step-up factor, but best practice is evolving toward stronger verification for administrative, financial, and production-access actions. In shared-device, call-center, or contractor-heavy environments, number matching, device binding, and session re-authentication often matter more than the initial login factor. For agentic and machine-access scenarios, passwordless human MFA is still the wrong model entirely, because the real problem is identity assurance for software actors, not people. See NHI Management Group’s Ultimate Guide to NHIs — Key Challenges and Risks and the Top 10 NHI Issues for the broader identity risk pattern.

Where SMS remains in use, telco takeover and roaming delays can make OTP delivery unreliable; where push remains in use, prompt bombing and proxy phishing can make approval meaningless. Security teams should treat these as design constraints, not user mistakes.

Related resources from NHI Mgmt Group

• Why do OTP and push approvals fail against adversary-in-the-middle attacks?
• Why do MFA controls fail against token-based SaaS attacks?
• Why do MFA codes still fail against vishing attacks?
• Why do traditional MFA methods fail against phishing attacks?