Why do vishing and MFA fatigue still work against organisations with MFA?

Why MFA does not stop social engineering by itself

MFA raises the bar, but it does not remove the attacker’s ability to persuade a person or to abuse a process. Vishing works when the attacker convinces a user or help desk agent that a legitimate reset, enrolment, or exception is needed. mfa fatigue works when repeated prompts condition someone to approve the wrong request. The control fails at the decision point, not the cryptographic factor.

That is why phishing-resistant sign-in matters: the weakness is often not the factor, but the recovery path and the human who can override it. Organisations should treat support workflows, enrolment changes, and reset exceptions as security controls, not just service desk tasks. The more authority those workflows carry, the more attractive they become to an attacker.

For a broader view of how weak MFA methods and recovery paths get abused, see MFA Guide, Workforce Identity Security Guide, and NIST’s NIST SP 800-63 Digital Identity Guidelines.

How attackers turn trust and recovery into access

Vishing usually aims at the help desk, account recovery, or device enrolment process. Once the attacker can convince support staff to add a new authenticator, remove an old one, or approve a reset, the attacker inherits a valid trust relationship and can authenticate as the user. In other cases, the attacker only needs a single approval or a tired user to accept enough prompts to open the session.

This is why MFA fatigue often pairs with another access path such as stolen credentials, session theft, or weak recovery identity proofing. MFA is not being “broken” in a mathematical sense. The attacker is abusing the organisation’s own trust decisions, especially where staff are trained to be helpful and fast rather than suspicious and strict.

Recent incidents make the pattern clear. The Cisco Yanluowang breach 2022 and Uber breach 2022 both show how social engineering around MFA can become initial access. The same abuse path is covered in the Identity Provider and SSO Security Guide, especially where help desk recovery and federation trust are part of the attack surface.

Attackers also use stolen credentials or session tokens to make the prompt look routine rather than suspicious. That is why CitrixBleed exploitation 2023 is relevant as a reminder that MFA can be bypassed when the session, not the password, becomes the target.

What actually reduces exposure in practice

The practical fix is to make recovery and approval paths harder to socially engineer than the sign-in flow itself. That means strong identity proofing for resets, separate verification for device changes, number matching or phishing-resistant MFA where possible, and tight logging on support actions that can rebind an account. The control objective is not only to block login, but to stop an attacker from converting pressure on a human into account ownership.

At scale, this becomes a governance problem as much as a technical one. If multiple teams can reset MFA, add devices, or bypass step-up checks, the organisation has created many equivalent attack paths. Good practice is to reduce the number of people who can perform high-impact recovery actions, make those actions attributable, and review them with the same seriousness as privileged access changes.

Useful implementation references include Passwordless and Passkeys Guide for phishing-resistant authentication and secure recovery, and IAM and Identity Provider Buyer's Guide for platform selection that supports stronger recovery controls.

Risk and Threat Considerations

When MFA can be reset, rebound, or socially overridden, the main risk is not factor compromise, but account takeover through process compromise. That can expose email, VPN, internal tools, admin consoles, and downstream systems that trust the account once the attacker has inherited it.

Failure mechanism: The attacker exploits a human, support workflow, or repeated push prompts until a legitimate trust event occurs, such as device enrolment, reset approval, or session creation.

Impact: The attacker gains durable authenticated access, often with the same permissions and trust edges as the real user, and can pivot to data theft, privilege escalation, or broader internal compromise.

Practitioner Guidance

What to verify: Check whether your reset and enrolment workflows require independent verification that is stronger than the sign-in flow they are protecting. If a help desk agent can restore access using easily social-engineered data, the control is too weak.

Common mistake: Treating MFA fatigue as a user-training issue only. Training helps, but it does not fix a recovery process that lets attackers convert pressure, urgency, or impersonation into a valid account change.

What good looks like: High-risk changes are rare, logged, reviewable, and hard to perform under pressure. Users cannot approve repeated prompts into a successful login, and support staff cannot casually rebind an account without stronger proof than the attacker can likely obtain.

Practitioner takeaway: If the attacker can reach the recovery path, they may not need to defeat MFA at all, so the real control question is whether your organisation can resist social engineering at the point where trust is reissued.

Related resources from NHI Mgmt Group

• Why do sprayed passwords and MFA fatigue still work against cloud tenants?
• Why do MFA codes still fail against vishing attacks?
• Why do MFA fatigue attacks still work in mature IAM programmes?
• Why do MFA fatigue attacks still work when MFA is already deployed?