StealthTech
A contractor in our Boston client base once described the moment his help desk phone lit up at 11:40 p.m. on a Tuesday: an employee’s phone had buzzed with a login approval request every ninety seconds for twenty minutes straight. He hadn’t tried to log into anything. He assumed it was a glitch, tapped “approve” to make the notifications stop, and went back to sleep. By the time our team caught the anomaly the next morning, the attacker was already inside the environment. That single tap is the entire attack. No malware, no zero-day, no cracked password hash — just a tired employee and a push notification that wouldn’t quit.
This is MFA fatigue, sometimes called push-bombing or MFA bombing, and it has become one of the more reliable ways threat actors get past authentication controls that organizations spent real money implementing specifically to stop them. For a defense contractor handling Controlled Unclassified Information, understanding this attack pattern isn’t optional reading — it’s the difference between a documented, defensible security posture and a DFARS incident report you didn’t see coming.
What Makes MFA Fatigue Attacks Different From Credential Theft
Most authentication attacks start with the attacker not having something: a password, a token, a session cookie. MFA fatigue starts with the attacker already having something — usually a harvested password from a previous breach, a credential-stuffing hit, or a phishing kit that captured a login. What they don’t have is the second factor. Rather than trying to defeat that second factor cryptographically, they exploit the fact that a human has to respond to it.
Push-based MFA — the “approve this login” notification most people are familiar with from Microsoft Authenticator, Duo, or Okta Verify — was designed to be more convenient than typing a six-digit code. That convenience is exactly what gets weaponized. An attacker who already holds valid credentials simply attempts to log in repeatedly, triggering a wave of push notifications on the victim’s device. Eventually, out of confusion, irritation, or the simple desire to silence a buzzing phone, someone taps approve. The attacker is in, and from the identity provider’s perspective, nothing looks wrong — a valid credential paired with a valid MFA approval is, by definition, a successful authentication.
That’s the uncomfortable part for anyone building a security program around zero-trust identity and device protection: MFA fatigue doesn’t break the technology. It exploits the fact that the technology still requires a person to make a judgment call, and people get tired, distracted, and annoyed. A program built entirely around cybersecurity tooling without addressing that human decision point has a gap that no firewall closes.
Anatomy of a Push-Bombing Campaign
The mechanics are almost insultingly simple, which is part of why the technique has spread. A typical campaign follows a recognizable sequence:
- The attacker acquires valid credentials through a prior breach, a purchased credential dump, or a targeted phishing email that harvested a username and password without triggering MFA.
- They script or manually initiate repeated login attempts against the victim’s account, each one generating a fresh push notification, phone call, or SMS code request.
- The volume of prompts is timed to hit periods of low attention — late at night, during a shift change, or in the middle of a high-volume workday when an employee is fielding dozens of notifications already.
- In more targeted variants, the attacker follows up with a spoofed call or message posing as IT support, instructing the victim to “just approve the one that’s coming through” to stop the barrage — a hybrid of push-bombing and vishing that raises the success rate considerably.
- Once one approval lands, the attacker pivots immediately: registering a new MFA device, changing recovery information, or moving laterally before the legitimate user or the security team notices the account was ever touched.
That last step matters as much as the initial breach. Attackers who get through via fatigue almost always try to entrench themselves by adding a second authenticator app or phone number to the compromised account, which is often the first reliable signal a monitoring team gets — assuming someone is watching for it.
Why Defense Contractors Are Prime Targets
Push-bombing isn’t industry-specific in origin, but the defense industrial base has characteristics that make it an attractive target for the technique specifically. Contractors sit on Controlled Unclassified Information, program schedules, and technical data that have resale value to nation-state actors and criminal brokers alike. CISA’s ongoing analysis of nation-state cyber activity consistently flags credential-based intrusion as a preferred entry method precisely because it avoids the noisier signatures of exploit-based attacks.
Smaller and mid-sized contractors in the engineering and manufacturing space are particularly exposed. They often adopted MFA to satisfy a compliance checkbox rather than as part of a deliberate identity strategy, which means push notifications went out to whatever device was on hand, with no number matching, no phishing-resistant fallback, and no monitoring layer behind it. An assessor reviewing your System Security Plan will see “MFA implemented” and check the box. An attacker running a fatigue campaign sees the same environment as an open door with a a doorbell that eventually gets answered.
Program managers and engineers with elevated access to CAD files, bills of materials, or export-controlled technical data are especially attractive targets because a single successful push approval can hand over exactly the kind of information a prime contractor never wants to explain losing to a subcontractor’s help desk incident.
The Human Factor: Why Fatigue Works
Security awareness training tends to focus on phishing emails — spotting a suspicious link, hovering over a sender address, checking for spelling mistakes. Push-bombing sidesteps almost all of that training because there’s no email to inspect. There’s a notification on a phone the employee already trusts, from an app they already trust, asking a yes-or-no question they’ve answered correctly a thousand times before.
Cognitive fatigue is the actual vulnerability being exploited. An employee approving twenty legitimate logins a week develops a reflexive motion: notification appears, thumb taps approve, back to work. When that reflex meets a two a.m. barrage of ten prompts in a row, the instinct isn’t “this is an attack” — it’s “why won’t this stop.” Attackers count on that instinct being stronger than security training that was delivered once during onboarding and never reinforced.
This is also why organizations that treat MFA fatigue purely as a technology problem tend to under-invest in it. It’s tempting to assume that because MFA is “already deployed,” the control is complete. In reality, the deployment decisions made at rollout — push versus number matching, which devices are authorized, whether there’s a lockout after repeated failed attempts — determine whether the same MFA investment is resilient or fragile against this specific technique.
Real-World Incidents That Put MFA Fatigue on the Map
The technique moved from theoretical to headline news through several high-profile breaches where a single approved push notification led to significant compromise. Large technology and ride-share companies have both attributed major intrusions to attackers who simply overwhelmed an employee with authentication requests until one was accepted, in some cases combined with a follow-up message impersonating internal IT to close the deal.
What made those incidents instructive wasn’t the sophistication — there wasn’t any — it was how far the access spread afterward. In each case, a single approved login became a foothold for lateral movement into internal tools, source code repositories, or administrative panels, because the initial detection gap allowed the attacker time to operate before anyone noticed the account behaving abnormally. For a defense contractor, that lateral movement window is the part that turns an authentication nuisance into a reportable cyber incident under DFARS timelines.
Where CMMC and NIST 800-171 Address the Identification Gap
Neither the CMMC framework nor NIST Special Publication 800-171 names “MFA fatigue” as a discrete control family, but the practices that mitigate it are already embedded in the identification and authentication requirements contractors are expected to implement. The expectation isn’t simply that multi-factor authentication exists — it’s that authentication mechanisms are configured to resist compromise, which is a meaningfully higher bar than checking a box that says MFA is turned on.
This is where a lot of System Security Plans fall short during assessment prep. A contractor can accurately state that MFA is enforced for all privileged and remote access and still be sitting on a push-based configuration with no number matching, no rate limiting, and no logging of repeated failed approval attempts. An assessor working from NIST SP 800-171A’s assessment procedures is going to ask how that control is actually implemented and monitored, not just whether it’s switched on. Contractors preparing for certification through the compliance process need documentation that shows deliberate configuration choices, not default settings left as the vendor shipped them.
The reporting obligation compounds this. Under DFARS 252.204-7012’s safeguarding and cyber incident reporting requirements, a successful push-bombing compromise that results in unauthorized access to covered defense information triggers the same 72-hour reporting clock as any other incident. Contractors who haven’t built detection for this specific attack pattern often don’t realize they’ve had a reportable event until well outside that window, which creates its own compliance exposure separate from the original breach.
Technical Defenses That Actually Stop Push-Bombing
Not every MFA method is equally resistant to fatigue attacks, and the fix isn’t necessarily ripping out and replacing an entire identity stack. A few configuration and architecture changes make the biggest difference:
- Number matching requires the user to enter a code displayed on the login screen into the authenticator app, rather than tapping a single approve button. This eliminates the reflexive-tap failure mode entirely because a distracted employee can’t accidentally approve something they haven’t actively transcribed.
- Phishing-resistant authentication, particularly FIDO2 security keys or platform passkeys, removes the push notification from the equation altogether. There’s no prompt to fatigue someone with because the authentication ceremony requires physical possession of a hardware key or a registered device biometric.
- Rate limiting and account lockout after a defined number of failed or unanswered authentication attempts stops a campaign before it reaches the tenth or twentieth notification, cutting off the attacker’s window before fatigue sets in.
- Geographic and behavioral risk scoring flags login attempts from unfamiliar locations or impossible travel patterns, adding a layer that catches the anomaly even if a distracted employee approves the prompt.
- Contextual push details, showing the requesting application, device, and approximate location inside the notification itself, give an attentive employee more information to recognize something is wrong before tapping anything.
Organizations that have already been evaluating passkeys as a password replacement are ahead of the curve here, since phishing-resistant credentials solve the push-bombing problem as a side effect of solving password reuse. For contractors still running push-only MFA across a hybrid workforce, migrating toward number matching is a lower-lift interim step that can usually be enabled through existing identity provider settings rather than a full platform change.
Building a Detection and Response Plan for Push-Bombing
Prevention alone isn’t a complete strategy, because no configuration change removes the underlying human decision entirely. Detection has to assume that someone, eventually, will tap approve on something they shouldn’t. The organizations that recover cleanly from a fatigue-based compromise are the ones who catch the anomaly within minutes, not the ones who caught it because a suspicious login attempt happened to fail.
Effective monitoring looks for the pattern rather than the individual event: a burst of authentication requests against a single account in a short window, especially outside normal working hours, is a stronger signal than any one login attempt on its own. Security teams should also treat any new MFA device registration or authenticator re-enrollment as a high-priority alert requiring immediate verification with the account owner through a channel other than the compromised device. Layering this kind of monitoring on top of managed IT services means the alert gets triaged by someone awake and paying attention, rather than sitting in a log nobody reviews until the following Monday.
Employee reporting also has to be frictionless. If someone has to remember a ticketing portal URL and password to report “I got a weird notification,” most people won’t bother, especially at midnight. A single phone number or chat channel that reaches a live person, staffed around the clock, closes that gap. Contractors working with a co-managed model can route after-hours anomalies through co-managed IT support without needing a fully staffed internal SOC.
Vendor Access and Supply Chain Exposure
MFA fatigue campaigns rarely stop at the boundary of the company that was targeted. Once an attacker has a foothold inside a contractor’s environment, the next objective is usually whatever trusted connections that environment has outward — vendor portals, subcontractor VPN access, shared collaboration tools, or remote monitoring agents. CISA’s guidance on nation-state cyber actors repeatedly emphasizes that supply chain relationships are treated by sophisticated adversaries as an extension of the primary target’s attack surface, not a separate concern.
For contractors managing their own vendor risk, this means the MFA posture of every third party with system access matters as much as internal configuration. A subcontractor’s push-based MFA weakness becomes the prime contractor’s exposure the moment shared credentials or federated access are involved. This is one of the areas where a vCIO engagement pays for itself, translating a technical gap like push-bombing susceptibility into a vendor management conversation the business side of the house can actually act on, and where centralized oversight through cloud transformation planning can reduce the number of disparate identity systems an attacker could exploit in the first place.
Building Employee Awareness Without Relying on a Single Training Session
Awareness training that treats MFA fatigue as a one-time slide in an annual compliance module doesn’t hold up against a technique that specifically exploits fatigue and repetition. What works better is normalizing a simple rule that employees can apply without thinking hard about it: if you did not initiate the login attempt, you deny the request and report it, every single time, no exceptions for late nights or busy weeks. That rule needs to be reinforced the same way phishing simulations are reinforced — periodically, realistically, and without punitive framing that makes people afraid to report a mistake.
Contractors that have already built out AI-driven monitoring and integration into their security stack can extend that same automation to flag repeated push attempts and notify both the security team and the employee simultaneously, closing the loop faster than a human reviewing logs the next morning ever could. And for organizations weighing how much of this to build in-house versus hand off, understanding the trade-offs between co-managed and fully outsourced IT models is a useful starting point before committing to a monitoring architecture.
What This Looks Like for Contractors in Boston, Tampa, and Sarasota
The threat itself doesn’t change by geography, but the operational reality of implementing these defenses does. A contractor in Boston with a hybrid workforce split between an office and remote engineers has a different device-management challenge than a machine shop in Sarasota running mostly on-site terminals with a handful of remote administrative staff, or a Tampa firm managing both commercial and defense-related contracts under separate compliance obligations. Each of those environments needs its MFA configuration, monitoring, and employee reporting workflow tailored to how people actually work day to day, not a generic template applied uniformly across every office. If backup and recovery planning isn’t already accounted for as part of that broader resilience picture, pairing identity hardening with a solid backup and data recovery strategy closes the loop on what happens if a fatigue-based compromise does get through before detection catches it.
Conclusion
MFA fatigue attacks succeed not because multi-factor authentication is a weak control, but because the specific way it’s configured and monitored often leaves a human decision as the last line of defense — and humans get tired at eleven at night. Closing that gap takes number matching or phishing-resistant credentials at the technical layer, real-time detection tuned to catch bursts of authentication requests rather than individual failures, and an employee reporting culture that doesn’t punish someone for admitting they almost tapped the wrong button. None of that requires abandoning the MFA investment already made — it requires configuring it like the control actually matters, which is exactly the distinction a CMMC assessor is trained to look for.
If your organization is planning its CMMC compliance journey, contact Stealth Technology Group today at (617) 903-5559 or visit the website to learn how modern cybersecurity infrastructure can accelerate your path toward certification readiness.
