Why do push-based MFA and SMS codes fail against social engineering campaigns?

They fail because attackers target the human and the delivery channel, not the underlying authentication protocol. Push prompts can be fatigued into approval, and SMS can be redirected through SIM swapping or telecom compromise. When the factor is easy to coerce or reroute, it no longer provides high assurance for privileged access.

Why This Matters for Security Teams

Push-based MFA and SMS codes look familiar, which makes them easy to overtrust. In reality, both factors are vulnerable to human-targeted attack paths: push fatigue, adversary-in-the-middle prompts, help desk pretexting, and SIM swap or telecom takeover. That matters most when the account protects privileged access, SaaS admin functions, or cloud control planes, where a single approval can expose secrets, sessions, and downstream systems. NIST’s identity guidance makes clear that authenticator strength depends on how resistant it is to replay, interception, and coercion, not just whether it is “multi-factor” in name. See NIST SP 800-63 Digital Identity Guidelines and NHIMG’s analysis of MGM Resorts Breach 2023 for the operational pattern.

Security teams often treat MFA enrollment as a finish line, then leave recovery flows, push policies, and SMS fallback as soft targets. social engineering campaigns exploit that gap because the attacker is not defeating cryptography first; they are defeating the person, the process, or the carrier boundary. In practice, many security teams encounter MFA compromise only after an account is already being used to reset passwords, mint sessions, or move laterally.

How It Works in Practice

Attackers usually combine identity theft, pretexting, and timing. A push prompt appears during a login attempt, then repeated prompts create fatigue until one is approved. SMS codes are even weaker when an adversary can redirect the phone number through SIM swapping, port-out fraud, carrier compromise, or access to the victim’s mailbox and backup channels. For this reason, current guidance suggests treating push and SMS as convenience factors, not high-assurance proof for privileged access.

For stronger protection, organisations should move toward phishing-resistant authentication and tighter recovery controls. That includes FIDO2 or passkey-based authenticators, number matching or challenge binding where push is still used, strict help desk verification for resets, and reduced reliance on phone numbers as an identity anchor. NIST’s control catalog and identity guidance support these patterns, especially when layered with privileged access controls and monitoring from NIST SP 800-53 Rev 5 Security and Privacy Controls. NHIMG’s coverage of Storm-2949 Azure Breach shows how a single manipulated identity event can cascade into cloud compromise.

• Prefer phishing-resistant authenticators for admin, finance, and remote access paths.
• Remove SMS as a fallback where a stronger factor is available.
• Harden reset and recovery workflows, since attackers often bypass MFA through support channels.
• Alert on push storms, impossible travel, and unusual session creation after MFA approval.
• Limit standing privilege so one coerced approval does not expose broad access.

These controls tend to break down in distributed environments with legacy VPNs, carrier-dependent enrollment flows, or help desks that cannot consistently verify identity before resetting factors.

Common Variations and Edge Cases

Tighter authentication often increases user friction and support load, so organisations must balance assurance against operational continuity. There is no universal standard for every workforce, but the trend is clear: the higher the privilege, the less acceptable push and SMS become.

Some environments still retain SMS for account recovery, temporary contractor access, or regions where hardware authenticators are not yet practical. That is a tradeoff, not a security endorsement. Best practice is evolving toward layered recovery, device-bound authenticators, and policy-based step-up checks for risky logins. ENISA’s threat reporting reinforces that social engineering remains a dominant initial access path, which is why fallback channels deserve the same scrutiny as primary login.

Where defenders underestimate this problem, social engineering campaigns often pivot into NHI abuse as well, because stolen sessions and tokens are more durable than one-time codes. NHIMG’s reporting on the Microsoft Midnight Blizzard breach and the Uber Breach shows that identity compromise rarely stops at the first factor. When an attacker can influence recovery, capture a session, or trigger downstream trust, weak MFA becomes one link in a larger chain.

Related resources from NHI Mgmt Group

• Why do traditional MFA controls fail against social engineering campaigns like Scattered Spider?
• Why do phishing-resistant MFA controls still fail against social engineering?
• Why do MFA and SSO still fail against AiTM attacks?
• Why do MFA controls fail against token-based SaaS attacks?