What Is MFA Fatigue? How Push Attacks Bypass Strong Security

• MFA Fatigue: An attack where hackers bombard a user’s device with repeated multi-factor authentication prompts (often push notifications) until the user unintentionally approves one.
• Where It’s Used Typically in targeted attacks after the attacker has stolen valid login credentials, against systems using push based MFA common in corporate networks and cloud services.
• Why It Matters: It exploits human behavior (fatigue, confusion) to bypass a critical security control. Even with MFA enabled, accounts can be compromised if a user is tricked into approving a rogue login.
• Key Risk A frustrated or inattentive user might tap Approve on a malicious prompt, giving an attacker access to internal systems and sensitive data despite MFA being in place.

MFA fatigue, also known as MFA prompt bombing or push fatigue, is a social engineering attack method aimed at defeating multi factor authentication protections. In plain terms, the attacker abuses the MFA system by incessantly sending approval requests to the legitimate user’s authentication device, like a smartphone app, hoping the user will eventually approve one of the requests out of annoyance or confusion. Unlike technical exploits that target software vulnerabilities, this technique targets the human element of security: it wears down the user’s vigilance.

This attack has gained prominence in recent years as organizations widely adopt MFA for identity security. Attackers who have already obtained a user’s password for example, via phishing or other credential theft techniques use MFA fatigue to bypass the remaining barrier. They keep triggering login attempts so that the MFA system sends repeated push notifications or calls to the user’s device. The relentless stream of prompts plays on the user’s impulse to just make it stop. In some cases, attackers even combine this with direct social engineering for instance, calling or messaging the user pretending to be IT support, urging them to approve the login to resolve a non-existent issue.

MFA fatigue matters today because it has been a factor in several high profile breaches and is recognized as a growing threat. It commonly appears in attacks on corporate VPNs, single sign on SSO platforms, cloud admin portals, and other identity driven services. Security teams have noted its use by groups like LAPSUS$ and Scattered Spider in MITRE ATT&CK it’s catalogued as T1621: Multi Factor Authentication Request Generation. In essence, MFA fatigue attacks turn a strength into a weakness: the very MFA alerts intended to protect the account are weaponized to trick users, highlighting why this tactic is a serious concern for modern identity and access management IAM defenses.

How MFA Fatigue Works

At its core, an MFA fatigue attack exploits the workflow of push based authentication. The attacker isn’t hacking the MFA technology, they’re tricking the user into inadvertently authenticating the attacker’s login. Here’s how it typically works step by step:

1. Initial Access via Stolen Credentials: First, the attacker acquires the user’s username and password, often through phishing or other social engineering, credential stuffing, or malware. Attackers also obtain that first password through password spraying, which tries a few common passwords across many accounts. In password-based MFA, without valid credentials they can’t even begin an MFA fatigue attempt. This means MFA fatigue usually comes after a credential compromise in the attack chain.
2. MFA Bombardment Begins: Using the stolen credentials, the attacker attempts to log in repeatedly to a service protected by MFA. Each login try triggers an MFA challenge for example, a push notification in the user’s authenticator app or a phone call or SMS with an approval request. The attacker may script these attempts to send a rapid fire flood of notifications, or sometimes send them at intervals even a few per hour to seem less obviously malicious. The key is the attacker can generate a large volume of legitimate looking auth requests.
3. User Fatigue and Confusion: The unsuspecting user’s device starts lighting up with incoming prompts: Approve sign in?. At first, a careful user will deny or ignore these since they know they’re not trying to log in. However, as the prompts keep coming, the user becomes increasingly annoyed or perplexed. Especially if this happens during off hours e.g. at 1 AM or during a busy workday, the user might assume it’s a system glitch or simply want to silence the constant interruptions. This is the psychological pressure point the attacker relies on the fatigue from alert overload.
4. Accidental or Reluctant Approval: Eventually, the attacker hopes, the user slips. The fatigue or distraction can lead the user to accidentally tap Accept or even consciously approve one request just to halt the barrage of notifications. In some recorded incidents, victims have reported clicking Approve thinking it would make the spam stop, not realizing they were thereby letting an intruder in. In more orchestrated cases, attackers have phoned the user concurrently posing as IT support to say something like, We’re troubleshooting an issue, please approve the login prompt adding social pressure to the technical bombardment.
5. Account Compromise and Post Access Moves: Once the user approves an attacker’s MFA request, the attacker is authenticated as that user. They gain the same access the user has often this means entry to internal corporate systems, cloud accounts, or email and collaboration platforms. The consequences can be severe: the attacker can browse the network and move laterally, steal data, or escalate privileges now that they’re inside the environment. Notably, savvy attackers will immediately take steps to maintain access. For example, after getting in, they may register their own device or token as a new MFA factor on the account. By enrolling a device they control, the attacker ensures subsequent logins won’t alert the victim with further MFA prompts preventing the user from realizing the ongoing compromise. At this point, the MFA fatigue attack has achieved its goal: the MFA barrier was effectively bypassed via human error, and the attacker can operate under the hijacked account.

