A multifactor authentication prompt is supposed to be a barrier: the password alone is not enough, so the user must confirm possession of another authenticator. MFA fatigue attacks exploit a weakness in some push-based workflows by turning that confirmation into a repeated human decision. The attacker keeps generating requests until the user approves one accidentally, approves one to stop the noise, or is persuaded by a social-engineering call that the request is legitimate.
The important point is that the attack usually begins before the first push notification appears. An adversary commonly already has the username and password, or has found another way to trigger an authentication flow for the victim. The push request is the remaining obstacle. For SY0-701, that cause-and-effect chain matters more than remembering “MFA fatigue” as a standalone label.
The attack is a state machine, not just a flood of notifications
Imagine a sign-in system with three broad stages. First, the user presents the primary credential. Second, the system decides that a second factor is required and sends a push challenge to the registered device. Third, the user’s response changes the authentication state from pending to approved or denied.
An attacker with the primary credential can repeatedly force the system into the second stage. Each new request creates a legitimate notification generated by the real authentication service. That detail is what makes the experience confusing: the message itself may not be forged. The malicious action is the attacker initiating the sign-in and trying to manipulate the human response.
The attacker wins when one request is approved and the system binds that approval to the attacker’s session. The attacker does not need to defeat the cryptography protecting the push channel. The attack instead abuses the workflow around the cryptography.
Why repeated prompts change user behavior
Push approval was designed to reduce friction. Instead of copying a one-time code, a user can tap approve. That convenience compresses a security decision into a fast yes-or-no interaction, often on a device that is already full of notifications.
Fatigue attacks add pressure. Requests may arrive rapidly, late at night, during a meeting, or after the attacker calls while pretending to be the help desk. A user who has already denied several prompts may assume there is a technical problem. If the prompt contains little context, the user may not know which application, location, or sign-in attempt caused it.
This is why security guidance that relies only on “train users not to approve unknown prompts” is incomplete. Awareness helps, but a resilient design should reduce the number of circumstances in which a single tired or confused tap can authorize an attacker. The broader pattern appears in many authentication attacks: attackers search for the point where a technically valid process depends on a weak human assumption.
Number matching changes the question the user must answer
One defense is to replace a generic approve/deny prompt with a challenge that requires the user to match information from the sign-in screen, such as entering or selecting a number. The user can no longer approve a request without having some context from the active login attempt.
This makes blind push bombing harder because the attacker and victim are looking at different screens. It also makes an unexplained notification more obviously suspicious. However, number matching is not the same as phishing resistance. A convincing attacker can still try to relay the number through social engineering, and a sophisticated adversary-in-the-middle can manipulate some authentication flows that depend on human-entered values.
The lesson is that an improvement in interaction design changes the attacker’s cost but does not necessarily remove the underlying class of attack. Defenders should understand what the control prevents, what it merely makes harder, and what attack paths remain.
Phishing-resistant authentication removes more of the relay problem
NIST’s current digital identity guidance distinguishes phishing-resistant cryptographic authenticators from methods in which a user manually transfers an authentication output. Technologies built around public-key credentials, such as WebAuthn/FIDO-style authenticators, can bind the authentication to the legitimate verifier rather than relying on the user to recognize every fraudulent request correctly.
That binding changes the mechanics. A fake site cannot simply collect a valid one-time value and replay it to the real service if the authenticator generates a response for the legitimate verifier identity. The user may still be socially engineered in other ways, but the authenticator itself is designed to resist the classic relay path.
This does not mean every organization can replace every authenticator immediately. Legacy applications, device constraints, recovery processes, contractors, and remote access systems may create transition periods. The security architecture should therefore identify which users and resources justify the strongest authentication first—privileged administrators, remote access, identity administrators, finance systems, and other high-impact paths.
A broader view of multifactor authentication for cloud access is useful here because MFA strength depends on the factor and protocol, not merely on the fact that two steps appear on the screen.
Rate limiting and risk policy can stop the attack before the user is exhausted
If one account can generate dozens of push challenges in a short period, the authentication service is allowing the attacker to convert stolen credentials into repeated pressure on the victim. Rate limiting, suppression of repeated challenges, and risk-aware policy can reduce that leverage.
Context can include unfamiliar location, new device, impossible travel patterns, suspicious IP reputation, recent password reset, or unusually repeated denials. The exact signals vary by platform, but the architectural idea is consistent: repeated failed or rejected authentication attempts should change how the system behaves.
A high-risk sign-in might require a phishing-resistant factor, block the attempt, or trigger investigation rather than sending another identical approval request. A sequence of denials followed by one approval is particularly important telemetry because it can represent the moment fatigue succeeded.
Rate limits must be designed carefully so an attacker cannot easily lock users out on demand. The goal is not simply to stop all retries; it is to prevent the authentication mechanism from becoming an unlimited notification generator while preserving legitimate recovery paths.
The attack can continue after the successful approval
Approving one malicious sign-in may create more than a single browser session. The attacker may register an additional authentication method, grant application consent, create a persistent token, change recovery information, establish mailbox rules, or use the session to reach other federated applications. The exact options depend on the environment and privileges.
This is why response should not end with a password change. Defenders need to inspect authentication-method changes, revoke active sessions and refresh tokens where supported, review new devices and application grants, verify recovery channels, and examine what the attacker accessed during the window of compromise.
The same principle applies to help-desk processes. If an attacker can persuade support staff to reset MFA or enroll a new factor, stronger push settings will not protect the account. Recovery and factor enrollment are part of the authentication system, not administrative side tasks.
Telemetry should describe the sequence, not just the final success
A single successful login can look ordinary. The sequence around it is what makes an MFA fatigue event visible: repeated primary-authentication successes, multiple push requests, several denials or timeouts, a later approval, a new location or device, and perhaps an authentication-method change shortly afterward.
Security operations teams should therefore preserve enough identity telemetry to correlate those steps. Useful questions include: How many MFA challenges did this account receive in a short window? Were the challenges initiated from the same source? Did the user deny some before approving one? Was the successful session followed by privilege use, new factor registration, or access to unusual applications?
Alerts should also consider the health of the notification channel. A user who reports unexpected prompts is providing high-value incident evidence. Treating that report as “just deny them” misses the fact that someone may already possess the primary credential.
Recovery paths deserve the same threat model as the login prompt
Organizations sometimes harden the primary sign-in but leave recovery weaker. A user who loses a phone may be allowed to enroll a replacement factor after answering help-desk questions, receiving a temporary access pass, or using another recovery channel. Those workflows are necessary, but they become alternative authentication protocols from an attacker’s perspective.
A useful review asks whether the recovery path can be triggered remotely, what evidence the support team sees, whether high-risk accounts require stronger verification, and whether a factor replacement generates immediate alerts. Temporary credentials should have narrow scope and lifetime, and a reset should not silently preserve suspicious sessions. The security of the strongest daily authenticator can be undermined if an attacker can cheaply persuade someone to replace it.
The strongest design reduces the number of decisions users must get right
Security training still matters. Users should know that unsolicited MFA prompts are a sign to deny the request and report it. But the long-term goal is to move from a model in which the user must repeatedly detect an attacker to one in which the system makes abuse difficult by design.
That can mean phishing-resistant authentication for sensitive access, number matching during transition, stronger context in prompts, sensible retry limits, risk-aware access policy, protected factor enrollment, session revocation, and monitoring for suspicious authentication sequences. Authentication methods beyond passwords should be selected according to the attack path they actually interrupt.
Within CompTIA Security+, MFA fatigue is a useful example of why “MFA enabled” is not a complete security statement. The outcome depends on the factor, the protocol, the user interaction, the retry behavior, the recovery path, the surrounding telemetry, and what the organization does after a suspicious approval. Understanding that system is what turns a memorized attack name into defensive judgment.
