MFA fatigue: when the second factor gives in to exhaustion

The bottom line: the second factor does not fail on technology, it fails on human exhaustion

Once an attacker already has an employee's password, the only thing left in the way is the second factor. And that factor rarely falls because someone breaks an algorithm. It falls because a tired, interrupted person ends up approving an access request they never made. That is MFA fatigue: multi-factor authentication (MFA), the second step requested in addition to the password, is not broken by technical means, it is worn down by human means.

The uncomfortable part is that the technology did its job. The system asked for confirmation, exactly as it should. The breaking point comes later, in the moment when a twelfth notification, at eleven at night, gets the tap that makes it disappear. There is no machine failing in that scene, there is a person under pressure. That is why MFA fatigue is best understood for what it is: a social engineering technique that uses repetition and exhaustion as leverage, not a software defect.

What MFA fatigue and push notification bombing are

MFA fatigue is an attack that floods a person with approval requests until one of them is accepted. It is also known as push bombing or prompt bombing. The starting point is always the same: the attacker has already obtained the password, through an earlier leak, a phishing email, or password reuse, and now needs to get past the second factor.

With the password in hand, the attacker tries to log in again and again. Each attempt triggers a notification on the victim's phone, that window asking whether it was really you signing in. The bet is both statistical and psychological: if the requests keep coming, in the middle of a meeting, during dinner, or in the early hours, sooner or later the person approves, either by accident while unlocking the phone or simply to make the notifications stop. A single approval is enough. In that instant, the protection meant to stop the intruder lets them through.

Why approval-based MFA is vulnerable to pressure and repetition

Approval-based MFA is vulnerable because it delegates the security decision to an interrupted person and asks them for a judgment call under conditions designed to wear them down. The weakness is not the second factor itself, it is the kind of second factor: one resolved with a single tap, with no more context than the question of whether it was you.

That format has three cracks the attacker exploits at once. The first is ambiguity: the notification does not say where the attempt is coming from or why, so the person decides blind. The second is repetition: an isolated request gets examined, but the fifteenth one is no longer read, it is dismissed. The third is emotional context: the bombing arrives at the worst possible moment on purpose, when the person's priority is to get on with their work, not to audit a login. It helps to remember where the risk comes from. Cisco's 90-5-5 framework estimates that around 90 percent of breaches involve a human factor. We are not talking about careless people: we are talking about people doing their jobs, hit by one interruption after another until one of them gives in. This is the same root as all social engineering, manipulating trust and fatigue rather than breaking the machine, a pattern we explored when looking at how AI reshaped phishing and deepfakes.

Phishing-resistant MFA versus approval-based MFA

The core difference is simple: approval-based MFA asks the person to decide, and phishing-resistant MFA takes that decision out of their hands. That is the line between a second factor that can be worn down and one that cannot.

Approval-based MFA, whether a push accepted with a tap or a code typed in by hand, depends on the person validating each attempt correctly, and any method that relies on repeated human judgment can be worn down with volume and pressure. Phishing-resistant MFA works differently: it ties authentication to the device and the legitimate site, so an attempt from anywhere else simply does not complete, no matter how many times it repeats or what the person decides in the moment. CISA explicitly recommends adopting phishing-resistant MFA as the primary defense against MFA fatigue and against phishing in general, and points to the FIDO2 standard as the reference. For organizations that cannot migrate yet and still rely on push notifications, CISA proposes an interim measure, number matching: instead of a tap, the person must read a code shown on the login screen and type it into the authenticator app. That extra step breaks approval by inertia, because it forces the person to look at where the attempt is coming from before confirming it.

The comparison between both approaches reads more clearly in a table.

Neither layer makes a company invincible on its own, and migrating to phishing-resistant MFA takes time and budget. But the direction is clear: the less security depends on a human decision made under pressure, the less surface MFA fatigue has to work with.

How to prepare the person and validate that they resist the pattern

A complete defense combines technology and behavior: hardening the second factor while also confirming that the person recognizes the pattern when it is in front of them. The first reduces the surface, the second confirms that the reduction actually works with real people, not on paper.

On the technical side, the priority is to migrate toward phishing-resistant MFA and, while that happens, require number matching and cap how many requests in a row an account can trigger. On the human side, the person needs to know that a burst of approvals they did not request is not a technical glitch on the phone, it is an attack in progress, and that the right response is to deny and report, never to approve so it stops. Because the attack starts once the attacker already has the password, catching exposed credentials early closes part of the gap before the bombing begins.

Then comes the layer that is almost always skipped: confirming that the person truly resists the pattern, not just that they attended a talk about it. This is where the concept of retest matters. Explaining what MFA fatigue is to an employee and calling it solved is a comfortable illusion: there is peer-reviewed evidence that completing training does not, on its own, predict a reduction in real failures. What proves someone learned is not finishing the module, it is facing it again weeks later, with a different variant of the same pressure, and seeing whether this time they hold firm. Validating behavior change instead of assuming it is the core idea of human risk management (HRM), and it is what separates a real defense from a checked box.

At Fensivo we address this use case by pairing a realistic simulation of the pattern with later validation: a person who faces a scenario of pressure on their second factor and then faces it again, weeks later and with a different variant, proves through action that they learned not to give in, not that they remembered a talk. You can see how we approach it in our use cases.

How much of your accounts' security today rests on a tired person, at eleven at night, having the judgment to reject the twelfth notification instead of approving it to make it stop?