The MFA fatigue attack we worked last quarter succeeded in eleven minutes. The attacker had a valid username and password — purchased on a credential market for $14 — and used a script to send an authentication push notification to the user’s phone every twenty seconds. At 11:47 PM, the user accepted one of the prompts. The attacker had a session token. By morning, the attacker had moved laterally, established persistence, and exfiltrated 18 GB of customer data. The user, when interviewed, said the same thing every fatigue victim says: “I just wanted them to stop.”
MFA fatigue — also known as MFA bombing or push-bombing — has become one of the most reliable initial-access techniques of 2026. The Microsoft Digital Defense Report tracks it as a leading vector for identity-based intrusions. CISA has issued repeated advisories warning that simple push-based MFA is no longer adequate for high-value accounts. The Verizon DBIR continues to flag stolen credentials as the dominant cause of breaches, and credential theft plus push-bombing is now the cheapest path from a $14 password to domain admin. Most organizations still rely on the exact form of MFA the attackers have learned to defeat.
This brief is written for security leaders, identity architects, and executives who deployed push-based MFA five years ago and have not revisited the architecture since. We will walk through three engagements, the patterns that connect them, and the identity-architecture changes that actually defeat MFA fatigue.
Why MFA Fatigue Works So Reliably in 2026
The mechanics are uncomfortable to read. Push-based MFA was designed in an era when the second factor’s job was to confirm a user’s intent. The user receives a prompt, recognizes the login attempt as their own, and approves it. The system worked because the prompt was rare. In 2026, attackers can generate prompts on demand. A user who receives forty notifications in twenty minutes — in the middle of the night, while trying to sleep — will eventually approve one. The attacker does not need to defeat the cryptography of MFA. They only need to defeat the user’s patience. Mandiant’s M-Trends has documented this pattern across nation-state and criminal actors alike.
“Push-based MFA assumed the prompt was a confirmation of intent. In 2026 it is a confirmation of exhaustion. The architecture has not caught up to the threat model.”
Senior identity architect, iSECTECH engagement notes
Three Engagements That Defined Our MFA Fatigue Response Playbook
Engagement One: The 11-Minute Compromise That Cost 18 GB of Data
The anchor engagement involved a SaaS company whose customer-success engineer accepted a push prompt at 11:47 PM. The attacker had purchased the credential the same week. The push-bombing took eleven minutes. The session token was valid for eight hours. By 12:30 AM, the attacker had used Graph API calls to enumerate mailboxes, identified a finance executive, and begun staging exfiltration. The MFA log showed twenty-three rejected prompts followed by one accepted prompt. No alert had fired. The system treated the accepted prompt as legitimate. The remediation arc included a complete identity-architecture redesign and a tabletop exercise we still cite in training.
Engagement Two: The CFO Who Approved a Prompt During a Board Dinner
The second engagement involved a public-company CFO whose phone vibrated repeatedly during a board dinner. He silenced his phone after the first ten prompts. At a break in the dinner, he checked his phone, saw an outstanding prompt that looked legitimate, and approved it to clear the queue. The attacker had access for ninety minutes before SOC alerts surfaced anomalous Graph API enumeration. The CFO is technical, sophisticated, and cybersecurity-literate. He fell to the attack because the design of the human interface gave him no good way to refuse without losing access to his email for the rest of the evening.
Engagement Three: The Helpdesk That Reset MFA Without a Verification Step
The third engagement is the one that taught us how the human side of MFA can also be defeated. The attacker, having compromised a credential and failed to push-bomb the account successfully, called the company’s helpdesk and claimed to have lost their phone. The helpdesk reset the MFA enrollment based on a knowledge-based answer the attacker had collected from public records. The attacker enrolled their own device. The verification protocol the helpdesk used was — in retrospect — indistinguishable from the public information any attacker could collect. We helped redesign the helpdesk’s identity-verification protocol, including a callback to a number on file and a manager-approval step for any MFA reset on a privileged account.
The Five Architecture Choices That Defeat MFA Fatigue
The organizations that have closed this gap share five choices. The first is phishing-resistant MFA — FIDO2 hardware keys or platform passkeys, which cannot be bombed because there is no asynchronous prompt to approve. The second is number matching: when push prompts are unavoidable, the user must enter a number displayed on the login screen, which an attacker cannot generate. The third is rate limiting and prompt suppression: more than three prompts within five minutes triggers an automatic account lock and analyst review. The fourth is conditional access policies that block authentication from anomalous geography, IP reputation, or device posture before a prompt is ever sent. The fifth is helpdesk verification discipline: any MFA reset on a privileged account requires a callback to a known number and manager approval. NIST’s identity guidance and CISA’s authentication advisories both reinforce these patterns.
“If you are still relying on simple push-based MFA for executive accounts, you are running 2018 controls against a 2026 threat. The attackers know it. The defenders need to know it too.”
iSECTECH identity security review summary
What Boards and Executives Should Demand This Quarter
The most useful question a board can ask the CISO this quarter: “Which of our privileged accounts are still relying on push-based MFA, and what is our timeline to migrate them to phishing-resistant authentication?” If the answer is uncomfortable, the timeline conversation should start the same week. A second high-leverage question: “What is our helpdesk’s verification protocol for an MFA reset, and would it survive a sophisticated social engineering attempt?” The boards we admire ask both questions every quarter and refuse to accept aspirational timelines as substitutes for executed migrations.
“The companies that have not migrated executive accounts to FIDO2 by the end of 2026 are running an unforced error in their threat model.”
Jen Easterly, former CISA Director, public commentary on identity security
How This Connects to the Rest of Your Security Program
MFA fatigue interacts with every other identity discipline. The Kerberoasting findings we documented in our Kerberoasting field notes often follow the same initial-access path. The executive impersonation patterns we covered in our CEO deepfake fraud playbook frequently begin with a compromised executive account. And the dark-web reconnaissance we wrote about in our piece on the first 24 hours of an executive dark-web audit is often the source of the credentials that fuel the push-bombing campaign in the first place.
What to Do This Week
Three actions before Friday. First, inventory which privileged accounts still use simple push-based MFA and assign a migration owner. Second, enable number matching on every Microsoft Authenticator deployment that has not yet been moved to phishing-resistant MFA. Third, run a five-minute table-talk with your helpdesk lead on the verification protocol for MFA resets and identify any step a sophisticated attacker could fake. Authoritative external references include CISA authentication advisories, the Microsoft Digital Defense Report, and NIST identity guidance.
Talk to a Senior Identity Security Practitioner
If your environment has not migrated privileged accounts to phishing-resistant MFA, that gap is worth closing this quarter. iSECTECH’s senior practitioners run identity-architecture audits that quantify your exposure and design the migration sequence that closes it. Book a confidential identity security review with our senior team.
The Cost of Migrating Off Push-Based MFA Is Lower Than Most Executives Assume
The single most common reason organizations have not migrated to phishing-resistant MFA is a perception that the cost is prohibitive. The math, in our experience, does not support that intuition. The hardware cost of a FIDO2 key for every privileged account in a typical mid-market organization is rarely above $5,000 in total. The integration work — enabling FIDO2 in the identity provider, distributing the keys, training the users — typically completes in two to three weeks. The cost of a single MFA-fatigue compromise, by contrast, runs into seven figures when remediation, regulatory disclosure, customer notification, and reputational impact are accounted for. The IBM Cost of a Data Breach Report has consistently placed identity-based intrusions among the most expensive incident classes. The economics favor migration. The barrier is rarely budget; it is decision velocity.
Why Conditional Access Belongs in the Same Conversation as MFA
Phishing-resistant MFA closes the prompt-acceptance gap, but it is not a complete answer to identity-based attacks. Conditional access policies — enforcing additional checks based on geography, device posture, network reputation, and behavioral signals — reduce the attack surface before authentication is even attempted. A login attempt from an anonymizing proxy network on a device that has never been registered to the user should not produce any prompt at all; it should produce a block. The identity programs we admire treat conditional access and MFA as a single discipline rather than two adjacent ones. Forrester research on identity maturity reinforces this pattern: the organizations with the lowest identity-incident rates are the ones whose conditional access policies do most of the work, with MFA acting as the final safety net rather than the primary control.
Continue Reading: Week 4 Field Notes
MFA fatigue interacts with the architectural disciplines we cover in Week 4: why most zero trust implementations quietly stall, why the most damaging insider cases are rarely malicious, and why most AI security findings are mundane access-control failures.