Updated: 03 Apr 2026
It is 1 a.m. Your phone buzzes. A push notification from your authenticator app: Approve sign-in?
You dismiss it.
It buzzes again. Then again. Ten times. Twenty. Forty.
You have already had a long day. You assume it is a system glitch or some miscommunication in IT. You just want it to stop. So you tap Approve.
That single tap is all an attacker needed. And they have been counting on exactly that moment since the first notification hit your phone.
This is an MFA fatigue attack — one of the most reliably successful breach techniques targeting Indian enterprises today. It does not require sophisticated malware or a zero-day exploit. It requires patience, a stolen password, and the understanding that most people, given enough pressure, will eventually take the path of least resistance.
What is an MFA fatigue attack? An MFA fatigue attack, also known as push bombing or prompt bombing, is a social engineering technique in which an attacker who has already obtained a user's credentials repeatedly triggers MFA push notifications on that user's device, hoping the user will approve one out of frustration, confusion, or exhaustion. The attack does not defeat MFA technically. It defeats the human being on the other side of it.
An attacker with stolen credentials initiates repeated login attempts against a target account. Each attempt fails — because MFA blocks it — but each one fires a push notification to the user's registered device. The loop is automated; the attacker does not need to be present.
The attack ends when the user approves a prompt out of exhaustion, or when the attacker escalates to a phone call posing as IT support to explain the notifications and request an approval. From there, the authenticated session is theirs.
(Source: Verizon 2024 Data Breach Investigations Report)
To understand why this attack is so effective, it helps to understand what push-based MFA was designed to do, and what it was not.
When an organisation enables push-based MFA, the assumption is that a user receiving an authentication request will evaluate it: Did I just try to log in? If yes, approve. If not, deny. That binary judgement is the entire security mechanism. The technology works perfectly. The problem is the human interface.
Push notifications are designed for convenience. They are fast, low-friction, and built to be acted upon quickly. Every time your phone buzzes with a notification, your instinct is to resolve it. Attackers have taken that design assumption and weaponised it.
At ten notifications, most users dismiss them and report the issue. At thirty notifications across a single evening — some arriving during dinner, others at midnight — the mental calculus begins to shift. At fifty, the fatigue is real. The user no longer knows whether any particular prompt is legitimate. They are no longer evaluating. They are reacting. And at that point, an approval is not a security decision. It is a reflex.
LAPSUS$, one of the most destructive threat groups of the early 2020s, articulated this in intercepted Telegram messages with striking directness: "Call the employee 100 times at 1 am while he is trying to sleep, and he will more than likely accept it."
That is not a technical insight. It is a psychological one.
"MFA fatigue does not defeat your authentication system. It defeats the person behind it."
MFA fatigue is not an emerging threat. It is a proven, documented breach technique with a track record against some of the world's most security-conscious organisations.
An 18-year-old attacker, later affiliated with LAPSUS$, purchased the VPN credentials of an Uber contractor from a dark web marketplace. The contractor's account was protected by MFA, so the attacker bombarded the contractor with push notifications for over an hour.
When the contractor initially continued to deny them, the attacker changed approach: they contacted the contractor on WhatsApp, posing as Uber IT support, and told them the notifications would stop once they approved one.
Exhausted and believing they were speaking to a colleague, the contractor approved the request.
Within hours, the attacker had accessed Uber's internal Slack, G-Suite, OpenDNS configuration, and HackerOne vulnerability database. The entire Uber engineering team was locked out of their code repositories while the company investigated. The incident cost Uber millions in remediation and regulatory response — and it began with a single tap.
(Source: Dark Reading, September 2022)
In 2022 alone, LAPSUS$ used MFA fatigue as part of breach chains against Microsoft, Samsung, Cisco, Nvidia, Okta, and Uber. These are not soft targets with minimal security investment. They are organisations with dedicated security teams, mature incident response capabilities, and multi-layered defences. What they shared was push-based MFA with no throttling, no number matching, and no policy to detect abnormal authentication volumes.
That shared vulnerability was enough.
(Source: Microsoft Security Blog — LAPSUS$ threat actor profile)
There is a specific script worth knowing, because it is still in active use. When push bombing alone fails to produce an approval — when the target keeps denying — attackers shift to a second stage: they contact the user directly, by phone or messaging platform, posing as IT support.
The script runs something like this: "We are seeing some unusual activity on your account, and we have been sending verification requests to confirm it is you. Could you please approve the next one so we can resolve this?"
The attacker has now reframed the attack as the solution. The user, who genuinely is experiencing something unusual on their device, finds the explanation plausible. They approve.
Understanding this script matters because user training that says "never approve unexpected MFA prompts" is incomplete. The prompts, by the time the social engineering stage begins, no longer feel unexpected. They feel like part of a conversation with someone from IT. Training needs to specifically address that framing.
"Legitimate IT support will never ask an employee to approve an MFA request in order to resolve a security concern. That is not how any legitimate process works."
MFA fatigue attacks targeting Indian enterprises are not distributed evenly across industries. The operational conditions of India's three dominant enterprise sectors create specific push bombing windows — each with a different root cause and a different fix.
IT/ITeS and GCC environments — the volume problem. Large IT services organisations and Global Capability Centres process authentication events in the thousands per hour, around the clock, across time zones. That volume creates a detection problem that most security teams have not solved. Anomaly detection thresholds configured for a 200-person company — or imported from a vendor's default ruleset — generate so much noise in a 10,000-user GCC environment that genuine attack signals are buried in false positives. Security operations teams learn to discount the alerts. The attacker running a push bombing campaign against one account at 2 a.m. is, from the SIEM's perspective, invisible.
The specific gap: MFA event logs are being collected, but per-account authentication velocity is not being alerted on. An account that generates 40 failed MFA events in one hour should be an immediate priority investigation. In most GCC environments, it is a log entry.
Manufacturing — the contractor access problem. Most large Indian manufacturers have two distinct authentication environments: the corporate IT environment, which the CISO controls, and the vendor and contractor access portals, which were configured by system integrators during ERP or OT deployments and have not been reviewed since. These portals frequently run older authentication configurations — sometimes without MFA at all, sometimes with SMS OTPs, rarely with any throttling policy.
Attackers targeting a manufacturing organisation do not always go for the corporate VPN. They look for the Siemens portal, the SAP vendor access URL, and the remote monitoring login for the HVAC or power management system. These are the doors that were installed by a third party, handed over at project closure, and never added to the authentication governance programme. The plant CISO often does not know they exist.
BFSI — the help desk problem. India's financial sector has normalised high volumes of help desk interaction for employees — branch staff, relationship managers, and back-office teams across hundreds of locations regularly contact IT support for access issues. That cultural familiarity with help desk engagement is exactly what makes the social engineering phase of push bombing effective here.
When an attacker's push bombing campaign fails to produce an approval, the next move in BFSI is a call to the target employee, impersonating the internal IT help desk, with a specific and credible explanation for the notifications. The employee is not suspicious — they call IT support regularly. The attack pivots from a technical campaign to a conversation.
The compounding factor is that many BFSI organisations' help desk identity verification processes were designed to resolve access problems for legitimate users quickly — not to withstand an attacker who has already obtained the user's employee ID, name, and department from a LinkedIn profile. Weak identity proofing at the help desk is a bypass route for every other MFA control in the environment.
Here is the uncomfortable reality for most large Indian enterprises: your MFA deployment is probably protecting you from what it was configured to protect you from in 2021. The threat has moved. The configuration has not.
Between 2020 and 2022, most organisations deployed push-based MFA under significant time pressure — remote work mandates, rapid cloud migrations, compliance deadlines. Speed was the priority. Hardening was deferred. For many, it was never revisited.
These are the five configuration gaps that Proactive's security architects find most consistently when reviewing enterprise MFA fatigue attack exposure across Indian enterprises — regardless of whether MFA is technically enabled.
The most dangerous characteristic of MFA fatigue is that it is rarely identified as an attack while it is happening. Users who receive repeated push notifications typically either dismiss them and say nothing, or report to IT that their phone is "acting strangely." Neither response triggers the investigation it should — because neither the user nor the IT team has a shared mental model of what an attack in this form looks like.
Four signals should be treated as indicators of an active push bombing campaign, not routine log noise:
Authentication velocity against a single account. Multiple failed MFA events on one account within a short window — even if each was denied — is an attack signal, not a technical glitch. This should trigger an alert and a temporary account lock pending investigation.
Out-of-hours attempts against accounts with no history of such access. An account that has never generated a login attempt after midnight doing so thirty times in one hour is not a synchronisation issue.
A user calling to report unexpected notifications. This is an employee telling you an attack is in progress. It should be routed to the security team immediately, not closed as a helpdesk ticket.
A user reporting a call from "IT support" asking them to approve a prompt. This is the social engineering phase of an active campaign. The account should be locked and investigated before anything else happens.
The fix for MFA fatigue does not require replacing your MFA platform or rolling out hardware security keys across your entire organisation. Cisco Duo's Verified Push feature addresses push bombing directly, and it can be enabled for existing Duo deployments immediately.
Verified Duo Push changes the authentication interaction from a passive approve/deny notification to an active verification step. When a user receives an authentication request, they are required to enter a short numeric code displayed on the login screen into the Duo Mobile app. The code changes with each request and is not visible to anyone who does not have access to that specific login page at that specific moment.
The consequence for push bombing is immediate and complete. An attacker running a remote bombing campaign cannot enter a code they cannot see. Even if they have the user's credentials, even if they can generate unlimited push requests, they cannot satisfy the Verified Push step. The attack collapses at that point.
This is not a marginal improvement. It eliminates the specific vulnerability that allowed the Uber breach and every Lapsus$ attack that relied on push bombing.
Adaptive Authentication provides a further layer. When Duo detects anomalous signals — an unfamiliar device, an unusual access location, an authentication volume that deviates from a user's baseline behaviour — it can automatically step up the authentication requirement or block the attempt entirely. Attacks that mimic legitimate access patterns are harder to catch with static policies; adaptive controls catch what static policies miss.
Push notification throttling and lockout policies allow administrators to define the maximum number of MFA requests a user can receive within a defined time window. A user who has received ten push notifications in five minutes can be automatically locked out of further authentication attempts and flagged for investigation — regardless of whether they approved any of them.
Number matching — where enabled as a baseline rather than Verified Push — provides a meaningful intermediate step for organisations that are not yet on Verified Push. It is not equivalent protection, but it transforms the approval from a reflexive tap into a conscious, manual action.
The False Confidence Audit above identifies where the gaps typically are. These are the six actions to close them.
Push bombing is not a clever attack. It does not require skill or much planning. The tooling is automated. The credentials are purchasable. The psychological vulnerability is universal.
What makes MFA fatigue attacks dangerous in India — and globally — is the gap between how organisations think about MFA and what it actually is: a human-assisted control that relies on users making correct decisions under pressure, at all hours, without training that specifically addresses this attack class.
Uber had MFA. The Lapsus$ attacks did not break it. They went around the people behind it.
The controls exist to close that gap. Verified Push is available today. Adaptive policies are configurable today. User training takes an afternoon. The question is not whether your organisation is on the list of push bombing targets — at scale, most credentials eventually surface somewhere. The question is whether your controls require the attacker to defeat technology, or merely to outlast a tired employee.
Proactive Data Systems is a Cisco Preferred Security Partner in India, operating across Delhi NCR, Mumbai, Bangalore, Pune, and Hyderabad. Our security architects help enterprises across Manufacturing, BFSI, and IT/ITeS close authentication gaps — including MFA fatigue vulnerabilities — with Cisco Duo deployments tailored to your environment and your compliance requirements.
If you would like a review of your current MFA configuration and push bombing exposure, speak with our team. Write to us at [email protected]
We'll get back to you shortly.