It’s important to understand that MFA fatigue is fundamentally an abuse of the normal authentication process. No malware is required on the user’s phone or any technical cracking of the MFA mechanism, the attack works because the system trusts the user’s approval. In effect, the attacker tricks the legitimate user into authenticating the attacker’s login. This makes it a devious technique: it often leaves no malware fingerprints and can appear, in logs, as a valid user login preceded by some failed attempts. In the next sections, we’ll explore real examples of this attack in action and how defenders can recognize and counter it.

DeepStrike's Red Teaming Services test whether your users approve unexpected prompts and whether anyone flags the burst that came first.

Real World Examples

Uber 2022: One of the most publicized cases of MFA fatigue was the breach of Uber’s corporate network in September 2022. The attacker reportedly obtained an Uber external contractor’s password, likely via the dark web or malware on the contractor’s device. When the stolen password alone couldn’t grant access due to MFA, the attacker initiated a campaign of MFA prompt spamming. The contractor was bombarded with mobile push notifications asking to approve a login. According to reports, the hacker also contacted the contractor via WhatsApp, impersonating Uber’s IT department, and insisted that the endless MFA prompts were a technical issue that would be resolved only if one request was approved. Under pressure, the fatigued contractor eventually approved the login request, thinking it would stop the notifications. That one click allowed the attacker into Uber’s internal systems. Once inside, the attacker moved through Uber’s network at one point even posting a message company wide on Slack announcing the breach. This incident showcased how MFA fatigue coupled with impersonation can defeat a company’s defenses. Uber later confirmed the attack stemmed from this MFA fatigue technique, which was also linked to the LAPSUS$ hacking group’s tactics.

Cisco 2022: Another notable example occurred in May 2022, when networking giant Cisco was targeted by a threat actor associated with the Yanluowang ransomware group. The attacker had stolen an employee’s VPN credentials, but access was blocked by Cisco’s MFA. To get past it, the attacker resorted to a mix of voice phishing and MFA fatigue. They repeatedly triggered push notifications to the employee’s MFA app and simultaneously called the employee pretending to be support staff. The relentless combination of phone calls and app prompts eventually convinced the employee to approve one MFA request. As soon as that happened, the adversary gained entry to Cisco’s VPN. Critically, the attackers then enrolled their own devices for MFA on that account, so they wouldn’t need to bother the user again for future logins. With a foothold in Cisco’s network, they were able to drop hacking tools, escalate privileges, and pivot deeper into systems installing backdoors like Cobalt Strike and conducting lateral movement to other internal machines. The Cisco case underlined the importance of not only preventing MFA fatigue but also monitoring for new MFA device enrollments or other suspicious changes following an MFA approval.

LAPSUS$ Attacks: Microsoft's March 2022 report on LAPSUS$ (DEV-0537) lists spamming users with MFA prompts among the group's social engineering techniques. A message attributed to a LAPSUS$ member summarized the approach: Call the employee 100 times at 1AM while he is trying to sleep and he will more than likely accept it. In these cases, the attackers counted on odd timing and sheer persistence to induce a mistake. The lesson for defenders was that a simple push notification could be the weak link in an otherwise solid security chain.

These examples underscore that MFA fatigue attacks are not just theoretical, they are actively being used by adversaries to breach high value targets. Any environment where MFA relies on user approval especially via one tap pushes or phone callbacks is a potential victim. The success of such attacks on major companies was a wake up call to the industry that MFA alone isn’t a silver bullet if users can be tricked into defeating it.

