What breaks when multi-factor authentication still relies on SMS codes or push approvals?

Traditional MFA can fail when attackers intercept one-time codes, trick users into approving prompts, or exploit push fatigue. Those methods improve protection over passwords alone, but they still depend on channels that can be socially engineered or hijacked. Security teams should treat them as weaker than phishing-resistant authentication and limit their use for high-value access.

Why This Matters for Security Teams

SMS codes and push approvals are convenient, but convenience is not the same as phishing resistance. Attackers can intercept text messages, relay one-time codes in real time, or exploit repeated push prompts until a user approves. That means the second factor can still be socially engineered, even when the password is gone. NIST SP 800-53 Rev 5 Security and Privacy Controls frames authentication as part of a broader access control and verification problem, not a single checkbox.

For security teams, the practical failure is that these factors often look “good enough” in policy while still leaving high-value access exposed to adversary-in-the-middle attacks, mobile malware, SIM swap abuse, and prompt fatigue. NHI Management Group research shows how quickly identity abuse becomes operationally damaging once credentials are compromised, including the 80% of identity breaches involving compromised non-human identities such as service accounts and API keys, which is a reminder that weak verification channels rarely stay a human-only problem for long. In practice, many security teams discover the weakness only after a mailbox, VPN, or admin console has already been accessed through a “successful” MFA event.

How It Works in Practice

The core issue is that SMS and push-based MFA verify possession of a channel, not the trustworthiness of the transaction. If an attacker can redirect a number, clone a device session, proxy a login page, or overwhelm a user with prompts, the verification step can be bypassed without ever defeating the password directly. Phishing-resistant methods such as FIDO2/WebAuthn, hardware-backed passkeys, or certificate-based authentication reduce that risk because the response is cryptographically bound to the origin and the device. Current guidance from NIST and ISO-aligned control programs treats stronger authentication as one element of a broader identity assurance model, not a substitute for least privilege or session governance.

In operational terms, teams should separate low-risk convenience flows from high-risk access paths. For example:

• Use phishing-resistant MFA for administrators, finance, source code, and production access.
• Reserve SMS only for recovery or constrained legacy scenarios, where there is no better option.
• Reduce push approvals by adding number matching, device binding, and anomaly detection.
• Pair MFA with conditional access, device posture checks, and short session lifetimes.

This matters because identity compromise often cascades into secrets theft, privilege escalation, and lateral movement. The Twitter Source Code Breach remains a useful reminder that once one account is trusted at the wrong moment, the blast radius can extend far beyond the original login. These controls tend to break down when legacy estates, consumer mobile fleets, or helpdesk-driven recovery processes force the organisation back onto SMS-based fallback paths because the weakest recovery flow becomes the real control plane.

Common Variations and Edge Cases

Tighter authentication often increases friction, support load, and recovery complexity, so organisations have to balance usability against the risk of account takeover. That tradeoff is real, especially for customer-facing systems, field workforces, or regions where device coverage and mobile reliability are inconsistent. Current guidance suggests treating SMS and generic push approvals as transitional controls, not a final state, but there is no universal standard for every recovery scenario yet.

One common edge case is account recovery. If a helpdesk can override phishing-resistant MFA with weak identity proofing, the “strong” factor is effectively bypassed at the back door. Another is service desk escalation during lockout events, where user frustration can drive unsafe resets. Security teams should also account for mobile-device compromise, SIM swap risk, and prompt bombing, all of which make approval fatigue more than a user-experience nuisance. If the business must keep push notifications, tighten them with number matching, geofencing, risk scoring, and step-up verification for privileged actions. For most high-value systems, the safer path is to move toward phishing-resistant authentication and use MFA that is bound to the device, the origin, and the transaction rather than the message channel alone.

Related resources from NHI Mgmt Group

• What breaks when multi-factor authentication is still built around passwords and basic biometrics?
• Why do SMS-based authentication codes still create security risk?
• How should security teams reduce identity risk when MFA still relies on passwords and SMS codes?
• When does multi-factor authentication still leave organisations exposed to account takeover?