Push authentication best practices and MFA fatigue risk

At a glance

What this is: This is an analysis of push authentication weakness, showing that MFA fatigue succeeds when stolen credentials, unlimited retries, and low-context prompts combine.

Why it matters: It matters because IAM teams must treat push MFA as an interaction design problem as well as an authentication control, especially where human approval gates protect access to cloud, SaaS, and administrative systems.

👉 Read Authsignal's analysis of push authentication best practices and MFA fatigue

Context

Push authentication is only as strong as the session, prompt, and retry controls around it. When an attacker already has a valid password, repeated MFA prompts can become a pressure channel rather than a verification step, especially if the user sees little context and the system allows unlimited retries.

For IAM programmes, the problem is not just whether a push is approved by the correct person. It is whether the approval flow preserves enough context, rate limiting, and session binding to resist fatigue, social engineering, and accidental consent across consumer, workforce, and privileged access use cases.

Key questions

Q: How should security teams reduce push fatigue attacks in MFA flows?

A: Start by binding each challenge to the live session, then add throttling for repeated denials and challenge creation. Number matching helps, but the control only works when the system also limits blind retries and records prompt bursts as suspicious behaviour. For privileged or remote access, move toward phishing-resistant authentication methods.

Q: Why do repeated MFA prompts increase account takeover risk?

A: Repeated prompts create pressure, confusion, and habituation. When a user has already denied several notifications, the chance of an accidental tap or coerced approval rises sharply. If the attacker already has a valid password, the approval loop becomes the weak point, especially when the prompt lacks origin, session, or device context.

Q: What do security teams get wrong about number matching?

A: They often treat it as a complete fix when it is really a partial mitigation. Number matching blocks some blind approvals, but it does not stop unlimited challenge generation, social engineering, or poor session design. It should be used as one layer in a broader push authentication control model.

Q: Who is accountable when push MFA fatigue leads to unauthorised access?

A: Accountability sits with the identity and access team that defines the authentication control, the application owner that accepts the risk, and the security leaders who decide whether push is sufficient for the access class. For high-risk access, governance should require stronger authenticators and documented escalation paths.

Technical breakdown

Why push fatigue works against weak prompt design

Push fatigue, also called MFA fatigue or prompt bombing, exploits a mismatch between how authentication is initiated and how it is approved. The attacker starts with a stolen password, then triggers repeated push prompts until the user approves one. If the prompt contains only a generic service name and no session context, the user has little evidence to distinguish a legitimate request from a manufactured one. The weakness is not push itself, but unauthenticated approval flow design that assumes one prompt equals one honest request.

Practical implication: require contextual prompts and tie approvals to the live session, not just the account being challenged.

Why number matching is a partial control, not a complete fix

Number matching adds a second factor of context by requiring the user to enter a code from the live web session into the phone. That blocks blind approvals and makes phishing harder, but it does not stop unlimited challenge generation or solve the broader trust gap between the authenticator and the application. CISA frames it as an interim mitigation, which is the right lens. It reduces risk in one place, but it does not remove the underlying attack conditions that let prompt bombing scale.

Practical implication: use number matching as one layer in a wider anti-fatigue design, not as the sole defence.

Why retry throttling and session binding matter more than notification volume

A robust push control plane limits challenge creation, not just notification delivery. If the user’s device receives fewer badges but the server still allows unlimited prompts, the attacker retains control of the pressure loop. Session binding closes another gap by ensuring the phone knows which browser or application session is asking. That lets the system detect when there is no active login context, when prompts arrive too quickly, or when approval occurs without a matching initiation event.

Practical implication: move throttling upstream into the authentication workflow and bind every challenge to a live session identifier.

Threat narrative

Attacker objective: The attacker aims to convert one stolen password into durable enterprise access and then pivot into high-value internal systems.

1. Entry begins when the attacker obtains a valid password from a marketplace or similar source and uses it to start the sign-in flow.
2. Escalation occurs when repeated push prompts exhaust the user’s tolerance or a social engineering message convinces the user to approve one request.
3. Impact follows when the attacker uses the approved session to access VPN, cloud services, collaboration tools, or internal administration surfaces.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Push authentication only works when the approval loop is bound to live session context. The article shows that a generic prompt with no request origin, session link, or behavioural context leaves users to guess under pressure. That is not an authentication guarantee, it is an assumption that a human can reliably detect deception while being spammed. Practitioners should treat context binding as part of the control, not an enhancement.

