One tap, worn down over an evening
Push approval is the method everyone likes. A prompt appears, you tap approve, you are in. Nothing to read, nothing to type. That convenience is the entire vulnerability.
The attack needs no exploit. Somebody already holds a valid password — phished, reused, bought. What they do not hold is the phone. So they sign in, which sends a prompt. The user ignores it. They sign in again. And again. At dinner, in a meeting, at two in the morning. Eventually one of two things happens: the user approves to make it stop, or they assume IT is doing something and approve to be helpful.
That single tap is the whole attack. It has worked against organisations with serious security programmes, because it does not defeat MFA technically. It defeats the person holding the phone.
This isn’t carelessness. It’s an attack built around the one moment a tired person stops reading.
What the flood means before anyone taps anything
Here is the part that usually goes unread. To send a prompt at all, the attacker had to get past the first factor.
A stream of approval requests against one account is not a glitch and not a broken client. It is somebody with a working password, hammering the only thing still in their way. The attack and the warning are the same event — if anybody is looking at prompts rather than at approvals.
The shape is specific enough to build a rule on: many prompts to one account in a short window, few or none approved. The same sequence ending in an approval is an attack that succeeded. The same sequence with no approval is one still in progress.
Number matching takes away the reflex
The weakness of push is that approval costs nothing — a tap given without a decision behind it.
Number matching puts something in the way. The sign-in screen displays a number, and the phone asks for it. Somebody who is not looking at the sign-in screen has nothing to enter, so a prompt the user did not start becomes a dead end rather than a coin toss. Approving by accident stops being possible, because approving now requires an action taken on purpose.
It applies to web and federated sign-ins. The cap below applies everywhere.
The prompts are capped
The attack is arithmetic: enough attempts, and one lands. So the defence is to remove the arithmetic.
Mirket rate-limits repeated push notifications to one account, which means the volume an attacker needs in order to wear somebody down never accumulates. The cap is on prompts, not on the person’s ability to authenticate — methods the user initiates themselves, like a code generated in the app, are produced locally and cannot be triggered from outside at all.
This is the part that matters most: the control is the cap, not the user’s stamina. It holds at two in the morning, in a meeting, and on the fortieth prompt, because none of those conditions apply to it.
- Available on either deployment Rate limiting and number matching are part of Mirket MFA. They work whether the platform runs on your own servers or as a service — you do not need the detection layer to be protected from this attack.
- Selectable, like the rest of the policy The cap is policy, written the same way every other Mirket rule is written, in the same console, per surface rather than as one global switch.
Reading the pattern, where ITDR is running
Capping the prompts stops the attack. It does not answer the other question the flood raises, which is what to do about a password somebody else clearly has.
Mirket ITDR reads the burst as a detection in its own right. It belongs to the volumetric family — rules that fire on shape and count rather than on judgement, with a threshold instead of an opinion — alongside repeated consecutive failures against one account and a success arriving immediately after a run of them.
The response is automatic and scoped to that account: isolate it, force the password to change, or require a stronger method on the next attempt. Which one fires depends on how serious and how certain the detection is; Adaptive Authentication covers how that pair is used.
This layer needs the workforce modules running as a service, because the detection engine has to be able to read the sign-ins. The protection above does not.
The methods that cannot be flooded
Push is worth defending rather than abandoning — it is the method people actually like, and adoption is a security property. But it is worth knowing which methods have no flood surface at all, because they are the right answer for the populations most likely to be targeted.
| A code from the app | Generated on the phone, on the clock, with nothing sent from outside. There is no prompt for anyone to trigger |
| A hardware token | The same property in a device with no network at all |
| FIDO2 and WebAuthn | In the browser, the authenticator is invoked by the sign-in the user started. Nothing arrives uninvited — see Passwordless Authentication |
A privileged population moved onto a user-initiated method is a population this attack cannot reach, whatever anybody taps.
What changes with Mirket
| Before | With Mirket |
|---|---|
| Approve is a single blind tap | A number has to be read from the screen and typed on the phone |
| An account can be prompted without limit | Repeated prompts are rate-limited |
| A flood of prompts looks like a broken client | The burst is a detection with a threshold behind it |
| The defence is asking users to stay alert | The defence is the cap, which holds when alertness doesn’t |
| A run of denials sits in a log | It can trigger isolation, a forced reset or a stronger requirement |
| Protection depends on buying a detection product | Rate limiting and number matching come with MFA, on either deployment |
Frequently asked questions
What is an MFA fatigue attack?
Somebody who already has a valid password signs in over and over, sending an approval prompt to the real user's phone each time, until the user taps approve — to stop the buzzing, or because they assume IT is doing something. It is also called push bombing or MFA bombing. It defeats no cryptography; it defeats a tired person.
How does Mirket stop push bombing?
Two controls that work together. Repeated prompts to one account are rate-limited, so the volume the attack depends on never accumulates. And number matching replaces the single tap with a number that has to be read off the sign-in screen and typed into the phone — so a prompt the user did not start has nothing to type against.
Does this need ITDR?
No, and this is worth being clear about. Rate limiting and number matching are part of Mirket MFA and work on either deployment, on your own servers or as a service. Mirket ITDR adds a further layer — reading the flood as a signal about the password and responding automatically — and that layer needs the workforce modules running as a service.
What is number matching?
Instead of an approve button, the sign-in screen displays a number and the phone asks the user to enter it. Somebody who is not looking at the sign-in screen cannot supply it, which turns a reflex into an action that requires attention. It applies to web and federated sign-ins.
Doesn't rate limiting just lock out the real user?
The cap is on prompts, not on authentication. A user who genuinely needs to sign in during a flood still has methods available that no attacker can trigger from outside — a code generated on their own phone, for example, which is produced locally rather than pushed. The attack relies on being able to generate unlimited prompts; the defence removes that, not the user's ability to work.
What does a push flood mean about the password?
That somebody is able to start the sign-in at all, which means they have got past the first factor. It is one of the clearer indications that a password is no longer private, particularly when the prompts arrive in a burst with no approval among them. Account Takeover & Compromised Credential Detection covers what to do about the password itself.
Can Mirket respond automatically to a fatigue pattern?
Where ITDR is running, yes — the account can be isolated, the password can be forced to change, or the next attempt can be met with a stronger requirement. Which one fires depends on how serious and how certain the detection is, rather than on a single threshold.
Is a denied prompt worth paying attention to?
A single one usually isn't — people dismiss prompts by accident. A run of them on one account is different: that is a person actively refusing something they did not start, and it is a signal that should reach somebody rather than accumulate in a log.
Which methods can't be flooded at all?
Anything the user initiates rather than receives. A code generated in the app, a hardware token, or a FIDO2 authenticator in the browser produce nothing to spam — there is no prompt for an attacker to trigger. Push remains the method people like most, which is why it is worth defending rather than abandoning.
Does number matching apply to Windows and Linux logon?
Number matching applies to web and federated sign-ins. At an operating-system logon screen the rate limiting still applies, and the methods available there — a code from the app, a hardware token — are user-initiated and so cannot be flooded in the first place.
Is training part of the answer?
It helps, and it is not a control. Advice to refuse prompts you did not start is correct advice that fails at two in the morning, which is when the attack is run. A defence that depends on alertness fails in exactly the conditions the attack is designed to create.
Related
Solutions — Account Takeover & Compromised Credential Detection · User Behaviour Analytics & Identity Deception · Adaptive Authentication · Passwordless Authentication
Products — Multi-Factor Authentication · Identity Threat Detection & Response