Why MFA Fatigue Is Important

Security Implications: MFA fatigue attacks highlight a critical security lesson: even strong technical controls can be undermined by human factors. Multi factor authentication has been one of the most recommended measures to prevent account breaches and it is indeed very effective against automated attacks or credential theft alone. However, the rise of MFA fatigue techniques shows that attackers have found a way to work around MFA by targeting the user’s behavior rather than breaking the technology. This is important because it means organizations must evolve their defenses, they can’t rely on basic MFA prompts as a catch all. If users are conditioned to approve prompts without thinking, the MFA’s protection is nullified. The impact of a successful MFA fatigue attack is essentially the same as a compromised account without MFA: the attacker can potentially access sensitive data, systems, and services, leading to data breaches, fraud, and other damages. In short, it turns a protected account into a compromised one through social engineering.

Prevalence and Trends: This attack method is becoming increasingly common. Microsoft published dedicated guidance on defending users from MFA fatigue attacks in September 2022. The tactic has made headlines due to breaches as described above, which means attackers large and small are adopting it. It’s important for security teams to be aware of this trend, it's an emerging risk that accompanies the wider deployment of MFA. Many organizations have rolled out app based MFA for remote work and cloud apps, now they’re learning that those very systems can be abused. The importance for businesses is clear: you must treat MFA fatigue as a real threat in risk assessments and incident response plans, not just an edge case. For current numbers on how often attackers try this, including Microsoft's estimate of about 6,000 MFA fatigue attempts per day and how many accounts still lack MFA, see our MFA statistics.

Operational Impact: Defending against MFA fatigue requires changes in both technology and operations. On the technology side, Microsoft has enabled number matching for all Microsoft Authenticator push notifications since May 2023, with no user opt-out, and Duo and Okta offer similar verified-push or number-challenge options. On the operations side, security teams need to monitor authentication logs and user reports in new ways. Many SOCs historically focused on endpoint or network anomalies, now identity systems produce crucial signals that must be watched like a surge of failed MFA prompts for one account. This can be challenging due to the volume of authentication events in large organizations, but it’s become important to sift that data for patterns of misuse. The Uber and Cisco examples also showed the business risk at stake: a single fatigued user’s mistake can bypass costly security layers and lead to a major breach. Thus, MFA fatigue underscores the importance of a holistic security approach—one that combines robust technical controls with user awareness and adaptive monitoring. It’s a prime example of why security culture and user training are as important as technology in defending the enterprise.

Common Abuse or Misuse

MFA fatigue is fundamentally an abuse of a legitimate security process. Attackers take advantage of the fact that many MFA systems rely on simple user approval. There’s no malfunction in the MFA service, it dutifully asks the user to approve each login attempt. The misuse comes in the form of overwhelming the user and exploiting their trust or frustration:

• Exploiting User Trust and Habits: Many users have been trained that when an authenticator app pops up, they just need to tap Yes to log in. Over time, especially in busy workplaces, this can become almost reflexive. Attackers abuse this habit by presenting what looks like a normal request but at an unexpected time. If the user is only half paying attention or assumes IT is doing something in the background, they might approve without fully considering it. The attack relies on social engineering psychology, similar to phishing, where urgency or annoyance can cloud judgement.
• Alert Overload and Fatigue: By design, a single MFA prompt is a minor inconvenience to verify a login. But dozens of prompts in succession become a significant annoyance. This alert fatigue is exactly what attackers weaponize. In some documented cases, attackers intentionally time the bombardment during late night hours when the target is sleeping or at home relaxing. The user wakes up to a stream of notifications or gets repeatedly woken up, and in a groggy state they might accept one just to get peace. Even during work hours, constant pop ups can disrupt the user until they capitulate. The misuse here is leveraging a form of denial of service on the user’s attention turning a security prompt into an irritant that the user wants to eliminate.
• Leveraging Default MFA Configurations: Many organizations deploy MFA with default settings that do not limit the number of attempts or do not provide additional context. Attackers abuse these defaults. For example, if the system allows unlimited push notifications, an attacker can spam indefinitely without lockout. If the prompt doesn’t show contextual info like the origin of the request, the user has no easy way to tell if it’s malicious or just a weird glitch. Poor default policies e.g., not enabling features like number matching or not alerting on multiple denials mean the attack may go unchecked. Essentially, attackers find it easy because some MFA implementations weren’t tuned to consider this abuse case.
• Difficult Detection During the Attack: From the attacker’s perspective, one reason MFA fatigue is effective is that it’s hard for automated defenses to immediately distinguish from a legitimate user having trouble logging in. A series of failed MFA prompts followed by a success could just mean the user was fumbling with their phone and finally got it right. Without specific monitoring, it doesn’t scream attack in progress. Attackers know this, so they abuse the fact that each MFA prompt is a normal event. The volume is abnormal, but unless the system or defenders are looking for that pattern, the attacker can hide in the noise. Furthermore, once the user approves, the attacker is in and now any actions they take appear as the authenticated user, potentially blending in with normal activity.

