A push notification can make multi-factor authentication feel effortless: enter a password, tap Approve on a registered device, and continue. The same convenience creates a problem when the approval prompt does not require the user to prove which login they are approving.

If an attacker obtains a password and can repeatedly trigger MFA requests, the legitimate user may receive prompts they did not initiate. A tired, distracted, or confused user may eventually approve one. This is commonly called MFA fatigue or push fatigue.

The useful defensive model is not simply “send fewer notifications.” Treat every approval as authority for one specific authentication transaction. The user should have a clear reason to expect the prompt, and the protocol should bind the approval to the login they actually started.

The weakness is ambiguous approval

Consider a simple password-plus-push flow:

browser                         phone
   |                              |
   | password accepted            |
   |                              |  "Approve sign-in?"
   |                              |<-----------------
   |                              |  Approve
   |<-----------------------------|
   | signed in                    |

The phone proves that someone with access to the registered authenticator approved an authentication request. The important question is whether it gives the user enough information and protocol binding to know that this is their current request.

A plain yes-or-no prompt is weak at that distinction. If the user has not just initiated a login, “Approve sign-in?” should be suspicious. But the protocol is asking human attention to carry most of the security burden.

That becomes worse when an attacker can generate many prompts. Repetition changes the user’s experience from a rare security decision into an interruption. The attacker does not need to defeat the authenticator cryptographically if one accidental approval completes the attacker’s session.

The threat model here is specific: an attacker can reach the first authentication step, often because a password is known or guessed, and can cause approval requests to reach a legitimate registered authenticator. The control discussed here reduces the chance that the legitimate user authorizes the attacker’s transaction. It does not protect a compromised authenticator, a stolen unlocked device, or a verifier that already trusts the wrong account or device.

Bind the second factor to the first-channel login

The stronger mental model is a pending authentication transaction:

primary login creates transaction T
             |
             +--> browser is participating in T
             |
             +--> authenticator must approve T

The second factor should not act as a generic “yes, this account may log in now” button. Its response should complete a particular transaction created on the primary channel.

One way to create that relationship is to transfer a short-lived secret or challenge between the primary login and the authenticator. The exact mechanism depends on the authentication protocol. The security property is what matters: approving a challenge associated with transaction T1 must not approve a different transaction T2 that an attacker started.

For example, a design may show a challenge in the browser and require the user to transfer it to the authenticator. That transfer can be manual or use a mechanism such as scanning a QR code when the protocol supports it:

browser                       authenticator
   |                               |
   | transaction T                 |
   | challenge C                   |
   |------------------------------>|
   |                               | confirm T using C
   |<------------------------------|
   | complete T                    |

This adds deliberate participation. A remote attacker who merely knows the password can cause their own transaction to exist, but the legitimate user’s authenticator should not silently turn an unrelated notification into approval for it.

The challenge must be generated and validated according to the authentication protocol. Do not invent an ad hoc code-exchange scheme around a push service and assume that visual similarity creates cryptographic binding.

Why displaying more context is not the same as binding

A prompt can display useful context such as the application name, approximate location, device description, or time. This can help a user notice an unexpected request, but context is not a reliable transaction-binding mechanism by itself.

Location can be imprecise. Device descriptions can be generic. A user may legitimately sign in through a network that makes the location look unfamiliar. Conversely, an attacker’s request may look ordinary enough that the user accepts it.

The distinction is:

context: "Does this request look familiar?"
binding: "Does this approval belong to the transaction I started?"

Context supports the decision. Binding changes what the protocol requires before the transaction can complete.

This is also why a design that merely displays matching information on two screens needs careful analysis. If completion still depends on the user noticing and comparing values correctly, the system retains a human-comparison failure mode. Prefer established authentication mechanisms whose transaction-binding properties are documented rather than creating a custom “number matching” workflow and assuming that any matching display solves push fatigue.

Limit how much pressure an attacker can create

Transaction binding addresses the meaning of an approval. Rate limiting addresses a different part of the problem: how often an attacker can demand the user’s attention.

An authentication service should place a reasonable bound on push requests. The policy needs to consider more than a single source IP because distributed attempts can come from many addresses. It also should not create an easy denial-of-service mechanism where an attacker can permanently block a victim’s account by intentionally exhausting a small quota.

A practical design may combine short-term limits with suppression or backoff for repeated outstanding requests. For example, if one authentication transaction for an account is already awaiting approval, creating several more notifications immediately may provide little legitimate value.

The exact thresholds depend on expected login patterns, recovery options, and the cost of false positives. The invariant is more portable than a particular number:

An unauthenticated party should not have an unlimited ability to generate security prompts on someone else’s device.

Rate limiting does not repair ambiguous approval. A single unexpected prompt can still be approved. Likewise, strong transaction binding does not make notification flooding harmless. The two controls address different failure modes.

