How should organisations reduce the risk of social engineering when MFA still leaves users fatigued and overexposed?

Why MFA fatigue changes the social engineering problem, not just the login flow

MFA reduces account takeovers, but repeated prompts, weak recovery paths, and habit-forming approval behaviour can turn it into a social engineering surface. When users are tired or overloaded, attackers do not need to defeat the factor itself, they need to exploit the human decision around it, then pivot into the account, session, or help desk path that follows.

That means the organisation is managing two linked risks at once: authentication abuse and user overexposure. The safer design question is not whether MFA exists, but whether the whole sign-in and recovery experience makes it easy to tell genuine prompts from malicious ones.

Controls that help are stronger authenticators, push fatigue reduction, step-up checks for risky events, and clear user-facing cues that make unexpected prompts easier to reject. The most effective programs also limit how often users are asked to approve low-signal requests in the first place.

Which controls actually reduce the chance of approval-based compromise?

Phishing-resistant MFA is the best starting point because it removes many replay, relay, and prompt-based attacks that exploit ordinary OTP or push workflows. NIST SP 800-63 Digital Identity Guidelines is the clearest external reference for authenticator assurance and phishing-resistant authentication choices.

From an operational standpoint, the most important controls are the ones that reduce silent acceptance: number matching, device-bound authenticators, conditional access, and session binding that makes a stolen approval less useful. If the user can approve a prompt without context, the attacker is already winning the interaction design.

Recovery matters just as much as sign-in. If password reset, MFA reset, or help desk verification is weak, attackers will target the back door rather than the primary factor. Strong recovery design closes the social engineering path that often follows an MFA prompt failure.

What should organisations harden around MFA fatigue and user trust?

Organisations should assume that attackers will combine phishing, vishing, token theft, and help desk impersonation until they find the easiest bypass. The practical defence is to harden the identity system around the factor, not only the factor itself, so that fatigue does not become a permanent exception path.

Internal guidance that maps well to this problem includes the Workforce Identity Security Guide, which covers phishing-resistant MFA, recovery, and session theft, and the Account Recovery and Help Desk Security Guide, which focuses on caller verification and reset abuse. For teams selecting platforms, the Identity Provider and SSO Security Guide helps frame how session, token, and federation controls reduce the blast radius of a compromised approval.

Where MFA fatigue is already a known weakness, organisations should tighten authentication triggers, monitor repeated prompts, and treat unusual recovery requests as high-risk events. A calm, explicit recovery process is often more effective than adding more prompts to the front door.

What does good practitioner response look like when fatigue is part of the threat model?

The right operating model is to reduce prompt volume, improve prompt quality, and make recovery deliberately harder than casual approval. That usually means moving the highest-risk users and actions to phishing-resistant methods first, then tightening help desk and reset workflows before expanding the rollout.

It also means teaching users what a real approval request should look like, but not pretending training alone solves the issue. MFA Guide and Passwordless and Passkeys Guide are useful for understanding why passkeys and FIDO2 reduce exposure to fatigue-driven approval abuse.

If users are repeatedly asked to approve prompts for routine activity, that is a design smell, not a user discipline problem. The long-term goal is to make suspicious requests rare, obvious, and difficult to convert into account access.

Risk and Threat Considerations

MFA fatigue creates a narrow but powerful opening for attackers because it shifts the attack from cryptography to human attention. A user who is overloaded, distracted, or conditioned to approve prompts may accept a malicious request, after which the attacker can use the resulting session or recovery path to deepen access.

Failure mechanism: Repeated prompts, help desk impersonation, token theft, and weak recovery controls combine to turn a valid authentication workflow into a social engineering channel. Once the attacker gets one approval, a session or reset path may be enough to bypass the original factor.

Impact: The likely outcome is account takeover, internal application access, and follow-on data exposure or lateral movement. At scale, even a small approval rate can matter if the same workflow is used across many employees or privileged users.

Practitioner Guidance

What to prioritise: Start with the identities and actions that create the highest blast radius, such as administrators, finance, support, and remote access users. Those groups benefit most from phishing-resistant methods and the strictest recovery checks.

What to verify: Confirm that MFA resets, password resets, and device re-enrolment require robust caller verification and are monitored for unusual patterns. If the recovery path is easier than the login path, the attacker will choose it.

Common mistake: Treating repeated prompts as a training problem only. Training helps, but if the workflow still encourages blind approval, fatigue will eventually produce a compromise.

Practitioner takeaway: The real control objective is not fewer MFA prompts, it is fewer unsafe decisions under pressure, with recovery and session handling designed so a single mistaken approval does not become full access.

Related resources from NHI Mgmt Group

• How can organisations reduce risk from browser-based social engineering against AI tools?
• How can organisations reduce the risk of deepfake-driven social engineering?
• How should organisations reduce phishing risk when users still receive convincing spoofed emails?
• Why do traditional security awareness programs fail to reduce risk in organizations with privileged users and modern social engineering threats?