In summary, attackers misuse the MFA process by turning user convenience against the user. It’s effective because it preys on human fallibility, something that isn’t patched by software updates. And it’s a misuse that flies under the radar compared to overt malware or exploit attacks. This is why security teams must treat MFA fatigue as a serious abuse case and not just user error.

Detection & Monitoring

Detecting MFA fatigue attacks requires visibility into authentication activity and the ability to spot unusual patterns. Unlike malware, there may not be signatures or binaries to catch instead, detection is about recognizing anomalous login behavior. Key indicators and monitoring practices include:

• Burst of MFA Requests: One of the clearest signs is a high number of MFA prompts for a single user in a short time window. Security teams should configure alerts if, say, an account triggers multiple MFA challenges within a few minutes or any pattern that looks like an MFA spam burst. For example, five or ten consecutive failed MFA approvals within 5-10 minutes should be extremely rare in normal use. Likewise, repeated MFA denials or cancellations by the user are a red flag they suggest the user keeps saying No to unexpected prompts.
• MFA Approvals After Failures: If an account shows a sequence of many failed or timed out MFA attempts followed by a successful MFA approval, this pattern can indicate the user eventually gave in. An analytic could detect MFA approved immediately following a burst of MFA failures. This sequence is characteristic of an MFA fatigue scenario and should prompt an investigation e.g., verify if the user actually initiated that login or not.
• Unusual Time or Location of Requests: Timing and geolocation are crucial contexts. Monitoring should flag MFA requests that occur at odd hours for the user or from anomalous locations, especially if combined with denial patterns. For instance, if an employee based in New York suddenly sees dozens of MFA push attempts at 3 AM from an IP address in another country, that’s very likely malicious. Many identity providers log the source IP and approximate location of each login attempt correlating that data is important. An impossible travel scenario user’s last login was in one country, now MFA requests from another far away combined with multiple prompts could indicate someone else is trying to authenticate as them.
• Identity Provider Logs & SIEM Analysis: To catch these signals, organizations need to aggregate identity logs. Sources include SSO or MFA provider logs (Okta System Log, Microsoft Entra ID (formerly Azure AD) sign-in logs, Duo authentication logs, etc.), which record each authentication attempt and its result. Feeding these into a SIEM or log analytics system allows detection rules to query for abnormal patterns across millions of events. For example, a SIEM rule might look for >X MFA challenges for the same user within Y minutes or multiple denied pushes followed by an accept from a new device or new location. MITRE’s guidance suggests monitoring for excessive or anomalous MFA push notifications especially from unusual source IPs or devices. In practice, defenders have created correlation rules: e.g., if a single account has MFA challenges from two continents in one hour, or a spike of failures, generate an alert.
• User Reports and Behavior Analytics: Users themselves can be sensors. Encourage users to report if they receive any unsolicited MFA prompts. A helpdesk call like "I keep getting MFA requests I didn't initiate" should immediately be treated as a potential incident; the security team can then lock the account and investigate credential compromise. A Red Team vs Blue Team exercise can confirm that these reports reach the security team instead of being closed as a glitch. Additionally, applying User Behavior Analytics (UBA) can help: this involves baselining normal login patterns and flagging deviations. For example, if a user who typically logs in once in the morning suddenly has 20 login attempts at random times, a UBA system would catch that anomaly. UBA can also detect things like an MFA approval from a new device or during off hours that’s out of character for that user.
• Watch for MFA Device Changes: After a successful compromise via MFA fatigue, attackers often register new MFA devices or change authentication factors on the account to secure their access. Monitoring for changes in MFA enrollment like a new phone or token added to an account can catch this post compromise activity. For example, if immediately after a suspicious login there’s an event of a new authenticator added for user X, that’s a big warning sign. Security teams should review such changes, especially if they happen right after a series of failed MFA prompts.