Make unexpected prompts actionable

Users need a safe response to a prompt they did not initiate. “Deny” is useful, but the system should decide what denial means operationally.

A rejected unexpected request can be a security signal because the legitimate user is telling the verifier that an authentication transaction was not theirs. Depending on the application’s risk model, repeated denials may justify additional throttling, an account notification, or an investigation signal.

Be careful not to turn one denial into an automatic account lock that anyone can trigger by starting a login and causing the victim to reject it. Detection and containment should account for the possibility that the attacker controls the request generation but not the authenticator.

The authenticator interface should also avoid teaching users that approval is the normal way to dismiss a notification. The safe action for an unsolicited request must be obvious. If the product provides a “This wasn’t me” path, that path should not require the user to approve the transaction first.

Keep approval transactions short-lived and single-use

An authentication approval is temporary evidence, not a standing permission.

Each pending transaction should have a bounded lifetime. When it expires, a later approval must not revive it. Once an approval succeeds or is rejected according to the protocol, the same transaction should not be reusable to authenticate another session.

Conceptually:

pending -> approved -> consumed
        \-> denied
        \-> expired

The server must enforce these states. Hiding an old prompt in the user interface does not invalidate the server-side transaction.

Concurrency matters too. If two workers process responses for the same transaction at nearly the same time, the state transition should ensure that only the permitted result takes effect. Database constraints, transactions, conditional updates, or equivalent atomic mechanisms can enforce that invariant depending on the architecture.

Short lifetimes reduce the period in which stale authentication material can be used, but an arbitrarily tiny window can harm legitimate users on slow networks or devices. Choose the lifetime from the protocol’s requirements and real operational conditions rather than treating “shorter” as automatically better.

Authenticate the authenticator, not just the notification channel

A push notification is a delivery signal. It should not be the credential itself.

A robust design needs the registered authenticator to establish an authenticated protected relationship with the verifier before its response is trusted. The verifier should know which enrolled authenticator is responding, according to the authentication mechanism’s key and device-binding model.

This distinction matters because notification infrastructure may involve intermediary services. Receiving a notification does not by itself prove that a response came from the enrolled authenticator. The authentication protocol needs its own evidence.

Protect authenticator enrollment with the same care. If an attacker who controls only a password can silently register their own approval device, improving push prompts on the legitimate user’s phone does not solve the account-takeover path. Adding or replacing an authenticator is a security-sensitive account-control change and should require evidence appropriate to the authority being granted.

Do not confuse push MFA with phishing-resistant authentication

Better push approval reduces a real risk, but it does not automatically make the authentication method phishing-resistant.

A phishing-resistant authenticator uses cryptographic protocol properties to prevent authentication secrets or outputs from being accepted by the wrong verifier context. User recognition of a brand name, location, or prompt is not equivalent to that property.

For applications that face meaningful phishing risk, consider established phishing-resistant authenticators rather than trying to add enough warnings to a weaker flow. The appropriate choice depends on user population, platform support, recovery requirements, and the impact of account compromise.

Push-based authentication may still be a reasonable control in some environments. If it is used, its limitations should be explicit so that the rest of the security design does not assume stronger guarantees than the mechanism provides.

Test the failure paths, not only successful approval

A happy-path test proves very little about MFA fatigue resistance. Test the states that an attacker or ordinary operational failure can create.

Useful cases include:

  • an approval arrives for an expired transaction;
  • an approval belongs to a different pending transaction;
  • the same approval is submitted twice;
  • several login attempts try to generate notifications for one account at once;
  • a user denies an unexpected request;
  • an enrolled authenticator is removed while a transaction is pending;
  • notification delivery is delayed until after the transaction expires.

Also verify what the user sees. A security protocol can have sound server-side state while the interface still makes dangerous actions easy to confuse. The prompt should identify the action clearly, and unsolicited requests should have an obvious rejection path.

Operational monitoring should record enough non-secret information to investigate unusual approval and denial patterns. Do not log authentication challenges, reusable session credentials, authenticator private material, or other secrets merely to make troubleshooting easier.

Choose the boundary you actually need

If an application uses push MFA, start by drawing the two authentication channels and the transaction that connects them. Ask what evidence makes an authenticator response valid for this login rather than any login on the account.

Then test the uncomfortable case: the password is already known to an attacker, but the registered authenticator remains under the legitimate user’s control. The design should limit the attacker’s ability to generate prompts, make unsolicited requests easy to reject, keep approvals short-lived and single-use, and bind successful approval to the intended authentication transaction.

That is the practical goal of MFA fatigue resistance. The notification is only a user-interface event. The security boundary is the protocol decision about exactly which login an authenticated response is allowed to complete.

Cybersecurity Authentication MFA Phishing Resistance