No malware, no exploit, just a working password and a lot of push notifications at three in the morning. Number matching helps. Passkeys end the attack class.
Multi-factor authentication is still the single highest-value security control most organisations can deploy, and nothing below changes that. But the common implementation, a push notification you approve on your phone, has a weakness that is behavioural rather than technical, and attackers have been exploiting it at scale for several years.
The attack
What makes this effective is that it does not require anything clever. The attacker already has a valid password, obtained from a reused credential, a phishing page or a breach dataset. MFA is the only thing standing between them and a session, and MFA, in the push-approval form, is a yes-or-no question asked of a human.
Ask a tired human the same yes-or-no question forty times at three in the morning and eventually one of them is answered wrong. That is the entire attack.
The variant worth knowing about adds a phone call. The attacker rings the user, introduces themselves as IT, says they are testing the new authentication system, and asks the person to approve the prompt they are about to receive. This version works on alert, well-rested people, because it supplies the missing context that makes the prompt make sense.
What actually stops it
Phishing-resistant authentication
Passkeys, FIDO2 security keys and certificate-based authentication share a property that makes this attack impossible rather than unlikely: there is no prompt to approve. Authentication is bound to the device and to the legitimate site, and an attacker on a different machine cannot generate anything for the user to accidentally accept.
This is the actual fix, and it is more deployable than it was two years ago. Passkeys are built into current versions of Windows, macOS, iOS and Android; most people are already carrying a capable authenticator.
Start with administrators. It is the smallest group, the highest value, and the group most able to cope with a change in how they sign in. Then extend to anyone with access to finance systems or client data.
Number matching
If you are not ready to move everyone to passkeys, number matching closes most of the gap and costs nothing. The sign-in screen displays a two-digit number and the user must type it into the authenticator rather than tapping approve.
An attacker who cannot see the victim's screen cannot supply the number, so accidental approval stops being possible. Microsoft now applies this by default in Entra ID, but it is worth verifying in your own tenant rather than assuming, particularly if your configuration predates the change.
Context in the prompt
Showing the application being accessed, the geographic location and the IP address converts a reflexive tap into a deliberate decision. Somebody half asleep is considerably more likely to pause at a prompt saying a sign-in is coming from another country.
Treat repeated prompts as an alert
Dozens of failed authentication attempts against one account in a short window is not a user having trouble. It is an attack in progress, and most platforms can alert on it. If they can, configure it. The alert arrives while the attack is still running, which is a rare luxury.
Tell people the two sentences
Security awareness training is frequently too long and too general. For this specific attack, two sentences delivered clearly do most of the work:
We will never call you and ask you to approve an authentication prompt. If somebody does, it is an attack, and hanging up is the correct response.
If you get prompts you did not ask for, your password is already compromised. Do not approve, do not ignore, report it, and change the password.
That second one matters because the natural reaction to unexpected prompts is annoyance rather than alarm. People dismiss them and move on, and the account stays compromised because nobody told IT.
If you think it has happened
Assume the password was already known and that the attacker may now have a session, which may survive a password change.
Revoke all active sessions for the account, not just the password. In Entra ID this is a specific action and it is the one people miss. Then reset the password, check for mailbox forwarding rules and inbox rules created recently, review the sign-in log for successful authentications from unfamiliar locations, and check whether any MFA methods were added, because registering a new authenticator is how attackers persist after the password changes.
That last check is the one most often skipped and the one that determines whether you have actually evicted them.
A reasonable sequence
This quarter: confirm number matching is on, enable alerting for repeated failed attempts, and send the two sentences to everybody.
Next quarter: move administrators to passkeys or security keys, and set an authentication strength requirement so that administrative access cannot fall back to push approval.
Over the following year: extend phishing-resistant authentication to everyone with access to money or client data, then to everyone else as devices and habits allow.
The first part costs an afternoon. The second removes the attack class for the accounts that matter most.