Common Blind Spots: Many organizations struggle with monitoring identity related events because logs can be very noisy. Every login for every user generates events, and large enterprises accumulate millions of auth log entries per day. If the organization hasn’t invested in centralizing these logs or if they use an MFA provider that doesn’t retain detailed logs at their subscription level, attacks can go unnoticed. Another blind spot is treating MFA alerts as a user only issue for instance, if IT support simply advises a user to change their password after reporting MFA spam, but doesn’t escalate to security, the broader attack pattern might be missed. It’s vital to break down silos between identity management and security monitoring.

In summary, detecting MFA fatigue attacks means looking at patterns of authentication events rather than any single event. By fine tuning alerts for rapid fire requests, unusual login contexts, and changes following an MFA approval, defenders can catch the attack in either the act or immediately after the fact. Quick detection is key if you see it early during the barrage, you can intervene before the user hits Approve. If you see it right after e.g., an unexplained successful login, you can contain the incident before the attacker does more damage.

Mitigation & Prevention

Preventing MFA fatigue attacks requires a combination of technology configurations and user focused measures. The goal is to harden the MFA process so that an attacker can’t easily spam prompts, and to ensure users are prepared to respond correctly if someone tries. Key mitigations include:

• Use Number Matching or MFA Prompt Codes: Implement number matching for push notifications whenever possible. Number matching means when a user gets a push prompt, they must enter a code shown on the login screen into their app, rather than just tapping Approve. This simple feature stops blind approval attacks cold: an attacker on the other side of the world won’t know the code on your screen. Microsoft, Okta, and other major MFA providers have rolled out number matching to counter push spam. With number matching enabled, even if an attacker floods you with prompts, they cannot succeed unless you provide the correct code, which you wouldn’t do if you didn’t initiate the login. Microsoft reported in September 2022 that, in its studies in live customer environments, number matching and additional context eliminated MFA fatigue attacks when enabled. In effect, it forces the user to prove they see the same login attempt as the system, something an attacker can’t fake remotely.
• Provide Additional Context in Prompts: Whenever the MFA system allows, turn on contextual information in notifications. This means the prompt will display details like the originating location, device, or application requesting login. For example, a Duo push or Microsoft Authenticator alert can show Attempting login from Sydney, Australia to Office 365. Such context makes it far easier for users to recognize unauthorized attempts if you’re not in Sydney and not logging into that app, you know it’s malicious. Context reduces the chance that a user assumes a prompt is benign or a glitch. It adds friction for the attacker, because users are less likely to approve something clearly suspicious. Many providers now include approximate geolocation and app name in the push to make sure this is enabled in your MFA policy.
• Rate Limit and Alert on MFA Prompts: Configure your MFA solution to limit the number of push attempts allowed within a given time frame. For instance, some organizations set a rule like no more than 3 MFA pushes in 5 minutes, after that, the account is temporarily locked or prompts are paused. This prevents unlimited spam. Even if it doesn’t stop the attack outright, it forces the attacker to be slower, giving security teams time to notice. Additionally, implement logic to block or suspend accounts that show a high number of consecutive MFA failures. Automated throttling can thwart an attacker by making the target account unusable to them after a few tries and it alerts the real user that something is wrong. Ensure these controls don’t lock out legitimate users permanently, they should trigger a security review or a cooldown period. The idea is to stop the continuous barrage. As Ping Identity notes, even trained users might eventually approve a prompt after 10+ notifications, so it’s wise to never let it get to that point.
• Implement Risk Based Authentication Policies: Embrace adaptive MFA or risk based authentication to make prompting smarter and less frequent under normal conditions. Risk based systems evaluate factors like the user’s device, network, location, and behavior. For example, if a login is coming from a known good device at an expected location, the system might not even require MFA no prompt to fatigue the user. But if a login is an unusual new device, new location, odd time, the system can step up the challenge or add extra verification. By reducing unnecessary MFA prompts in everyday use, you achieve two things: users stay vigilant because prompts aren’t so common that they ignore them, and any attacker generated prompts will stand out more. Conditional access rules such as geofencing blocking or extra challenging logins from high risk countries or device trust requirements fall under this category. These policies can outright block known bad scenarios e.g., an impossible travel attempt so that an attacker can’t even initiate MFA requests from certain conditions. Overall, risk based MFA makes the authentication process more context aware, mitigating fatigue both by reducing noise and by reacting to suspicious patterns in real time.
• Adopt Phishing Resistant MFA Methods: Wherever feasible, move toward phishing resistant MFA like FIDO2 security keys, smart cards, or other phishing resistant MFA methods. These methods don’t rely on push approvals at all for instance, a hardware security key e.g., YubiKey or a built in biometrics using WebAuthn requires the user to physically confirm presence or use a fingerprint, and it usually involves an encrypted challenge that an attacker can’t mimic remotely. Similarly, one time passcode TOTP apps or OTP tokens are not trivially fatigue-able because an attacker can’t make a prompt appear on your phone, they would need the actual code. The strongest options are passwordless flows using device bound credentials, which are inherently resistant to replay or fatigue attacks. Transitioning to these methods may be an investment, but it virtually immunizes users from push notification abuse. As one example, after the spate of MFA fatigue incidents, many companies accelerated plans to distribute hardware keys or enable phone as a token features, especially for privileged accounts. While not every account will use FIDO2 overnight, prioritizing it for high risk users and admins can remove the low hanging fruit that attackers target.
• User Education and Policy: Technology alone isn’t enough, user awareness is a critical layer of defense. Educate all users and continuously reinforce that they should never approve an MFA request they did not initiate. Make it clear: if you get a surprise prompt, it’s likely an attack. Users should know to deny unexpected prompts and immediately report them to the security team. Training should include examples of MFA fatigue scenarios so users recognize the tactic. If you keep getting bombarded with login approvals, that’s not normal; it's an attack. It’s also worth developing an easy reporting mechanism, like a single click in the MFA app to mark This wasn’t me, which some providers offer. Beyond training, consider your MFA UX policies: do users get prompted more often than necessary? For instance, if sessions time out very quickly or every single application requires a new MFA every time, users might develop prompt fatigue. Tuning session durations and SSO so that MFA prompts are at a reasonable frequency can prevent frustration. In essence, organizations should aim to minimize unnecessary MFA prompts in daily life and maximize user skepticism toward unexpected ones. Lastly, ensure users, especially those with access to sensitive data, know that attackers might contact them pretending to be IT to establish official channels so employees can verify such communications. A healthy dose of zero trust by users not trusting random IT calls will complement the zero trust principles in your infrastructure.

