Hardening Identity Providers (IdPs) Against MFA Fatigue And Push Harassment

📅 October 28, 2026  |  🏷 Cyber Security  |  Cyber Security, Information Security, Threat Management

At 2:47 AM, a senior engineer at a multinational logistics firm received his forty-third authentication push notification that night. He approved it — not because he intended to grant access, but because exhaustion had eroded his judgment. Within minutes, attackers using stolen credentials had pivoted laterally through the company’s identity provider, accessed Azure AD, and exfiltrated configuration data for 11 production environments. The breach cost $4.2 million in remediation. The root cause wasn’t a zero-day exploit. It was a design flaw in how the organization had deployed multi-factor authentication.

MFA fatigue — also called push harassment or push bombing — has become one of the most reliably effective social engineering vectors in enterprise environments. According to the 2026 Verizon Data Breach Investigations Report, credential-based attacks now account for 61% of all confirmed breaches, and a growing subset of those attacks exploit MFA push mechanisms specifically. Security teams that once considered MFA a definitive control are now discovering that poorly configured identity providers can transform a security layer into an attack surface.

This post examines how adversaries weaponize push notification fatigue, what architectural weaknesses in Identity Providers (IdPs) enable these attacks, and — critically — what hardening strategies actually stop them at the infrastructure level.

Understanding the MFA Fatigue Attack Chain

Push bombing isn’t sophisticated in the traditional sense. It doesn’t require exploit code or CVE weaponization. What it requires is a valid username/password pair (easily purchased from credential marketplaces for as little as $8 per account) and a willingness to flood a victim’s authenticator app with approval requests until cognitive fatigue, frustration, or confusion leads them to tap “Approve.”

The Uber breach of September 2022 remains the canonical case study. The attacker purchased Uber credentials from a dark web marketplace, then sent repeated push notifications to the target employee’s phone for over an hour. When the employee didn’t respond, the attacker contacted them via WhatsApp, impersonating an Uber IT security team member and claiming the notifications were legitimate. The employee approved the request. The attacker then had authenticated access to Uber’s internal Slack, HackerOne bug reports, and several critical internal tools.

The Three Phases of a Push Harassment Campaign

Security teams benefit from understanding push harassment as a structured attack chain rather than a one-time event:

1. Credential acquisition: Valid credentials sourced from phishing, infostealer malware, or breach databases. At this stage, no MFA has been bypassed — the attacker has simply authenticated the first factor.
2. Push flooding: Automated scripts trigger repeated authentication attempts at the IdP, generating a cascade of push notifications to the victim’s registered device. Volume and timing are calibrated to maximize fatigue.
3. Social reinforcement: If push flooding alone fails, attackers layer social engineering — calls, texts, or messages impersonating IT helpdesk — to coerce the victim into approving what they’re told is a “system test” or “legitimate IT activity.”

Understanding this chain is essential because effective defenses must address all three phases, not just the notification itself.

Architectural Weaknesses in Identity Providers That Enable Fatigue Attacks

The attack succeeds not because MFA is fundamentally broken, but because most organizations deploy it in configurations that prioritize user convenience over adversarial resilience. Several IdP-level architectural choices create exploitable conditions.

Default Push Approval Without Number Matching

The most pervasive vulnerability is simple: traditional push MFA asks the user to tap “Approve” or “Deny” without requiring them to confirm any contextual detail from the login screen. An attacker triggering a push from Brazil while the user works in Chicago creates an identical prompt to a legitimate authentication request. There is no visual or cognitive differentiation.

Microsoft’s own data from their 2023 Entra ID threat intelligence shows that organizations using number matching in Microsoft Authenticator saw an 87% reduction in successful MFA fatigue attacks compared to those using simple approve/deny prompts. Number matching requires the user to enter a two-digit code displayed on the login screen into the authenticator app — a trivially simple UX change with profound security implications. Okta, Duo, and Ping Identity all support equivalent mechanisms, yet adoption as of mid-2026 remains below 55% among enterprise deployments, according to the Identity Defined Security Alliance (IDSA).

Absence of Authentication Rate Limiting and Anomaly Detection

A well-hardened IdP should throttle authentication attempts at the session initiation layer, not just at the password validation stage. If a single set of credentials generates 40 push requests within 60 minutes, that pattern should trigger an automatic account lockout, risk-score elevation, and security team alert — not the 41st push notification.

Many organizations configure their IdP’s Conditional Access or Adaptive Authentication policies only for geographic anomalies or device trust failures. They leave push attempt volume entirely unmonitored. Attackers have become aware of this gap and calibrate their push intervals specifically to avoid triggering velocity-based blocks — sending requests every 90 seconds rather than in rapid bursts.

Hardening Strategies at the Identity Provider Level

