Join our Newsletter — 33% off our NHI Course
Home FAQ Authentication, Authorisation & Trust Why do one-time codes and push-based MFA still…
Authentication, Authorisation & Trust

Why do one-time codes and push-based MFA still leave organisations exposed?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated September 23, 2026 Domain: Authentication, Authorisation & Trust

One-time codes can be intercepted through SIM swapping, malware, phishing, or mobile network abuse, and push approvals can be exploited through MFA fatigue. The weakness is not MFA itself, but relying on methods that users can be tricked into revealing or approving. Stronger controls reduce prompt volume, train users to reject unexpected requests, and prefer less spoofable authentication methods.

Why one-time codes and push approvals are still a weak second factor

One-time codes and push-based MFA add a barrier, but they do not eliminate the core problem: they still depend on a user receiving, recognising, and correctly responding to an authentication challenge in real time. If an attacker can intercept the code, socially engineer the user, or repeatedly pressure them into approving, the second factor becomes an access path rather than a stop sign. That is why “MFA enabled” is not the same as “MFA resilient.”

Weaknesses in this category are usually about the channel and the user decision, not the existence of a second factor. SMS codes can be diverted through SIM swap, telecom abuse, malware, or session interception. Push notifications can be accepted under fatigue, confusion, or urgency. In both cases, the control can be present while still being bypassable through common attack paths.

For practitioners, the important distinction is between a factor that proves possession and a factor that is hard to phish, replay, or coerce. One-time codes and generic pushes are often sufficient for low-risk convenience, but they are not the strongest choice where the account can reach sensitive systems, administrative functions, or high-value data.

Where the failure mode shows up in real environments

The risk is highest when the authentication flow relies on short-lived trust in a mobile device, messaging network, or user attention. Codes can be captured during phishing, relayed by adversary-in-the-middle tooling, or exposed when a device is compromised. Push-based approvals are especially vulnerable when users are conditioned to approve quickly, when requests arrive outside expected work patterns, or when repeated prompts create a habit of clicking through.

These methods also create uneven protection across the identity lifecycle. They may protect the login prompt, yet leave recovery flows, help desk resets, legacy applications, or privileged sessions weaker than the primary sign-in path. That gap matters because attackers often target the easiest adjacent route rather than the strongest visible one.

For a concrete example of push abuse, Uber’s MFA fatigue breach shows how repeated prompts can turn user approval into a compromise path. For code interception and credential abuse more broadly, Microsoft’s Midnight Blizzard breach illustrates how authentication controls can be bypassed when an attacker reaches an alternate path or weak account state. At a broader control level, the OWASP API Security Top 10 is useful when auth weaknesses spill into token, session, or authorisation abuse.

What stronger practice looks like for modern MFA

Better MFA does not just add more prompts. It reduces the chance that a human can be tricked into approving the wrong request and reduces the value of a captured code. Practically, that means preferring phishing-resistant methods where available, reducing unnecessary prompts, binding approvals to the actual login context, and making unexpected requests easy to reject.

Organisations should also treat MFA as part of an access design, not a standalone product checkbox. If the account can be reset through weaker recovery paths, if help desk workflows can be socially engineered, or if high-risk sessions are not separately protected, the authentication layer will not carry the full burden. That is why a control set built around verification strength, session risk, and recovery hardening is more durable than one built around prompt volume alone.

Useful reference points include NIST Cybersecurity Framework 2.0 for governance and access-control outcomes, NIST SP 800-63 Digital Identity Guidelines for authenticators and assurance strength, and NIST SP 800-207 Zero Trust Architecture for continuous verification and reduced trust in one-time sign-in events.

Risk and Threat Considerations

These MFA methods fail because they can be turned against the user rather than defeated by pure cryptography. Attackers target the delivery channel, device trust, or human reflex. The result is not usually a broken factor, but a successful login through interception, relay, repeated prompts, or induced approval.

Failure mechanism: The attacker captures, relays, or coerces the authentication event, often through phishing, SIM swap, malware, push fatigue, or session hijacking.

Impact: A valid login is granted to the attacker, which can lead to account takeover, data access, privilege escalation, or use of the account as a foothold for further movement.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0PR.AA-01 — Identity Management, Authentication and Access ControlCovers access control and stronger authentication outcomes for exposed accounts.
Recommendation — Enforce stronger authentication and reduce reliance on easily abused approval flows.
NIST SP 800-63AAL — Authentication Assurance LevelDefines assurance strength for authenticators like OTP and MFA methods.
Recommendation — Select authenticators that meet the required assurance level for the account risk.
NIST Zero Trust (SP 800-207)3.1 — Verify ExplicitlySupports continuous verification instead of trusting a single interactive login event.
Recommendation — Require explicit verification for each access attempt instead of trusting prior sign-in state.
CIS Controls v86 — Access Control ManagementAligns with managing authentication methods and reducing overexposed access paths.
Recommendation — Limit access paths to methods that resist interception and prompt abuse.
OWASP Non-Human Identity Top 10NHI-01 — Secret Sprawl and Credential ExposureRelevant where one-time codes, tokens, and reusable secrets become exposed or intercepted.
Recommendation — Reduce exposure of reusable secrets and prefer harder-to-phish authentication methods.

Practitioner Guidance

What to prioritise: Treat phishing-resistant authentication as the default for privileged, financial, administrative, and remote-access use cases. If the account can reach production systems or sensitive records, a one-time code or generic push should be treated as a transitional control, not the end state.

What to verify: Check whether recovery flows, help desk resets, backup methods, and legacy application logins are weaker than the primary MFA method. Many programmes harden the login prompt while leaving the recovery path as the easiest compromise route.

Common mistake: Measuring MFA success by deployment rate instead of resistance to prompt abuse. High adoption does not mean high assurance if users can still be phished, spammed, or manipulated into approving access.

Practitioner takeaway: The goal is not to add more authentication friction, it is to ensure that the factor is resistant to interception, replay, and human coercion in the paths attackers actually use.

Deepen Your Knowledge

Sign up to our weekly newsletter — get 33% off our NHI Foundation Level Course

    NHIMG Editorial Note
    Reviewed and updated by the NHIMG editorial team on September 23, 2026.
    NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org