By implementing these mitigation steps, organizations can greatly reduce the likelihood of an MFA fatigue attack succeeding. It becomes much harder for an attacker to spam the user, and even if they try, the user and the system are far more likely to detect and block the attempt. The overarching strategy is: strengthen the authentication process through better MFA tech and policies and strengthen the user through awareness and good security culture. With both in place, MFA fatigue goes from an easy win for attackers to a far less effective trick.

Related Concepts

• Credential Theft & Phishing: MFA fatigue doesn’t work unless the attacker first has stolen credentials. It’s closely related to credential theft techniques like phishing emails or database leaks. In many cases, the threat actor phishes the password, then uses MFA fatigue as the next step to fully breach the account. It reinforces that strong passwords and anti phishing measures are foundational if you prevent the initial credential compromise, you prevent the MFA fatigue scenario entirely.
• Social Engineering Attacks: This technique is a form of social engineering, akin to phishing or pretexting. Instead of tricking a user to click a link or give up info, it tricks them into approving an auth request. Like other social engineering attacks, it exploits human psychology in this case, impatience and error rather than hacking code. The common thread is manipulating the user into performing an action that undermines security.
• Adversary in the Middle AiTM & MFA Bypass: Compare MFA fatigue to adversary in the middle attacks, where attackers use fake login pages or proxy tools to intercept MFA codes or tokens for example, man in the middle phishing kits that grab session cookies. Both are methods to bypass MFA, but via different means: one through user fatigue, the other through technical interception. Attackers might choose one method or the other depending on the situation. It’s worth understanding that MFA fatigue is not the only MFA bypass technique, others include SIM swapping to hijack phone based OTPs and reuse of session cookies to pass the cookie attacks. Each method targets a different weakness, MFA fatigue specifically targets the user’s interaction with MFA.
• Lateral Movement & Post Exploitation: Once an attacker uses MFA fatigue to get in, it becomes an initial access vector for a larger attack. From there, they will likely perform lateral movement methods within the network, escalate privileges, or exfiltrate data. In incident analysis, MFA fatigue often appears in the initial access or credential access phase, enabling everything that comes after. It’s part of the broader attack chain, which is why Zero Trust architectures and network segmentation are important. They assume that any single account, even one protected by MFA, could be compromised, and they limit the damage that can be done once an attacker is in.
• Phishing Resistant MFA Solutions: The security industry’s answer to attacks like MFA fatigue is to push towards phishing resistant MFA methods and improved authentication standards. Concepts like WebAuthn, FIDO2, and passkeys are designed so that approval or credential use cannot be tricked or duplicated by an attacker easily. Understanding MFA fatigue helps underline why there’s a big push for passwordless and phishing resistant tech. It removes the approve button from the equation or ties it to something the user can’t accidentally hand over like a biometric or physical key. In essence, MFA fatigue has accelerated the adoption of these stronger authentication methods in many organizations.

