MFA Fatigue Attacks: Why Multi-Factor Authentication Alone Won’t Save Your Enterprise

  • Home
  • MFA Fatigue Attacks: Why Multi-Factor Authentication Alone Won’t Save Your Enterprise
MFA Fatigue Attacks: Why Multi-Factor Authentication Alone Won’t Save Your Enterprise
MFA Fatigue Attacks: Why Multi-Factor Authentication Alone Won’t Save Your Enterprise
MFA Fatigue Attacks: Why Multi-Factor Authentication Alone Won’t Save Your Enterprise
MFA Fatigue Attacks: Why Multi-Factor Authentication Alone Won’t Save Your Enterprise
MFA Fatigue Attacks: Why Multi-Factor Authentication Alone Won’t Save Your Enterprise

Multi-factor authentication (MFA) was supposed to be the silver bullet. Enforce it across your organisation, the consultants said, and you eliminate 99% of credential-based breaches. That advice was sound — until attackers adapted. In 2026, MFA fatigue and push-bombing attacks have turned your own security controls into an entry point. Indian enterprises running legacy MFA deployments — particularly push-notification-based ones — are sitting on a vulnerability that threat actors are actively exploiting right now.

This post explains exactly how MFA fatigue works, why it succeeds even against security-aware users, and what your organisation must do immediately to close the gap.

What Is an MFA Fatigue Attack?

An MFA fatigue attack (also called push-bombing or MFA bombing) follows a deceptively simple kill chain:

  1. The attacker obtains valid credentials — through phishing, credential-stuffing from leaked databases, or purchasing them on dark-web forums (where Indian enterprise credentials routinely appear).
  2. They log into the target portal repeatedly, triggering a flood of MFA push notifications to the victim’s phone.
  3. After receiving dozens of “Approve sign-in?” prompts — often at 2 a.m. or during a busy workday — the victim taps Approve simply to make the notifications stop.
  4. The attacker now has authenticated access with a legitimate session token, bypassing every perimeter control downstream.

In some variants, the attacker calls the victim pretending to be IT support, instructs them to approve the “test” request, and combines social engineering with technical persistence. The 2022 Uber breach — one of the most-cited examples of this technique globally — followed exactly this pattern. A contractor’s credentials were obtained, the attacker push-bombed them for over an hour, then called posing as Uber IT. One approval was all it took.

Why Indian Enterprises Are Particularly Exposed

India’s enterprise IT landscape has several compounding factors that raise the risk profile:

1. Rapid MFA Roll-Outs Without Architecture Review

Post-COVID remote work forced organisations to deploy MFA quickly — often selecting whatever was fastest to roll out rather than most secure. Push notifications (Microsoft Authenticator, Duo, Google Prompt) are extremely easy to deploy but are the weakest link. Organisations that should have moved to phishing-resistant MFA never did, because “we already have MFA” became the answer to every audit question.

2. Overloaded Helpdesk and IT Teams

India’s mid-market enterprises frequently run lean IT teams. When users receive unexpected MFA prompts, the path of least resistance is to approve and escalate later — or simply approve because they assume it was a glitch. Security training exists on paper but is rarely contextual or role-specific.

3. Credential Exposure from Third-Party Breaches

India consistently ranks among the top countries in credential exposure from global data breaches. Attackers routinely purchase leaked credential sets, test them against corporate VPN portals and Microsoft 365 tenants, and immediately initiate MFA fatigue campaigns against valid accounts.

4. Weak Session Management

Many organisations issue long-lived session tokens after MFA approval — sometimes 30 to 90 days. A single successful approval gives attackers persistent access long after the initial compromise is forgotten.

The Taxonomy of Modern MFA Bypass Techniques

MFA fatigue is the most visible but not the only technique. Your security team should be aware of the full spectrum:

Push-Bombing (Fatigue)

Repeated push notifications until the user approves. Low skill required; high success rate against push-based MFA. Works 24/7 against sleeping or distracted users.

Real-Time Phishing with MFA Relay

Adversary-in-the-Middle (AiTM) phishing proxies — like Evilginx, Modlishka, and Muraena — sit between the user and the legitimate login portal. The user enters credentials and approves their MFA prompt against the real IdP; the proxy captures the resulting session cookie. The attacker uses that cookie directly, completely bypassing MFA for subsequent access.

