The attacker already has the password. That part is finished, usually months earlier, from a breach dump or a phishing page. What stands between them and the account is a push notification on somebody's phone, and the whole attack is a bet that the person will eventually tap approve.
A push prompt asks a yes or no question with no context. It does not say what is being signed into, from where, or why now. A person who receives forty of them at two in the morning is not making a security decision, they are trying to make their phone stop.
The attackWhat it looks like from both sides
From the attacker's side it is a loop. Submit the stolen password, trigger a push, wait, submit again. There is no exploit and no malware. The only thing being attacked is a person's patience.
From the user's side it is a phone buzzing repeatedly, usually at night, usually with no explanation. Some attackers add a call or a message claiming to be the help desk, saying the prompts are a system error and asking the user to approve one so it stops. That version succeeds far more often than the silent one.
From the log side it is unmistakable in hindsight and easy to miss live: a long run of failed or expired multi factor challenges for one account, from an address nobody has used before, ending in one success.
The fixNumber matching, which costs nothing
Number matching changes the question. Instead of approve or deny, the sign in screen shows a two digit number and the phone asks the user to type it. An attacker who cannot see the sign in screen cannot supply the number, so approving by reflex stops being possible.
Every major identity provider supports it and most now default to it for new tenants. Older tenants frequently do not have it on, because it was introduced after they were built and nothing forced the change.
Turning it on is a policy setting, not a project. The user experience cost is one extra tap. Compared to every other authentication improvement, the ratio of protection to disruption here is unusual.
| Control | Stops MFA fatigue | Cost to roll out |
|---|---|---|
| Number matching | Yes | A policy setting |
| Showing app and location in the prompt | Helps | A policy setting |
| Limiting prompts per period | Yes | A policy setting |
| Passkeys or hardware keys | Yes, and phishing too | A real project |
| Blocking legacy authentication | Prevents the bypass | An audit, then a switch |
| Alerting on repeated denials | Detects it | One rule |
ReferenceWhere the setting lives
It is a policy setting in every platform below, and in most of them it is now the default for a tenant created recently. The tenants that need this article are the ones built before the option existed, where nothing ever forced the change.
| Platform | What it is called | Where to find it |
|---|---|---|
| Microsoft Entra ID | Require number matching for push notifications | Authentication methods, Microsoft Authenticator, Configure |
| Okta | Number challenge | Authenticators, Okta Verify, push settings |
| Duo | Verified Duo Push | Policy, Authentication methods |
| Google Workspace | Number matching in the Google prompt | Applied automatically to the Google prompt |
| Ping and ForgeRock | Number matching or number challenge | Per push authenticator configuration |
Two things are worth checking rather than assuming. Whether the policy applies to every group or only to the pilot group somebody scoped it to two years ago, and whether any application is still allowed to fall back to a plain push when number matching fails. A fallback path is the setting turned off for anyone who finds it.
The bypassThe path that skips the prompt entirely
Every control in this article assumes the attacker has to get past a multi factor prompt. There is a class of protocol where they do not.
Older mail and directory protocols were designed before second factors existed and have nowhere to put one. IMAP, POP, SMTP AUTH and the older Exchange and Office clients send a username and a password and expect an answer.
If the identity platform still accepts them, an attacker holding the password does not send a single push notification, because there is nothing to send it to. They read the mailbox directly.
That is why blocking legacy authentication sits in the table above. It is not an improvement on number matching, it closes the door that makes number matching irrelevant.
The work is an audit before a switch, and the audit is the part that takes time. Sign in logs record which accounts still authenticate this way, and the answers are usually a scanner on a copier, a line of business application with a hardcoded mailbox, and one person's phone that has not been set up again since 2019.
Each has a modern replacement and each needs finding before the block goes on, because the failure mode is silent: the device stops working and nobody reports it for a week.
Where a protocol genuinely cannot be replaced, the answer is a dedicated account with no interactive rights, a long random password, and a conditional access rule that restricts it to one address.
DetectionThe alert worth building
Repeated denials are the signature, and almost nobody alerts on them. A user who denies three multi factor prompts in ten minutes is telling you something, and in every identity platform that is a rule you can write in an afternoon.
Two refinements make it useful rather than noisy. Trigger on denials and expiries together, because an ignored prompt is as strong a signal as a rejected one. And raise the priority when the attempts come from an address or country the account has never used, which is almost always the case.
The response is simple and should be written down before it is needed: force a password reset, revoke the active sessions, and speak to the person. The password is already compromised, so leaving it in place while investigating just extends the window.
ResponseWhat a password reset does not do
If somebody approved a prompt, the attacker completed a sign in and holds what a completed sign in produces: a session, and usually a refresh token that can mint new access tokens for weeks without ever seeing another password or another prompt.
Resetting the password does not touch it. On its own, the attacker keeps working while the user changes their password and everyone believes the incident is closed.
Three actions end it, in this order. Revoke the sessions and refresh tokens for the account, which is one command or one button in every platform and is the step that actually evicts them. Then reset the password, so the loop that started this cannot start again.
Then look at what changed while they were in: a forwarding rule on the mailbox, a new inbox rule that files messages from finance somewhere quiet, an added authentication method, a registered device, an OAuth consent granted to an application nobody recognizes.
That last list is the point of the exercise. An attacker who reaches a mailbox for twenty minutes and leaves a forwarding rule behind has arranged to keep reading it after every credential in the account has been changed, and a rule is not a login, so nothing in the sign in logs will ever mention it again.
PeopleWhat to tell users, in one sentence
Security training on this topic tends toward a paragraph nobody remembers. The whole message fits in a sentence: if a prompt arrives when you are not signing in, deny it and tell somebody.
The second half matters more than the first. A denied prompt with no report is an attack that continues quietly until the attacker gets lucky. A denied prompt that gets reported is an incident that ends the same afternoon.
It also helps to tell people plainly that the help desk will never call and ask them to approve a prompt. That single fact removes the pretext the successful version of this attack depends on.
- Turn on number matching
The user types a two digit number from the sign in screen instead of tapping approve. An attacker who cannot see that screen cannot supply the number.
- Show the application and location in the prompt
A prompt that names what is being signed into and from where turns a reflex into a decision, and costs nothing to enable.
- Alert on three denials or expiries in ten minutes
This is the signature, and almost nobody watches for it. Raise the priority when the attempts come from an address the account has never used.
- Write the response down before you need it
Revoke the sessions and refresh tokens first, because that is what evicts an attacker who already signed in. Then reset the password, then check the mailbox for forwarding and inbox rules, added authentication methods and new OAuth consents.
The message for users, in full
Anything longer than this does not survive contact with a buzzing phone at two in the morning.
FAQQuestions from the comments
Is MFA fatigue a failure of MFA?
No. It is a failure of one factor type, the approve or deny push. Multi factor authentication with number matching, a code, or a hardware key is not vulnerable to it.
Does number matching stop phishing too?
No. A phishing proxy relays the whole sign in including the number. Only a hardware key or a passkey, which binds to the real site, stops that.
What if the identity provider does not support number matching?
Limit the prompts per period, switch that group to a code based method, and treat the platform limitation as a reason to plan a move.
Should a user who approved one be disciplined?
No, and doing it guarantees the next person hides it. The design put a person in an impossible position at two in the morning, and the design is what to fix.
How do attackers get the password in the first place?
Almost always a breach dump reused elsewhere, or an earlier phishing page. The password part of the attack finished months before the prompts started.
How do I find this in the sign in logs?
Look for a run of failures on one account with a strong authentication reason rather than a bad password, ending in one success.
In Entra the failure reason on a denied or expired prompt is 500121, and a column of those from one address followed by a single 0 is the whole attack in one screen. The address is almost always one the account has never used before.
Is a password reset enough after somebody approves one?
No, and it is the most common mistake in the response. A completed sign in leaves a session and usually a refresh token that keeps minting access for weeks without another password or another prompt. Revoke the sessions first, then reset the password, then look for what was left behind.
What should I look for in the mailbox afterwards?
Forwarding rules, inbox rules that move messages from finance or from the help desk somewhere quiet, newly added authentication methods, newly registered devices, and OAuth consents granted to applications nobody recognizes. A rule is not a login, so once it exists nothing in the sign in logs will mention it again.
Does limiting the number of prompts fix this on its own?
It helps and it is not the fix. A cap turns forty prompts into five, which reduces the odds of a tired approval without removing them, and it introduces its own failure where a genuine user is locked out at the wrong moment. It is worth having alongside number matching rather than instead of it.
We use conditional access. Does that cover it?
Only where the conditions happen to exclude the attacker. A rule that requires a compliant device or a known location does stop most of this, and a rule that requires multi factor authentication and nothing else does not, because the attack is a way of obtaining exactly that. Check what the policy actually demands rather than that one exists.
Should the help desk ever ask a user to approve a prompt?
Never, and it is worth making that a stated rule rather than a habit. The version of this attack that works involves a call claiming to be the help desk, and a policy of never asking removes the pretext entirely. It costs nothing, because there is no legitimate situation that requires it.