Each of these related concepts connects to MFA fatigue, either as a prerequisite, an analogous technique, or a defensive response. Together they form a bigger picture of identity security in which MFA fatigue is one piece. Recognizing those relationships helps defenders craft a multi-layered strategy to handle not just MFA fatigue, but the evolving tactics around account compromise and protection.

FAQs

• How does an MFA fatigue attack actually work?

In an MFA fatigue attack, the hacker needs your login credentials first username and password. They use those to repeatedly attempt logins, which triggers a flood of MFA prompts on your device. The attack works when the legitimate user gets so tired of or confused by the constant prompts that they accidentally or reluctantly approve one, thinking it’s a benign request or wanting to stop the notifications. Once that approval is given, the attacker is logged in as the user. It’s essentially tricking the user into authenticating the attacker’s session.

• Which types of MFA are most vulnerable to MFA fatigue?

Primarily push notification MFA and similar one tap approval methods are vulnerable. This includes mobile authenticator apps that say Approve/Deny and certain phone call or SMS verifications where a user can simply respond to authenticate. Methods that require the user to input a code like TOTP apps or SMS codes or use a physical token are much harder to abuse with fatigue, because the attacker can’t generate endless approval requests without the user actively providing a code. That’s why number matching push MFA or hardware security keys are recommended, an attacker can’t just spam those. In short, any MFA that allows low friction approval with just a tap is at risk, whereas high friction methods to enter a code, plug in a key are more resilient.

• How can I tell if I’m being targeted by an MFA fatigue attack?

The clearest sign is receiving multiple MFA prompts for no reason. If you get one unexpected prompt, it could be a stray error but if you keep getting notifications asking Is this you logging in? when you are not, that’s a red flag. Especially if they come in rapid succession or at odd times like in the middle of the night, assume it’s malicious. Also, if someone contacts you via phone, text, email claiming to be IT support and asks you to approve an MFA request, that’s a huge warning sign it’s likely part of the attack. In summary: more than one uninitiated MFA request is not normal. Do not approve, instead notify your IT/security team immediately.

• What should I do if I receive a flurry of MFA prompts out of the blue?

Do not approve any of them. Treat it as an attack in progress. Deny the requests and then change your password immediately since it likely means the attacker knows your password. Also, inform your organization’s security team or IT department right away they may need to investigate and possibly lock the account. If your account supports it, also check for any new devices registered to your MFA or any settings changes. Essentially, your response should be: deny, alert, and secure. Never assume it’s just a glitch, multiple prompts are almost never a random technical error. By reporting it, you not only protect yourself but also let the organization activate incident response to protect others if needed.

