Push authentication best practices and MFA fatigue risk

At a glance

What this is: This is Authsignal’s analysis of push authentication fatigue, showing that number matching helps but does not fix the deeper architectural weaknesses that make repeated MFA prompts easy to abuse.

Why it matters: It matters because IAM teams still relying on push MFA need to decide whether they are mitigating blind approvals or redesigning the authentication flow around context, throttling, and session binding.

Context

Push authentication fatigue is a social engineering pattern against MFA push flows, not a failure of password strength alone. An attacker who already has valid credentials can trigger repeated prompts until the user approves one or is manipulated into doing so, which means the risk sits in the authentication workflow itself, not just in the user’s judgement.

For identity teams, the governance question is whether push approval is being treated as a standalone control when it really depends on session context, challenge throttling, and user trust in the prompt surface. Authsignal’s article uses real breach patterns and CISA guidance to argue that number matching is useful, but incomplete on its own.

Key questions

Q: What breaks when push MFA depends on blind approvals?

A: Push MFA breaks when users are asked to approve requests without enough context to verify the session behind them. At that point, repeated prompts become a social engineering channel rather than a security control, because the attacker only needs one accidental or coerced tap to win.

Q: Why does unlimited MFA retry increase push fatigue risk?

A: Unlimited retries let an attacker keep generating prompts until a user gives in or makes a mistake. Without challenge-rate controls, the system turns repeated authentication attempts into a harassment loop, which is exactly what push fatigue attacks depend on.

Q: How do security teams know whether push MFA is too abstract to trust?

A: Look for prompts that show little more than a generic approve sign-in message, with no meaningful request context, session linkage, or risk signal. If the user has to guess why the prompt arrived, the control is already too thin to resist phishing or fatigue.

Q: When should organisations move beyond push authentication to stronger methods?

A: Organisations should move beyond push as the primary control when the account or action has high blast radius, when users are repeatedly targeted, or when the login flow cannot reliably bind approval to an active session. In those cases, phishing-resistant methods are the safer baseline.

Technical breakdown

Why push prompts become socially engineerable

Push MFA is vulnerable when the approval action is separated from the login context. A user receives a generic request in a third-party authenticator and has to decide whether it belongs to a session they can see elsewhere. That weak coupling makes the prompt easy to impersonate with a phone call, chat message, or repeated notifications. The control fails less because the user is careless and more because the interface gives them too little context to verify the request. In practice, the attack succeeds when the approval surface is abstract, high-friction, and easy to normalise under repetition.

Practical implication: reduce abstract approvals by binding the challenge to the active session and exposing request context where the user can verify it.

Why unlimited retries turn MFA into an abuse channel

If challenge creation is not throttled, an attacker can keep generating prompts until the user relents. The important design flaw is that many systems rate limit notification delivery rather than the creation of challenges, so each new attempt looks isolated even when it is part of the same attack. That turns MFA into a harassment mechanism. The security control is not just user education, it is a limit on how many times a principal can be challenged before the system changes state, alerts, or stops accepting the same pattern of requests.

Practical implication: enforce challenge-rate controls upstream of the notification layer and escalate repeated denials as a security signal.

How number matching changes the approval model

Number matching adds a second factor of context by requiring the user to copy a code from the live login session into the authenticator. That defeats blind approvals because an attacker on a separate channel does not have the code tied to the legitimate session. But it does not eliminate the broader abuse path if prompts are still decoupled from the browser session or if the attacker can keep forcing fresh challenges. Number matching raises the cost of accidental approval; it does not by itself re-architect the trust model behind push authentication.

Practical implication: treat number matching as a selective anti-phishing control, not as the full control design for push MFA.

Threat narrative

Attacker objective: The attacker wants to turn a valid password and a single approved push into durable access across the victim’s internal environment.

1. Entry begins with a stolen password purchased from a dark web marketplace, which gives the attacker a valid starting credential.
2. Escalation happens when repeated MFA push prompts and social engineering pressure the user into approving one request.
3. Impact follows when the attacker uses the approved session to reach VPN access and then pivots into cloud and collaboration systems.

Breaches seen in the wild

• Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Push fatigue is an approval-design failure, not just a user-error problem. The control breaks when authentication treats every prompt as a discrete event rather than part of a session with context. That is why repeated prompts can overwhelm a user even when passwords are correct and MFA is enabled. The practitioner lesson is that push MFA has to be analysed as a workflow, not a button.

Abstract prompts create trust debt in MFA programmes. When the user sees only a generic approval request, the system is asking for trust without supplying enough context to justify it. That trust debt is what attackers exploit with a phone call, a chat message, or a fabricated help desk story. The problem is architectural because the prompt itself withholds the evidence a user would need to refuse confidently.

Number matching reduces blind taps, but it does not resolve the underlying challenge-generation model. A code check helps when the user is near the legitimate login flow, yet it leaves unlimited retries and detached notification logic in place. The control is therefore a mitigation against one abuse technique, not a complete answer to push-based MFA abuse. Teams should stop treating it as the end state.

Session-bound authentication should replace notification-only thinking. The article’s strongest signal is that the phone must know which browser or application session is requesting approval. That shifts trust from the notification itself to the live transaction behind it. For IAM programmes, the implication is that push MFA design now belongs in the same governance conversation as phishing resistance and authentication assurance.

Push MFA needs governance over issuance, not just user behaviour. Repeated prompts, alert fatigue, and social engineering are symptoms of a weaker control plane. A mature programme measures whether the authentication method can be abused at issuance time, not only whether users can be trained to tap more carefully. That is where modern identity governance has to move.

What this signals

Trust in push authentication now depends on whether the approval flow is tied to the live session, not whether the user notices the notification. Teams that still rely on abstract prompts are carrying a larger social engineering surface than they may realise. The control boundary has shifted from the device alert to the session itself.

Number matching is a useful friction layer, but it should be treated as a transitional control. It lowers the success rate of blind taps, yet it does not solve repeated challenge generation or the weak trust relationship between the app and the request being approved. The governance problem is broader than one extra code.

Push authentication fatigue exposes an identity assurance gap that programme owners should measure explicitly. If a method can be abused through repetition, impersonation, and contextual ambiguity, it is not delivering the level of assurance many teams assume. That gap belongs in authentication policy reviews, not just user training.

For practitioners

• Turn on number matching where push MFA remains in use Use it as a floor for reducing blind approvals, especially on consumer-facing or high-volume sign-in paths where one-tap approval is too easy to abuse.
• Throttle challenge creation, not just notification delivery Limit repeated MFA challenge issuance for the same identity and escalate persistent denial patterns to security monitoring instead of treating each prompt as independent.
• Bind approvals to the active session Ensure the challenge can be tied to the browser or app session that initiated it so the user can see whether the request is live and expected.
• Remove abstract prompt language from the approval flow Show enough request context in the approval step for the user to distinguish a real login from a fabricated support narrative or replayed prompt.
• Reserve push for low-risk sign-ins and step up for sensitive actions Use stronger verification for password resets, withdrawals, and other high-impact transactions so push is not the only gate on material account changes.

Key takeaways

• Push fatigue attacks succeed when MFA prompts are repeated, context-poor, and easy to socially engineer, even if the password itself is valid and MFA is enabled.
• Number matching helps stop blind taps, but it does not remove the retry abuse path or the deeper design issue of detached approval prompts.
• Identity teams should treat push authentication as a controllable workflow with session binding and throttling, not as a simple yes or no approval step.

Key terms

• Push fatigue: A condition where repeated mobile approval prompts train users to approve authentication requests without careful review. Attackers exploit the fatigue to turn a human decision into an accidental bypass, especially after they already know the password.
• Number Matching: Number matching is an MFA method that requires the user to enter or confirm a number shown on the login screen. It reduces blind approvals by linking the approval to the specific session, which makes random taps or reflexive acceptance far less effective.
• Session Binding: A control that ties an authenticated session to the device, connection, or risk context that created it. When applied well, it makes stolen cookies harder to reuse from an untrusted endpoint or a different network context.
• Challenge Rate Limiting: A control that restricts how many authentication prompts can be created for the same identity or session in a defined period. It is stronger than notification throttling because it stops the abuse at issuance time, before the user is flooded with prompts.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.