Notifications
Clear all
Topic starter
25/08/2026 6:11 pm
TL;DR: Traditional MFA fails when attackers bypass the second factor through help desk social engineering, MFA fatigue, vishing, or SIM swapping, according to Trusona’s analysis. The real control boundary is identity verification and reset governance, because a strong authenticator cannot save a weak recovery process.
NHIMG editorial — based on content published by Trusona: Why Traditional MFA Fails Against Scattered Spider
By the numbers:
- Obsidian Security notes that attackers have figured out ways to subvert MFA in 70% of SaaS breaches.
Questions worth separating out
Q: How should security teams handle MFA resets and account recovery?
A: Treat MFA resets and account recovery as privileged actions.
Q: Why do traditional MFA controls fail against social engineering campaigns like Scattered Spider?
A: Traditional MFA fails when the factor can be redirected, coerced, or socially engineered.
Q: What do teams get wrong about phishing-resistant MFA?
A: They often measure success by the presence of a strong factor instead of the absence of weaker bypasses.
Practitioner guidance
- Reclassify MFA recovery as privileged access Put reset and device enrollment workflows under the same governance standards as high-risk administrative access, including approval rules, logging, and periodic review.
- Require secure identity proofing for resets Use verified app-based proofing, liveness checks, or equivalent controls before changing a factor or sending a reset link to any new channel.
- Eliminate discretionary help desk bypasses Remove informal exceptions, verbal approvals, and ad hoc manager overrides from factor reset procedures, especially for privileged accounts.
What's in the full article
Trusona's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step identity proofing workflow for help desk reset requests and factor enrollment.
- Specific guidance on callback controls, approval routing, and denial conditions for risky reset requests.
- Examples of phishing-resistant MFA patterns and device-bound recovery flows used to reduce support abuse.
- Process recommendations for training support staff to resist urgency, impersonation, and MFA fatigue.
👉 Read Trusona's analysis of why traditional MFA fails against Scattered Spider →
Traditional MFA and help desk resets: are your controls keeping up?
Explore further
25/08/2026 6:11 pm
Traditional MFA fails when recovery is weaker than authentication. The article shows that the real control boundary is not the login ceremony but the reset ceremony. If help desk staff can be manipulated into replacing a second factor, MFA becomes a recoverable inconvenience rather than a security control. Practitioners should treat factor recovery as part of the authentication lifecycle, not as an administrative side door.
Help desk recovery is now part of the identity attack surface. Organisations that still separate IAM from service desk operations will continue to miss the real control failure point, which is factor reissuance. With 70% of SaaS breaches already involving MFA subversion, the governance gap is structural rather than tactical, and support workflows need the same scrutiny as privileged access processes.
A question worth separating out:
Q: Who is accountable when a help desk reset leads to account takeover?
A: Accountability sits with the organisation that owns the recovery process, not just the individual agent who approved the action. Security, IAM, and service owners should define the controls, evidence standards, and escalation paths before resets can restore trust. If the process can be abused, the process owner owns the risk.
👉 Read our full editorial: Why traditional MFA fails against Scattered Spider attacks