• Is MFA fatigue the same thing as MFA bombing or push bombing?

Yes, these terms are often used interchangeably. All refer to the tactic of overwhelming a user with authentication requests until they give in. Some people use MFA bombing to emphasize the idea of a bombardment of prompts. There’s a slight nuance where MFA bombing sometimes implies a more aggressive approach, possibly combined with the attacker actively contacting the user for example, bombarding and calling to pressure you. Meanwhile, MFA fatigue highlights the effect on the user getting tired or complacent. But practically speaking, if you hear any of those terms MFA fatigue, MFA bombing, MFA spamming, push harassment they are referring to the same overall technique.

• Can attackers launch an MFA fatigue attack without knowing a user’s password?

Generally, they need to have the correct credentials to trigger the MFA in the first place. The MFA system only sends a prompt after the right username/password or sometimes just username is entered. So attackers typically steal or guess the password first. There is a rare scenario mentioned in security research where if an organization has misconfigured something like self service password reset with automatic MFA enrollment, an attacker might abuse that to send a prompt. But in normal conditions, without the password, the attacker can’t make the MFA system do anything. This is why protecting passwords and detecting password compromise is so important: it’s the prerequisite for an MFA fatigue attack. In password-based MFA, keeping the password secret prevents the attack; passwordless push sign-in can be triggered with a username alone, so number matching and rate limits matter there.

• Will measures like number matching or physical security keys completely stop MFA fatigue attacks?

They drastically reduce the risk. Number matching makes it virtually impossible for an attacker to succeed by pure spamming, because you won’t approve a request unless you can enter the correct code which the attacker can’t see. An attacker could still try a social engineering angle for example, calling and asking you to read the code but that’s more work for them and much easier for users to realize as suspicious. Physical security keys FIDO2/WebAuthn are even stronger: the attacker cannot clone the key or trick it remotely, and there’s no Approve prompt to fool you with. With those, an MFA fatigue attack simply won’t work as intended. However, no security measure is 100% foolproof. A very determined attacker might switch to other tactics like phishing for your key’s PIN or using malware. But in practice, enabling features like number matching and using phishing resistant MFA effectively stops the classic MFA fatigue technique. These measures remove the low hanging fruit that attackers have been exploiting.

• Is MFA still worth using if attackers have found ways to bypass it?

Absolutely yes. MFA in general is still one of the most effective defenses against the vast majority of attacks. MFA fatigue is a specific technique that bad guys came up with because MFA was blocking them in so many other cases. Think of it this way: previously, if an attacker got your password, they were in but with MFA, they got stopped, so now they have to do this whole complicated fatigue ploy. Most attackers won’t even try this if easier routes are available. And the fact that MFA fatigue exists has led to improvements in MFA systems like number matching which make MFA stronger. So you shouldn’t abandon MFA instead, you adapt and improve it. When configured properly with the mitigations we discussed and combined with user awareness, MFA remains a critical security layer. The cat and mouse nature of security means we have to keep enhancing defenses, but MFA is still a cornerstone of account security. It’s much better to have MFA with enhancements than to go without and be vulnerable to every stolen password.

MFA fatigue attacks reveal that security is only as strong as its weakest link in this case, the human factor in authentication. By bombarding users with prompts, attackers found a clever way to sidestep a strong technical control. The key takeaway is that organizations must respond by fortifying both their technology through better MFA configurations and limitations and their people through education and vigilance. Multi factor authentication is still essential, but it must evolve with features like number matching and adaptive policies to stay effective against these tactics. In the end, MFA fatigue teaches us to never become complacent: even good security measures require continuous improvement and user understanding. By learning from these attacks, we can adjust our defenses to ensure that a moment of fatigue or annoyance does not open the door for adversaries.

About the Author

Mohammed Khalil is a Cybersecurity Architect at DeepStrike, specializing in advanced penetration testing and offensive security operations. With certifications including CISSP, OSCP, and OSWE, he has led numerous red team engagements, focusing on cloud security, application vulnerabilities, and adversary emulation. His work involves dissecting complex attack chains and developing resilient defense strategies for clients in the finance, healthcare, and technology sectors.