Threat Intel
MFA Fatigue: The Attack That Turns Your Security Into a Weapon
Attackers are flooding employees with push notifications until they tap Approve out of exhaustion. Here is what is happening and how to stop it.
By SecureBusinessHub Editorial, International cybersecurity desk — · 7 min read
Your staff have MFA switched on. You did the right thing. The problem is that attackers spent the last two years finding ways around it.
MFA fatigue, sometimes called push bombing, is about as low-tech as attacks get. The attacker already has a stolen username and password, bought cheaply from a breach forum or harvested by phishing. They feed it into the login screen, which triggers a push notification on the employee's phone. Then they do it again. And again. Twenty, thirty times. At 11pm after a long day, when your account manager just wants the buzzing to stop, they tap Approve. No malware. No zero-day. Just exhaustion.
Why SMBs are a specific target here
Large companies often run 24-hour security operations centres watching for unusual logins. You almost certainly don't. A credential bought for a few dollars on a breach forum can unlock your accounting software, your client files, your email, if the only thing standing between the attacker and your data is a tired employee at the end of the day.
Uber's 2022 breach started this way. An 18-year-old bought contractor credentials, bombed the target with push notifications, and when that stalled, sent a WhatsApp message pretending to be IT support. Accept the request to make it stop. The contractor did. Uber had a full security team and a nine-figure security budget. Microsoft now reports that push bombing comes bundled as a standard feature in commercial attacker toolkits, which means less skilled criminals can run it, not just state-sponsored groups.
If your business has any accounts that can move money, access client records, or reach supplier systems, you are a worthwhile target. The attacker doesn't need to know your name or industry in advance. They buy a list of credentials and start pushing.
What attackers are doing now
Push bombing is only half the picture. A parallel threat has grown alongside it: adversary-in-the-middle phishing kits.
Tools like Evilginx2 sit as a transparent proxy between your employee and the real Microsoft 365 or Google Workspace login page. The employee sees a pixel-perfect copy of the sign-in screen, enters their credentials and their six-digit code, and the kit captures both in real time before passing them through to the real service. The employee lands in their inbox as normal and has no idea anything happened. Standard TOTP codes, the six-digit kind from an authenticator app, are useless here because the attacker uses the code immediately. The session cookie is what they're really after, and once they have it, MFA is irrelevant for the rest of that login session.
Both attacks target the same weak point: MFA that depends on a person making the right call under pressure. The fix is to remove that dependency entirely.
Signs your staff may already be targeted
- Employees report push notifications they didn't trigger. This is the attack in progress. Train people to report it immediately and deny it, never to approve it just to make it stop.
- Your Microsoft 365 or Google Workspace admin audit logs show login attempts from unfamiliar countries or IP ranges. These logs are free to check and most businesses never look at them.
- A sudden spike in account lockouts, which can signal credential-stuffing attempts against your domain.
- Staff receive WhatsApp, Teams, or email messages from someone claiming to be IT support asking them to approve a notification. Legitimate IT teams don't work this way.
- Your company domain appears in breach databases. HaveIBeenPwned offers a free domain-level search that shows which staff email addresses are in known data dumps.
What to do this week
Only one category of MFA defeats both push bombing and adversary-in-the-middle attacks: phishing-resistant MFA. That means FIDO2 hardware keys such as YubiKey or Google Titan, or passkeys backed by device biometrics. Both use public-key cryptography tied to your exact domain. A fake login page gets a useless response, and there is nothing for the employee to tap in approval. The human is taken out of the equation.
A full rollout across your whole team takes time. Start where a breach does the most damage. Finance staff, anyone with admin access to your cloud systems, and anyone who can authorise wire transfers or change payment details should get hardware keys first. Budget around 40 to 60 pounds or dollars per key, two keys per person so there is a backup. That is a small bill compared to recovering from a business email compromise.
For everyone else right now, turn on number matching in your existing MFA app. Microsoft Authenticator and Google Authenticator both support it. Instead of a simple Approve button, the employee has to type a number shown on the login screen into their phone. It takes five minutes to enable in your admin settings and is meaningfully harder to push-bomb than a straight yes/no prompt.
- This week: enable number matching in Microsoft Entra ID or Google Workspace MFA settings for all users.
- This week: run a search on HaveIBeenPwned for your company domain and force password resets on any compromised accounts.
- Next 30 days: order FIDO2 hardware keys for finance, IT admin, and executive accounts. Set up the provisioning workflow before the keys arrive.
- Ongoing: add a standing agenda item in team meetings for 'report unexpected MFA prompts'. Normalise the conversation before an attack happens.
The real risk here is not a technical gap, it is a human one. Attackers have worked out that your security training is part of the problem: employees who approve the suspicious request are not careless, they are just human. Your job is to take that choice away from them where it matters most. Hardware keys do that. A one-tap Approve button does not.
An attacker who can't beat your MFA will just keep asking until someone lets them in.
NIS2 requirements: the second regime to know about
Data protection law is not the only European regime a business gets asked about. The NIS2 directive sets baseline cybersecurity and incident-reporting obligations for organisations in a defined list of sectors, and it is the source of most of the security questions that now arrive attached to contracts. The two regimes cover different ground: data protection law governs personal data and what people can ask you to do with it, while the NIS2 requirements govern the security and resilience of network and information systems, whether or not personal data is involved. A single incident can engage both, on separate clocks, to separate authorities.
The directive applies to organisations in its listed sectors that are at least medium-sized, meaning broadly fifty or more employees or turnover and balance sheet above ten million euros. That size rule puts most small businesses outside its direct scope, and the honest answer for a ten-person company is usually that the directive does not regulate it. What the size rule does not do is keep the requirements away, because one of them is supply chain security: organisations inside scope are expected to consider the security practices of their direct suppliers, and the way that expectation shows up in the world is as a questionnaire in your inbox.
The measures the directive names are a reasonable checklist for any business, which is why they are worth knowing even when they do not apply to you directly. They cover risk analysis and written security policies, incident handling, business continuity and backups, supply chain security, secure development and vulnerability handling, basic cyber hygiene and training including for management, encryption and access control policies, and multi-factor authentication. Reporting is staged and fast for the organisations it covers: an early warning within twenty-four hours of becoming aware of a significant incident, a fuller notification within seventy-two hours, and a final report within one month.
Because the directive is national law in each member state rather than a single rulebook, the details of scope, thresholds and reporting differ by country. For a fuller explanation of the instrument itself, see our guide to what the NIS2 directive is, and for the supplier side of the supply chain obligation, our walkthrough of vendor risk assessment. The reporting clocks that run alongside data protection deadlines are covered in data breach notification requirements.
Frequently asked questions
Does NIS2 apply to a small business?
NIS2 generally applies to organisations in its listed sectors that are at least medium-sized, meaning broadly fifty or more employees or turnover and balance sheet total above ten million euros. Most smaller businesses fall outside its direct scope, unless a member state has specifically designated them or they sit in one of the size-independent categories such as DNS service providers or trust service providers. Being outside scope does not stop the directive reaching you through customers who are inside it.
What is the difference between GDPR and NIS2?
GDPR governs personal data: what you may collect, why you may hold it, and what rights people have over it. NIS2 governs the security and resilience of network and information systems in specific sectors, whether or not personal data is involved. One incident can engage both regimes at once, on separate reporting clocks and to separate authorities.
How long do you have to report a data breach?
Under the European model, a personal data breach is reported to the supervisory authority without undue delay and, where feasible, within seventy-two hours of becoming aware of it, and affected individuals are told without undue delay where the risk to them is high. Organisations in scope of NIS2 carry a separate obligation: an early warning within twenty-four hours, a fuller notification within seventy-two hours, and a final report within one month.
Does a small business need a data protection officer?
Under GDPR a data protection officer is required where the organisation is a public authority, where its core activities involve regular and systematic monitoring of people on a large scale, or where its core activities involve large-scale processing of special category or criminal offence data. Most small businesses meet none of those tests and are not required to appoint one, though naming someone internally as the contact for privacy questions is worth doing regardless.
What should a small business do when a client's security questionnaire asks about NIS2?
Answer what you actually do rather than what you think the client wants to hear. The questions usually cover written security policies, incident handling and how fast you would notify them, multi-factor authentication, access control when staff join and leave, backup and recovery arrangements, and which of your own subprocessors touch their data. Gaps are common, and disclosing one with a date for closing it lands far better than an answer that does not survive the follow-up question.
Do these rules reach a business based outside the EU?
They can. GDPR reaches organisations outside the EU that offer goods or services to people in the EU or monitor their behaviour, and other regions have their own regimes with their own triggers. NIS2 obligations follow the sectors and the member states that transpose it, but its supply chain expectations travel through contracts, which is how they reach suppliers anywhere in the world.
Related reading
- What is the NIS2 directive? Scope, sectors and deadlines: the instrument itself, who it covers, and how it reaches businesses outside its scope.
- Vendor risk assessment: a practical walkthrough: which suppliers to assess, what to ask them, and how to score the answers.
- Data breach notification requirements: who to tell and when: the audiences, the clocks, and the decisions to make before an incident.
- Privacy policy template for small business: what to include: the sections a policy needs, and the ones a generated template always gets wrong.
- Editable policy template pack: ready-to-adapt versions of the vendor risk questionnaire, incident response playbook and policy documents referenced above.