Effective IdP hardening against push harassment requires changes across authentication policy, session management, and monitoring — not just enabling a single feature toggle. The following controls represent a defense-in-depth architecture specifically engineered for this threat vector.

Enforce Number Matching and Additional Context Across All Push-Enabled Applications

Number matching should be non-negotiable in any enterprise IdP deployment as of 2026. Beyond number matching, configure your authenticator to display geographic location and application name with every push prompt. Microsoft Authenticator, Duo Push, and Okta Verify all support “additional context” policies that show the user where the login is originating from and which application is requesting access.

Implementation guidance for Microsoft Entra ID administrators: Navigate to Entra Admin Center → Authentication Methods → Microsoft Authenticator → Configure. Enable both “Require number matching” and “Show additional context in notifications” at the policy level for all users, not just privileged accounts. Apply this configuration via Conditional Access policies to ensure it cannot be bypassed by legacy authentication clients.

For Okta environments, enforce the equivalent under Security → Authenticators → Okta Verify → Edit, enabling “Show sign-in details” and configuring push challenge type to require user verification rather than simple presence confirmation.

Implement FIDO2/Passkey Authentication as the Primary Factor for Privileged Accounts

The most durable long-term defense against MFA fatigue is architectural: replace push-based MFA entirely for high-privilege accounts with FIDO2/WebAuthn hardware keys or platform passkeys. FIDO2 authentication is phishing-resistant and fatigue-immune by design — it requires physical user interaction with a hardware token or biometric device and binds the authentication to the specific origin URL, preventing replay and man-in-the-browser attacks.

The Cybersecurity and Infrastructure Security Agency (CISA) explicitly classifies FIDO2/WebAuthn as Tier 1 MFA in their 2024 MFA guidelines, while categorizing push-based OTP and simple approve/deny push as Tier 2 — acceptable but insufficient for privileged access. For accounts with access to IdP administration consoles, cloud management planes, or production infrastructure, FIDO2 hardware tokens (YubiKey 5 series, Google Titan, or device-bound passkeys on managed endpoints) should be the mandated authentication method.

Conditional Access and Adaptive Authentication Policies

Hardening at the authentication prompt level must be paired with intelligent policy enforcement at the session initiation layer. Conditional Access policies allow organizations to dynamically adjust authentication requirements based on real-time risk signals before a push notification is ever generated.

Risk-Based Authentication and Sign-In Risk Policies

Both Microsoft Entra ID P2 and Okta Identity Engine support risk-based authentication that can automatically block or step-up authentication when sign-in risk scores exceed defined thresholds. Configure policies that treat High sign-in risk (impossible travel, anonymized IP, unfamiliar device fingerprint) as grounds for blocking access entirely rather than simply requiring an additional factor — because the additional factor is precisely what the attacker is trying to exploit.

A well-designed policy set for an enterprise IdP should include:

• Block authentication entirely from Tor exit nodes, known threat actor IP ranges, and datacenter IP blocks not associated with approved cloud services.
• Require device compliance verification through MDM integration (Intune, Jamf) before push prompts are issued — ensuring that only managed, compliant devices receive authentication challenges.
• Limit authentication sessions to defined working hours with geo-fencing for accounts that don’t have legitimate global access requirements.
• Auto-remediate high-risk users by forcing password resets and revoking active sessions when Entra ID Protection or Okta ThreatInsight flags an account as compromised.

Cisco Talos published research in early 2026 documenting a campaign where threat actors specifically targeted organizations whose Conditional Access policies had gaps in coverage for legacy authentication protocols. They bypassed push MFA entirely by authenticating via IMAP and SMTP endpoints that weren’t covered by the primary CA policy — a reminder that policy coverage must be holistic, not siloed by application.

Authentication Attempt Throttling and Lockout Configuration

Configure smart lockout policies in your IdP to trigger after no more than five failed or ignored push attempts within a 10-minute window. In Microsoft Entra ID, Smart Lockout can be configured under Security → Authentication Methods → Password Protection, but for push-specific throttling, custom Conditional Access policies with sign-in frequency controls and session management settings provide more granular control. Pair lockout events with real-time SIEM alerts to your SOC — a locked account following repeated push attempts is a high-fidelity signal of an active push harassment campaign, not a routine user lockout.

Monitoring, Detection, and Incident Response for Push Fatigue Attacks

Technical controls reduce attack surface, but monitoring closes the detection gap. Push harassment campaigns that don’t immediately succeed may continue for hours or days, and organizations without specific detection logic for this pattern will miss the attack entirely until a user capitulates.

Building Detection Logic in Your SIEM

Effective detection for MFA fatigue requires log correlation across your IdP audit logs, your SIEM, and your endpoint detection platform. The key signals to monitor and alert on include:

• More than 5 MFA push requests for a single user within 30 minutes, particularly outside business hours.
• An MFA approval event following a sustained series of denials or timeouts — a pattern highly consistent with eventual capitulation.
• Geographic or device anomalies between the initiating authentication request and the approving device.
• Authentication approvals where the initiating IP is associated with known VPN services, proxy networks, or threat intelligence feeds.

Microsoft Sentinel provides a built-in analytics rule called “MFA Fatigue (Success Preceded by Many Failures)” that can be enabled from the Content Hub. For Splunk-based environments, the Okta Add-On for Splunk provides sourcetype normalization that supports similar correlation rules. Regardless of platform, the alert should route to your SOC with P1 priority — a user who has just approved an MFA request following push flooding is a live incident, not a future risk.

Tabletop Exercises and User Awareness Calibrated to This Specific Threat

Technical controls can be circumvented by human behavior, and MFA fatigue attacks succeed specifically because they exploit human psychology under stress. Organizations should include push harassment scenarios in their annual tabletop exercises and red team engagements. SANS Institute’s 2025 Purple Team survey found that only 31% of enterprise organizations had specifically simulated MFA push bombing in their adversary emulation exercises within the past 12 months — a significant blind spot given how common the attack vector has become.

User awareness communications for this threat should be specific and practical: employees should know that IT will never call or message them asking them to approve a push notification, that receiving unexpected push requests is a signal to immediately contact the security team — not to approve the request to stop the notifications — and that denying the request and calling IT is the correct response even if it feels disruptive.

Governance and Compliance Alignment for IdP Hardening

Hardening identity providers against push fatigue isn’t purely a technical exercise — it has direct implications for compliance posture under frameworks that security and compliance officers must navigate.

NIST SP 800-63B, the definitive U.S. federal standard for digital identity, classifies authentication assurance levels (AALs) in a way that is directly relevant here. Simple push-based MFA qualifies as AAL2, but only when implemented with verifier impersonation resistance — a criterion that basic approve/deny push notifications with no binding to the authentication session fail to meet. Organizations subject to FedRAMP, FISMA, or HIPAA Security Rule obligations should audit their current MFA configurations against AAL2 and AAL3 criteria and document the gap remediation as part of their Plan of Action and Milestones (POA&M).

Under the EU’s NIS2 Directive, which came into full enforcement effect across member states by late 2024, critical infrastructure operators and essential service providers are required to implement “multi-factor authentication or continuous authentication solutions” as part of their baseline technical measures. Enforcement bodies have begun interpreting this to require phishing-resistant MFA for privileged accounts — meaning FIDO2 or equivalent, not push-based approval. Organizations with European operations or data processing obligations should treat IdP hardening as a compliance requirement, not an optional enhancement.

Key Takeaways

• MFA fatigue is a policy failure, not a technology failure. Push-based MFA remains a valid control when deployed with number matching, contextual information display, and rate limiting — but the majority of enterprise deployments still lack these configurations.
• FIDO2/passkey authentication is the definitive mitigation for privileged accounts. For administrators, cloud console access, and IdP management roles, hardware tokens or device-bound passkeys eliminate the attack surface that push bombing exploits entirely.
• Conditional Access must be comprehensive. Coverage gaps — particularly around legacy authentication protocols — allow attackers to bypass push MFA entirely. Audit your CA policy stack for gaps and enforce modern authentication across all application endpoints.
• Detection logic for push fatigue should be a live SOC alert, not a retrospective finding. An MFA approval event preceded by multiple failures is a high-fidelity active incident signal and should be triaged within minutes, not hours.
• Compliance frameworks are increasingly demanding phishing-resistant MFA. NIST SP 800-63B AAL2/3, FedRAMP, and NIS2 all have provisions that standard push MFA may not satisfy without additional controls. Treat IdP hardening as a compliance deliverable with a documented implementation timeline.

Conclusion: From Configuration Debt to Adversarial Resilience

The engineer who approved that forty-third push notification wasn’t negligent — he was human, operating under conditions that an attacker had engineered precisely to exploit human cognition at its limits. The fault belonged to the organization that deployed push-based MFA without number matching, without anomaly detection, without rate limiting, and without a user culture that understood what a sustained push campaign signaled.

Hardening your identity provider against MFA fatigue and push harassment is not a six-month roadmap item. Number matching can be enabled in Microsoft Entra ID, Okta, and Duo in under 30 minutes. Conditional Access policies blocking high-risk sign-in attempts can be deployed this week. SIEM detection rules for push flooding are available as open-source content and deployable within a sprint.

The specific action to take today: Pull your IdP’s authentication method policies and audit three things — whether number matching is enforced globally (not just for admins), whether your Conditional Access policies block legacy authentication protocols across all applications, and whether your SIEM has an active alert for push approval events preceded by multiple failures