SIM Swapping Targeting SMS-Based MFA

Organisations still using SMS one-time passwords (OTPs) face SIM-swap fraud, where attackers socially engineer telecom operators to port a victim’s number to an attacker-controlled SIM. This is particularly relevant in India given documented cases at major telecom providers. SMS OTP must be considered deprecated for high-value accounts.

Notification Number Matching Bypass

Some MFA systems now show a two-digit number match to prevent blind approvals — but attackers have begun using social engineering to instruct victims to approve the “correct” number they see on their screen, which the attacker also sees in real time.

What Phishing-Resistant MFA Actually Means

Not all MFA is created equal. The FIDO2/WebAuthn standard — implemented via hardware security keys (YubiKey, Feitian) or passkeys bound to the device — is categorically different from push notifications:

  • Origin binding: The cryptographic challenge is bound to the exact domain of the legitimate site. An AiTM proxy on a lookalike domain cannot intercept it — the authentication simply fails.
  • No shared secret: There is no OTP, push code, or SMS to intercept. The private key never leaves the device.
  • User presence + intent: The user must physically interact with the hardware key or biometric, making remote push-bombing impossible.

Microsoft has classified FIDO2/hardware keys and Certificate-Based Authentication (CBA) as the only truly phishing-resistant MFA methods in its Conditional Access framework. If your organisation is not on this path for privileged accounts and remote access, it is not fully protected.

A Practical Hardening Checklist for Indian Enterprises

Immediate actions your IT and security team should take this quarter:

Authentication Architecture

  • Audit all MFA methods in use: Identify every system still using SMS OTP or simple push. Prioritise for replacement.
  • Enable number matching and additional context: For Microsoft Authenticator, enforce number matching and location/app context display. This alone significantly reduces blind approvals.
  • Deploy FIDO2 / passkeys for privileged accounts: Domain admins, Azure/AWS/GCP admins, and C-suite accounts should be migrated to phishing-resistant MFA immediately.
  • Enforce MFA registration policy: Prevent users from self-registering new MFA methods without IT approval — attackers who compromise an account often immediately register their own authenticator.

Conditional Access and Session Controls

  • Restrict legacy authentication protocols: Block Basic Auth, NTLM, and older SMTP/POP/IMAP — these bypass MFA entirely. Microsoft reports that over 99% of password-spray attacks use legacy protocols.
  • Enforce device compliance: Require that devices meet compliance policies (managed, patched, encrypted) before granting access — unmanaged devices should not get full access even with valid MFA.
  • Reduce session token lifetimes: Cap session validity at 8–12 hours for sensitive applications. Force re-authentication for high-privilege operations.
  • Geo-restrict logins: Flag or block authentication from countries where your organisation has no employees or business operations.

Detection and SOC Visibility

  • Alert on MFA push floods: Set thresholds — more than 5 failed MFA prompts in 10 minutes from the same account should trigger an immediate investigation ticket.
  • Monitor for impossible travel: A login from Mumbai followed by one from Eastern Europe 20 minutes later is a confirmed credential compromise. This should be an automated block, not just an alert.
  • Correlate credential-stuffing attempts: High-volume failed login attempts against your VPN or M365 portal often precede a successful MFA fatigue attack. Your SIEM should surface this pattern.
  • Watch for MFA method changes: Any addition of a new authenticator app or phone number to an account should generate an alert, especially outside business hours.

User Awareness (Beyond the Annual Training)

  • Contextual just-in-time alerts: When users receive unexpected MFA prompts, they should know to immediately report to the helpdesk — not approve. Build this into your phishing simulation campaigns.
  • Executive and finance team briefings: These are the highest-value targets. They deserve personalised walkthroughs, not generic e-learning modules.
  • Clear escalation path: “If you get an MFA push you didn’t expect, call this number” should be on a card in every employee’s wallet.

How ZTNA Reduces the Blast Radius of an MFA Compromise

