MFA Fatigue Attacks: Why ‘Just Add MFA’ Isn’t Enough Anymore

For years, the advice was simple: turn on multi-factor authentication and most account takeover risk goes away. That advice hasn't aged well. Attackers have adapted, and one technique in particular, MFA fatigue, is quietly undoing the protection that push-based authentication was supposed to provide.

The uncomfortable part is that nothing has to be broken for it to work. No malware runs, no exploit fires, no control fails an audit. A real person approves a real prompt on a real device, and the attacker walks in through the front door holding a legitimate session. That is why this deserves more than a line item on a security checklist.

What an MFA fatigue attack actually looks like

The anatomy of a push-bombing run

The attacker already has a valid username and password, usually from a previous breach, a phishing kit, or credential stuffing against a password reused somewhere less careful. That is normally where the attack stalls, because logging in also triggers a push notification to the user's phone asking them to approve the sign-in.

Instead of giving up, the attacker simply tries again. And again. Sometimes dozens of times in a row, often late at night, during a Monday morning inbox rush, or in the middle of a school run. Eventually, out of irritation, confusion, or the assumption that it is a glitch, someone taps "approve". The attacker is in, with a fully authenticated session and a session token that keeps them in.

The mechanics are deliberately boring. There is no zero-day and no custom tooling required. The attacker is not attacking your identity platform at all, they are attacking a tired human being's tolerance for notifications.

The help-desk voice on the other end

Push bombing gets far more effective when a second person joins in. A follow-up call, WhatsApp message or Teams chat arrives from "IT support", apologising for the noise and asking the user to approve just one prompt so the sync issue can be cleared. Sometimes the caller already knows the user's name, job title, manager and office location, all of which are easy enough to assemble from a company website and LinkedIn.

That combination of technical pressure and a plausible human explanation is what makes the technique work against people who would confidently tell you, in a training session, that they would never fall for it. Because the failure is a judgement call made under pressure rather than a technical flaw, security awareness training that rehearses this exact scenario — the buzzing phone, the helpful voice, the request to approve just one prompt — does more good here than general advice about suspicious links.

The variants worth knowing about

• Registration hijack. If a user has a password but has never enrolled a second factor, the attacker enrols their own. No fatigue needed, and the account now looks properly protected on paper.
• Help-desk social engineering. Rather than fatiguing the user, the attacker phones your service desk and talks an agent into resetting the MFA method for a "locked out" employee.
• Adversary-in-the-middle phishing. A reverse-proxy phishing page sits between the user and the real sign-in page, relays the password and the one-time PIN in real time, and steals the resulting session cookie. The user genuinely signs in, everything looks normal, and the attacker replays the stolen token. This one defeats every code-based and approval-based factor there is.

Why push approval and SMS are weak factors

It helps to be precise about what each factor actually proves.

A password proves knowledge of a secret that can be stolen at scale. An SMS one-time PIN proves control of a phone number, which in South Africa is a meaningful weakness given how well established SIM-swap fraud is here, and which can be intercepted or socially engineered out of a person in seconds. A time-based code from an authenticator app is better, because it never travels over the mobile network, but it is still a short string a person can be persuaded to read out or type into a convincing lookalike page.

Push approval is the interesting case. It removes typing, which is why it became popular, but in doing so it reduces the entire authentication decision to a single binary tap with almost no context attached. The user is asked to make a security judgement with no information about who is signing in, from where, or why. Under repeated pressure, "approve" is simply the button that makes the phone stop buzzing.

The common thread is that all of these factors can be relayed. A code or an approval generated for the real site works just as well for an attacker sitting in the middle, because nothing in the process is tied to the website the user is actually on.

What phishing-resistant authentication actually means

"Phishing-resistant" is not a marketing adjective. It describes a specific property: the credential is cryptographically bound to the legitimate site, and the browser or operating system enforces that binding without asking the user to judge anything.

With FIDO2 and WebAuthn, the open standards behind passkeys and hardware security keys, a private key is generated on the authenticator and never leaves it. That key is registered against one specific domain. When a user lands on a lookalike domain, the browser looks for a credential for that origin, finds none, and the sign-in simply does not proceed. There is nothing to read out, nothing to type, and nothing to approve out of context. The relay attack described above has nothing to relay.

The main phishing-resistant options in practice:

• Device-bound passkeys on hardware security keys. A physical key held by the user, typically USB or NFC. The strongest option, and the right one for administrators and high-risk roles.
• Platform passkeys / synced passkeys. Stored in the operating system or browser credential manager and protected by the device's biometric or PIN. Far more convenient to roll out, and still origin-bound, though the sync mechanism means the credential exists in more than one place.
• Windows Hello for Business. Platform authentication built on the same standards, tied to a specific device and unlocked with a biometric or PIN.
• Certificate-based authentication. A client certificate issued by your own PKI, on a smart card or provisioned to a managed device. Strong and well understood, but it presumes you have certificate lifecycle management you can actually run.

Number matching is a stopgap, not the destination

Number matching replaces the approve/deny tap with a number shown on the sign-in screen that the user must type into their authenticator app. It is genuinely valuable: it breaks the reflex tap, and an attacker who cannot see the sign-in screen cannot supply the number. Microsoft has made it the default behaviour for Authenticator push, and other identity providers offer equivalents.

But it is a mitigation for fatigue, not for phishing. In an adversary-in-the-middle scenario the attacker's proxy displays the correct number to the victim, who dutifully enters it. Treat number matching as the control you switch on this week while you plan the move to phishing-resistant methods, not as the finish line.

Comparing the factors honestly

Authentication factor	Resists push fatigue	Resists phishing / AiTM relay	Deployment friction	Sensible use
Password only	No	No	None	Never on its own
SMS or voice OTP	Partially	No	Very low	Last resort; vulnerable to SIM swap
Authenticator app code (TOTP)	Yes	No	Low	Baseline for low-risk accounts
Push approval (plain approve/deny)	No	No	Very low	Should be phased out
Push with number matching	Mostly	No	Very low	Immediate interim control
Platform / synced passkey	Yes	Yes	Moderate	Broad workforce rollout
Hardware security key (FIDO2)	Yes	Yes	Higher (procurement, logistics)	Admins, finance, executives
Certificate-based authentication	Yes	Yes	High (needs PKI and device management)	Managed-device fleets

The pattern is clear enough. Everything that can be typed, read aloud or tapped can be relayed. Everything bound to an origin by cryptography cannot.

A rollout path a mid-sized SA business can actually follow

Very few organisations can move an entire workforce to security keys in one weekend, and pretending otherwise is how these projects stall. A phased approach works better, and each phase reduces real risk on its own.

Phase 1 — remove the easy wins from the attacker (days, not months)

• Turn off plain approve/deny push everywhere and require number matching, with application name and sign-in location shown in the prompt.
• Remove SMS and voice as permitted factors for anyone with administrative rights, and set a date to remove them generally.
• Block legacy authentication protocols that skip MFA entirely.
• Confirm every account has a second factor enrolled, including service accounts, shared mailboxes, contractors and dormant accounts.
• Write down the help-desk identity verification procedure for MFA resets, and make it non-negotiable.

Phase 2 — protect the accounts that matter most (weeks)

• Issue hardware security keys to global administrators, finance and payments staff, and the executive team. Two keys each, so a lost key is an inconvenience rather than a lockout.
• Require phishing-resistant authentication for administrative role activation, with no fallback to weaker methods.
• Keep a documented, tested break-glass account with its own strong factor, stored securely offline.

Phase 3 — extend to the workforce (a quarter or two)

• Enable platform passkeys for staff on managed devices and let convenience do the persuading, because passkey sign-in is genuinely faster than what it replaces.
• Track adoption by department and follow up with the stragglers rather than announcing once and hoping.
• Retire weaker factors as coverage grows, department by department, instead of in a single disruptive cut-off.

Phase 4 — keep it honest

• Review registered authentication methods quarterly for accounts that quietly regained a weak factor.
• Include MFA fatigue and help-desk impersonation in awareness training by name, not just "phishing" in general.
• Rehearse the response: what happens when a user reports a prompt flood at 22:00 on a Friday?

If this is more than your internal capacity can absorb alongside everything else, it is a natural fit for a co-managed or fully managed IT arrangement, where identity hygiene is somebody's standing responsibility rather than a project that keeps slipping.

Conditional access is the control around the control

Strong factors decide how someone authenticates. Conditional access and risk-based policies decide whether the attempt should be entertained at all, and that is where much of the practical value sits.

Useful policies to have in place:

• Device compliance. Require a managed, compliant device for access to email and business data, so a stolen credential on an unknown machine gets nowhere.
• Sign-in risk. Where your platform scores risk on impossible travel, anonymised IP ranges and unfamiliar sign-in properties, require re-authentication with a strong factor or block outright.
• Session controls and token protection. Bind sessions to the device where supported, and shorten session lifetimes for high-privilege roles. This is the layer that limits the damage of a stolen token.
• Administrative isolation. Separate administrative identities from day-to-day mailbox accounts, and require phishing-resistant authentication plus just-in-time activation for those roles.
• Throttling and alerting. A burst of repeated authentication requests should raise an alert to whoever watches your logs, not simply generate more notifications for the user. Detection matters here, because the sign-in logs show a very recognisable pattern: many prompts, same session, short window, unfamiliar location.

Conditional access is also where a Microsoft 365 tenant most often disappoints on inspection, because policies get configured during migration and never revisited. It is worth reading through what the Microsoft 365 defaults leave uncovered if your tenant has not been reviewed in a while.

Where POPIA fits in

POPIA requires responsible parties to put appropriate, reasonable technical and organisational measures in place to protect personal information, and to keep those measures current with generally accepted practice. Phishing-resistant authentication has moved firmly into that territory for accounts holding personal information, and continuing to rely on SMS codes for administrator access is increasingly hard to defend as reasonable.

The obligation is not only preventative. A mailbox takeover is a security compromise, and it triggers duties to investigate, to notify the Information Regulator, and to notify affected data subjects where their personal information has been accessed. Sign-in and audit logging is what makes that investigation possible at all: without it, you cannot establish what the attacker read, forwarded or exported, and you are forced to assume the worst. Verify that audit logging is enabled and retained for long enough to be useful before you need it.

Business email compromise is usually where this ends up, so the guidance on what actually goes wrong with business email is worth reading alongside this.

The takeaway

MFA remains one of the best security investments a business can make. The "set it and forget it" version of MFA is no longer enough on its own, because the attacker has stopped trying to break the factor and started working on the person holding it.

The sequence is not complicated. Switch off blind push approval and require number matching now. Get hardware keys into the hands of your administrators and finance team next. Move the rest of the workforce to passkeys over the following quarter. Wrap the whole thing in conditional access, device compliance and monitoring that treats a flood of prompts as an incident rather than noise. None of these steps is dramatic in isolation, but together they take the human judgement call out of the loop, which is precisely the thing attackers have learned to exploit.

If you would like a second pair of eyes on how identity is configured in your environment, that is part of what our cybersecurity services cover.

Frequently asked questions

Is MFA still worth enabling if attackers can bypass it?

Yes, without qualification. MFA still blocks opportunistic credential-based attacks, which rely on a password alone and stop dead when a second factor is required. The point is not that MFA has failed, it is that the weakest forms of MFA are now routinely worked around, so the goal has shifted from "do we have MFA" to "which factors are we accepting, and for which accounts".

What is the single fastest change we can make this week?

Require number matching and remove plain approve/deny push from your tenant, then remove SMS as an allowed factor for anyone with administrative rights. Both are configuration changes rather than projects, and they close the specific gap that MFA fatigue attacks exploit.

Are passkeys secure enough for a small business, or do we need hardware keys?

Platform passkeys on managed devices are a large step up from codes and push approval, and for most staff they are the right balance of security and practicality. Hardware security keys are worth the extra cost and logistics for the accounts that would cause the most damage if taken over: global administrators, finance and payments approvers, and executives.

What should staff do when they get a flood of unexpected MFA prompts?

Deny every prompt, do not approve one to make them stop, and report it immediately. A prompt flood means someone already has that user's password, so the password needs to be changed and the sessions revoked. Staff should also treat any call or message asking them to approve a prompt as suspicious by default, even when the caller sounds like internal IT.

How do we know whether this has already happened to us?

Check your identity platform's sign-in logs for repeated authentication requests against a single account in a short window, sign-ins from unfamiliar locations or anonymised IP ranges, and any new authentication methods registered recently. Also review mailbox rules across the organisation, because attackers routinely create forwarding or auto-delete rules to hide their activity after a successful takeover.

This article is general information, not legal advice. POPIA decisions, correspondence with the Information Regulator and enforcement responses should be taken with a South African admitted attorney, and accountability rests with your Information Officer.