Why does push-based MFA create risk when users are repeatedly challenged?

Repeated MFA prompts turn a strong factor into a weak decision point

Push-based MFA is designed to add a second check, but its effectiveness depends on the user treating each challenge as meaningful. When prompts arrive repeatedly, the control starts to resemble background noise rather than a security decision. That matters because the attacker is no longer trying to defeat the factor directly; they are trying to wear down the person who must interpret it. NIST Cybersecurity Framework 2.0 is useful here because it frames authentication as part of a broader resilience and governance problem, not just a technical login step.

Repeated challenges also reduce the signal value of a genuine prompt. Users begin to assume the request is routine, incorrectly timed, or generated by a system glitch. Once that mental model takes hold, the barrier shifts from “can the attacker authenticate?” to “can the attacker create enough annoyance to make approval feel harmless?” In practice, many security teams encounter this failure only after users have already been conditioned by harmless-looking noise to approve without checking the request source.

How the risk develops during prompt bombing

Push fatigue usually develops in a simple sequence. First, an attacker obtains a username and password through phishing, reuse, or another access path. Next, the attacker repeatedly triggers MFA pushes, often in bursts that interrupt the user at inconvenient times. If the user is busy, confused, or frustrated, a few prompts can turn into a pattern of reflexive acceptance. At that point, the attacker does not need to break the authentication method itself; they need only secure one mistaken approval.

The practical weakness is that push-based MFA assumes the human will act as the final verifier. That assumption is sound when challenges are rare and clearly tied to a real login attempt. It becomes fragile when the same person sees many requests close together, especially if the system does not show enough context to distinguish a legitimate request from abuse. Useful safeguards include rate limiting, number matching, clear device and location context, and alerting on unusual challenge volume. Where implementations are weak, repeated prompts can also mask a broader account compromise because normal users and help desks may dismiss the pattern as a nuisance rather than a sign of active abuse.

• High prompt frequency weakens user attention and increases the chance of accidental approval.
• Context-poor prompts make it harder to tell legitimate access from attacker-triggered requests.
• Controls that stop only one login attempt do not address the underlying fatigue created by repeated challenges.

The guidance breaks down when organisations treat MFA as a user training problem alone and ignore the need to constrain prompt volume, enrich request context, and detect abnormal challenge patterns.

When push MFA is acceptable, and when it needs a stronger design

Tighter MFA challenge flows often improve security, but they also increase user friction, so organisations have to balance resistance to abuse against login usability. There is no universal consensus that push notifications should be eliminated everywhere; the better view is that they should be reserved for environments where the authentication workflow can tolerate the human overhead and where abuse signals can be detected quickly. If a login process is exposed to frequent external attempts, plain approval pushes are usually too easy to exhaust.

One edge case is low-volume, low-risk access where push MFA is paired with strong device binding and contextual signals. Even there, teams should be cautious if the same user receives repeated interruptions, because the control’s real weakness is not just authentication failure but habituation. Another edge case is support-heavy environments where users rely on help desks for routine access recovery. In those settings, repeated prompts may get normalised as “just how the system works,” which reduces challenge quality over time. When that happens, a stronger method with less approval ambiguity may be more appropriate.

For identity-heavy environments, the real decision is not whether MFA exists, but whether the chosen factor can still make a trustworthy decision under pressure. If the answer is no, the organisation has a control design problem rather than a user-compliance problem.

Practitioner Guidance

What to prioritise: Reduce repeated approval opportunities before you rely on user judgement. The most effective response is to suppress prompt storms, add request context, and make abnormal challenge patterns visible to operations.

What to verify: Confirm that the MFA flow gives users enough detail to recognise an unexpected request, and that security teams can detect unusually dense prompt activity on a per-user basis. If those two conditions are missing, the control is easier to exhaust than it first appears.

Common mistake: Treating every approval as informed consent. Repeated prompts often reflect fatigue, not trust, so a single successful approval may tell you more about user conditioning than about real authentication strength.

Practitioner takeaway: Push MFA is most vulnerable when the attacker can turn a security prompt into a habit, because habit erodes the very judgement the control depends on.

Related resources from NHI Mgmt Group

• Why do push-based MFA flows create more risk for privileged and remote access than they reduce?
• Why do OTP and push-based MFA create risk in high-value enterprise access flows?
• Why do non-human identities create more risk than many human accounts?
• Why do non-human identities create more remediation risk than many human accounts?