Notifications
Clear all
Topic starter
10/07/2026 9:19 pm
TL;DR: Push fatigue attacks exploit stolen passwords, unlimited MFA retries, and abstract push prompts to trick users into approving sign-ins, according to Authsignal’s analysis of real-world breach patterns and CISA guidance. Number matching helps, but it does not address the deeper architectural issues that make push MFA easy to socially engineer.
NHIMG editorial — based on content published by Authsignal: Push authentication best practices, and why number matching alone is not enough
Questions worth separating out
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.
Q: Why do repeated MFA prompts increase account takeover risk?
A: Repeated prompts create pressure, confusion, and habituation.
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.
Practitioner guidance
- 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.
- Throttle challenge creation upstream Rate-limit prompt generation in the authentication workflow itself, not just on the notification channel.
- Use number matching for high-risk actions only Reserve number matching for sign-in exceptions, payments, password resets, and privilege elevation.
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.
👉 Read Authsignal's analysis of push authentication best practices and MFA fatigue →
Push authentication fatigue: are your controls keeping up?
Explore further
10/07/2026 9:42 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Push authentication best practices and MFA fatigue risk
