Why do traditional MFA controls fail against social engineering campaigns like Scattered Spider?

Traditional MFA fails when the factor can be redirected, coerced, or socially engineered. Push fatigue, SIM swap, and one-time code theft all exploit the fact that possession is not proof of the real user. Phishing-resistant authentication reduces this risk because the challenge is bound to the legitimate identity registration and cannot be reused by a caller.

Why This Matters for Security Teams

Scattered Spider-style campaigns work because many organisations still treat MFA as a final barrier rather than a weakly bound proof step. Once a help desk, user, or approval workflow can be manipulated, attackers do not need to “break” the factor; they only need to redirect it. That is why phishing-resistant authentication and stronger identity proofing matter so much in modern controls like NIST SP 800-63 Digital Identity Guidelines.

The real issue is not just code theft. Push fatigue, SIM swap, and social approval bypass turn the MFA process into a human trust problem, and human trust is exactly what extortion crews exploit. NHIMG research on the Microsoft Midnight Blizzard breach shows how identity workflows can become the entry point for broader compromise when verification steps are too easy to manipulate.

In practice, many security teams encounter MFA bypass only after the attacker has already obtained a session, reset a factor, or escalated through the service desk, rather than through intentional testing of the recovery path.

How It Works in Practice

Traditional MFA assumes possession equals legitimacy, but that assumption fails when an attacker can persuade a victim to approve a prompt, convince support to reset a factor, or intercept an OTP. Current guidance suggests the strongest response is to reduce reliance on reusable, human-mediated factors and move toward phishing-resistant authentication tied to the registered identity, such as hardware-backed passkeys or FIDO2-based methods. The NIST identity guidelines support this direction because the authenticator must be bound to the legitimate account enrollment.

Operationally, this means tightening the whole identity lifecycle, not just the login screen. Teams should:

• Require phishing-resistant methods for privileged users, admins, and high-risk access paths.
• Remove SMS OTP from recovery flows where feasible, since SIM swap attacks can redirect the factor.
• Harden help desk scripts, escalation checks, and identity proofing for password and factor resets.
• Use conditional access to flag impossible travel, unfamiliar device enrollment, and unusual reset requests.
• Monitor for repeated push requests and rapid factor changes, which often precede session theft.

This issue is not theoretical. NHIMG coverage of the JetBrains GitHub plugin token exposure and the DeepSeek breach shows how quickly exposed credentials and weak identity controls can be chained into broader account abuse. The control objective is to make every reset, approval, and second factor harder to socially engineer than the attacker’s expected payoff. These controls tend to break down in outsourced service desks and high-pressure incident environments because adversaries exploit urgency, ambiguity, and inconsistent verification steps.

Common Variations and Edge Cases

Tighter authentication often increases friction for users and support teams, so organisations have to balance resilience against operational overhead. That tradeoff matters most where privileged access, remote support, or executive account recovery is frequent, because attackers target the fastest path, not the strongest password.

There is no universal standard for every recovery scenario yet, but best practice is evolving toward phish-resistant MFA for primary sign-in and stricter out-of-band controls for resets. In high-risk environments, a backup code or SMS fallback may still exist, but it should be treated as a degraded path with extra verification, not an equal alternative. The NHIMG standards guide is useful for mapping those identity decisions to broader NHI governance expectations.

Security teams should also account for edge cases such as executive assistants, shared devices, roaming contractors, and outsourced support centres. These environments often normalize exceptions, and exceptions are where social engineering succeeds. MFA fails less often because the technology is weak than because the surrounding process allows a caller to become the owner of the authentication event.

Related resources from NHI Mgmt Group

• Why do traditional identity processes fail against social engineering and hiring fraud?
• Why do phishing-resistant MFA controls still fail against social engineering?
• Why do traditional visitor controls fail against modern social engineering?
• Why do static login controls fail against AI-assisted attacks?