Even the best MFA can be defeated — defence in depth is the only reliable posture. Zero Trust Network Access (ZTNA) fundamentally limits what an attacker can do after they have compromised credentials and MFA:

  • Application-level access control: With ZTNA, a compromised account only reaches the specific applications it is explicitly authorised for — not the entire network. Lateral movement is structurally blocked.
  • Continuous trust verification: Unlike a VPN that grants access once and forgets, ZTNA continuously re-evaluates device health, location, and behaviour on every request. An anomalous session is terminated, not tolerated.
  • No network exposure: Internal applications are not exposed to the internet at all. An attacker with valid credentials cannot even reach the login page of systems they are not authorised to use.
  • Full session logging: Every access event — what application, from where, at what time, with what device — is logged and available for your SOC to analyse.

FortiGate’s ZTNA implementation integrates natively with FortiClient and FortiAuthenticator, giving PJ Networks’ managed customers continuous posture assessment without requiring a separate overlay architecture.

The Role of 24/7 SOC Monitoring in MFA Attack Detection

Detection speed is everything. The average dwell time for an attacker who has successfully bypassed MFA is measured in hours to days — during which they establish persistence, exfiltrate data, or move laterally to backup and financial systems. A 24/7 SOC with tuned detection rules can compress that window dramatically.

Effective SOC coverage for MFA-related threats includes:

  • Real-time alerting on MFA fatigue indicators (push flood + eventual approval)
  • Correlation of successful logins with prior failed MFA attempts on the same account
  • Behavioural baselining to detect abnormal access patterns post-authentication
  • Automated account lockdown playbooks triggered when indicators of compromise are confirmed
  • Direct notification to the customer’s security lead within defined SLA windows

Without 24/7 coverage, a weekend MFA fatigue attack — which attackers deliberately time for low-staffing periods — is often not discovered until Monday morning, when the damage is already done.

CERT-In and DPDP Reporting Obligations

Under India’s CERT-In directions (effective 2022), any incident involving unauthorised access to systems or data must be reported within 6 hours of detection. An MFA bypass leading to access of employee or customer data — even without confirmed exfiltration — likely triggers this obligation. Under the DPDP Act 2023, a personal data breach must be reported to the Data Protection Board within a prescribed timeline.

Organisations that lack 24/7 monitoring frequently discover MFA compromises days after the fact — making timely regulatory reporting impossible and creating significant compliance exposure. This is not a theoretical risk: CERT-In has made clear that under-reporting will attract penalties.

Key point: The 6-hour CERT-In clock starts from the moment of detection, not the moment of breach. Faster detection — enabled by a 24/7 SOC — directly reduces your compliance risk by giving you more time to investigate before the reporting window closes.

Immediate Next Steps for Your Organisation

If you take nothing else from this article, act on these three things this week:

  1. Enable number matching on all push-based MFA today. It costs nothing and immediately raises the bar for push-bombing attacks. In Microsoft Authenticator, this is a single policy toggle in Entra ID.
  2. Pull a report of all accounts with SMS OTP enabled. Begin migrating them to authenticator apps or FIDO2 keys, starting with privileged and finance accounts.
  3. Verify your SOC has a detection rule for MFA push floods. If you don’t have a SOC, or your current provider cannot confirm this coverage exists, that is a gap that needs to close before the next incident, not after.

How PJ Networks Can Help

PJ Networks provides Indian enterprises with an end-to-end managed security capability purpose-built for today’s identity-based attack landscape:

  • Managed ZTNA deployment using FortiGate and FortiClient, reducing lateral movement risk even when credentials are compromised.
  • 24/7 NOC/SOC services with tuned detection for MFA fatigue, AiTM phishing, and impossible-travel anomalies — with documented SLA-backed response times.
  • FortiAuthenticator integration for organisations looking to centralise and harden their MFA infrastructure across on-premise and cloud workloads.
  • CERT-In incident response support, including documentation and reporting assistance within the mandatory 6-hour window.
  • Security awareness programmes with simulated MFA fatigue campaigns to validate user resilience before attackers do.

MFA is not optional — but it is also not sufficient on its own in 2026. The organisations that stay ahead of the attacker curve are those that treat identity security as a continuous programme, not a checkbox. If you would like to assess your current MFA architecture or explore managed ZTNA options, speak with a PJ Networks security specialist for a no-obligation consultation.

Leave a Reply

Your email address will not be published. Required fields are marked *