Number matching is a friction control, not an anti-fraud architecture. It can stop the simplest blind taps, but it does not eliminate unlimited retries, social engineering, or the trust gap created when the authenticator sits outside the product the user is trying to access. The implication is that pushing more users through the same workflow only buys time unless the workflow itself changes.

Prompt fatigue is really a governance failure around approval authority. The breach pattern shows that approval can be coerced when the system treats repeated denials as noise rather than as evidence of attack. That makes access decisions too dependent on user endurance, which is a poor control basis for high-value IAM and PAM flows. Security teams need to reclassify repeated push denials as a security signal, not a UX nuisance.

Context-aware push changes the trust model by reducing the distance between request and approval. When the challenge is tied to the live session and generated inside the trusted application context, the attacker loses the narrative advantage that makes fatigue attacks work. The practical lesson is not to abandon push, but to stop treating all push implementations as equivalent under MFA policy.

Push fatigue reveals a broader identity design flaw: approval without proof of origin scales poorly. This is the same governance weakness that shows up in other consent-based flows, from consumer login to privileged step-up. IAM programmes should assume that user attention is a scarce resource and build controls that do not depend on repeated human judgment under stress.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• Push fatigue is a governance problem as much as an authentication problem, and the Ultimate Guide to NHIs , The NHI Market helps frame how identity control models fail when trust assumptions are too broad.

What this signals

Prompt fatigue is a reminder that identity controls fail when they depend on user endurance. In practice, IAM teams should watch for every authentication flow that asks a human to resolve ambiguity under pressure, because the same coercion pattern can appear in workforce access, customer login, and privileged step-up paths.

The governance signal is clear: number matching is a useful threshold control, but phishing-resistant authentication and session binding will keep rising in priority for privileged access. Teams that still classify MFA quality by factor count alone will miss the real control question, which is whether the approval path can be coerced faster than it can be interpreted.

With 44% of developers following secrets-management best practices according to our research, identity programmes cannot assume adjacent controls are consistently implemented. A weak surrounding control environment makes even well-designed authentication journeys easier to subvert.

For practitioners

• Bind push challenges to the initiating session Ensure the prompt can verify the browser or application session that created it, and suppress approval when no matching live session exists. This reduces blind approvals and makes off-path social engineering harder.
• Throttle challenge creation upstream Rate-limit prompt generation in the authentication workflow itself, not just on the notification channel. Set escalation thresholds for repeated denials so the system can switch methods or flag the account for review.
• Use number matching for high-risk actions only Reserve number matching for sign-in exceptions, payments, password resets, and privilege elevation. Keep low-risk sessions low-friction, but require stronger context when the approval would materially expand access.
• Treat repeated denials as an attack signal Send denial bursts into monitoring and case-management workflows so SOC or IAM teams can investigate prompt bombing patterns before a user finally approves one.
• Move toward phishing-resistant MFA for privileged access Prioritise stronger authenticators for administrators, remote access, and cloud control planes where a single coerced approval can unlock disproportionate blast radius.

Key takeaways

• Push fatigue succeeds because repeated prompts turn human approval into a pressure point rather than a trustworthy verification step.
• Number matching helps, but it does not fix unlimited retries, missing session context, or the broader design gap in push authentication.
• IAM teams should treat prompt bursts, session binding, and phishing-resistant MFA as governance issues for high-risk access, not optional hardening.

Key terms

• Push Fatigue: Push fatigue is an MFA attack pattern where repeated authentication prompts wear down a user until one is approved. It is not a protocol flaw alone. It is a control design weakness that appears when approval lacks enough context, throttling, and session binding to resist coercion.
• Number Matching: Number matching is a push authentication variant that requires the user to enter a code shown on the sign-in session into the authenticator prompt. It reduces blind approvals, but it remains a partial mitigation if challenge generation is unlimited or the approval flow is weakly bound to the session.
• Session Binding: Session binding links an authentication challenge to the specific browser, app, or transaction that initiated it. For human IAM, this creates visible context for the user. For high-risk access, it also gives security teams a way to distinguish legitimate approvals from off-path coercion.

What's in the full article

Authsignal's full blog post covers the operational detail this post intentionally leaves for the source:

• A step-by-step breakdown of the Uber contractor attack path and the sequence of approvals used by the attacker.
• A deeper explanation of how the product binds challenges to the live session and reduces prompt fatigue.
• The specific number matching flow for high-risk actions, including when the code appears and how the approval is unlocked.
• Implementation details on rate limiting, notification suppression, and risk-rule thresholds for repeated denials.

👉 Authsignal's full post covers the Uber attack chain, number matching flow, and push control design details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.