Why do OTP and push-based MFA create risk in high-value enterprise access flows?

Why This Matters for Security Teams

OTP and push-based MFA still have value, but they create a false sense of safety in access paths where the attacker’s goal is to get a legitimate user to approve a malicious session. Reverse-proxy phishing, session hijacking, and MFA fatigue attacks do not need to break the factor itself; they only need to win the user interaction. That is why higher-assurance access cannot rely on approval prompts alone.

For security teams, the key mistake is treating “MFA enabled” as equivalent to phishing-resistant authentication. In reality, OTP and push methods authenticate a moment, not the intent behind it. Guidance from the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 both reinforce that control strength depends on the threat path, not the label on the factor. NHIMG’s Ultimate Guide to NHIs — Why NHI Security Matters Now shows how quickly enterprise identities can become systemic risk when protections lag behind attacker tactics.

In practice, many security teams discover this weakness only after a successful phishing or push-bombing campaign has already turned a valid login into an authorised compromise.

How It Works in Practice

In high-value access flows, the right question is not “Did the user approve?” but “Was the approval bound to the right device, the right origin, and the right transaction?” OTP and push-based MFA are vulnerable because they are often replayable, interceptable, or socially engineered. A reverse-proxy phish can collect the OTP in real time, while push fatigue can get a user to tap “approve” without verifying context.

Stronger patterns shift from simple second-factor checks toward phishing-resistant authentication and contextual access decisions. That typically means:

• Using FIDO2/WebAuthn or certificate-bound flows for privileged users instead of reusable OTP challenges.
• Binding authentication to device posture, user session, geo-velocity, and application risk signals at request time.
• Reducing approval prompts for sensitive actions by requiring step-up checks only when policy indicates elevated risk.
• Limiting session lifetime and re-authenticating only for truly high-impact operations, not every routine action.

This approach aligns with the intent of the NIST SP 800-53 Rev 5 Security and Privacy Controls, which emphasise authentication assurance, least privilege, and continuous control enforcement. It also fits the breach patterns discussed in NHIMG’s 52 NHI Breaches Analysis, where compromised identities often become the entry point for broader access abuse. For environments with service accounts, API access, or admin consoles, the same principle applies: reusable approvals create too much trust for too little proof.

These controls tend to break down when legacy applications cannot support phishing-resistant factors or when privileged access is shared across teams, because the authentication signal becomes detached from individual accountability.

Common Variations and Edge Cases

Tighter authentication often increases operational friction, so organisations must balance user experience against exposure on the most sensitive paths. There is no universal standard for this yet, and current guidance suggests a layered approach rather than a single replacement for OTP everywhere.

OTP and push can still be appropriate for lower-risk internal access, helpdesk workflows, or recovery scenarios where stronger options are not yet deployable. The risk rises sharply when the flow grants administrative control, production access, financial authority, or access to secrets and tokens. In those cases, best practice is evolving toward phishing-resistant methods, conditional access, and transaction-specific approval.

Two practical edge cases matter. First, fallback and recovery flows often become the weakest link, so a strong primary factor loses value if reset paths still allow OTP-only verification. Second, device-bound authentication is not enough if the endpoint itself is compromised, because the attacker may inherit a trusted session. NHIMG’s Ultimate Guide to NHIs is clear that control quality depends on lifecycle discipline, not just initial configuration.

For high-value access, organisations should treat OTP and push as convenience controls, not final proof against targeted intrusion.

Related resources from NHI Mgmt Group

• When does MFA create enough assurance for high-risk access?
• Why do SMS-based MFA flows create more risk than TOTP in custom auth systems?
• Why do non-human identities create more risk than many human accounts?
• Why do non-human identities create more remediation risk than many human accounts?