MFA fatigue, also called push bombing, uses repeated authentication requests to pressure someone into approving a sign-in. Treat a prompt you did not initiate as something to investigate. The notification alone does not prove how an attacker reached the sign-in step or whether an account has been accessed.
If a prompt arrives unexpectedly
- Deny the request. Do not approve it to stop the notifications, and do not share an approval number with someone who calls or messages you.
- Contact your IT team through a known support channel. A message arriving alongside the prompts may itself be part of the attempt.
- Record the account, approximate time and whether you approved anything. Share the relevant details through the approved support process; do not send passwords, recovery codes or private keys.
If you approved an unfamiliar request, report that immediately. Give the responder the facts you know, including whether you also entered a password into an unfamiliar page. A prompt that has stopped still deserves follow-up.
Number matching and phishing-resistant MFA address different risks
Number matching makes approval more deliberate by connecting it to a number in the sign-in experience. It reduces accidental approval under a stream of simple yes/no prompts. It does not make a user immune to a convincing caller or a fraudulent sign-in workflow. CISA recommends phishing-resistant MFA and identifies number matching as an interim improvement when a transition is still being planned. See CISA’s MFA guidance announcement.
For Microsoft Authenticator, number matching is enabled for push notifications, but the experience can differ for a sign-in initiated on the same phone. Check the actual applications and authentication paths in use, especially older integrations. Microsoft’s number-matching documentation explains the supported scenarios.
Phishing-resistant options such as FIDO2 security keys and suitable passkey deployments bind authentication to the intended service. Selection still needs an account-recovery plan, supported devices and a process for replacing a lost authenticator. Test ordinary sign-in and recovery with a small approved group before a wider rollout.
What the IT response should establish
An authorized administrator should investigate sign-in and audit records, distinguish attempted access from successful sessions, and review the affected account’s authentication methods and permissions. Depending on the findings, containment may include blocking sign-in, revoking sessions and resetting credentials. Review suspicious mailbox forwarding or rules when email is involved. A password change alone does not establish that the account is clean. Microsoft’s compromised-account response guide provides a detailed administrative workflow.
Keep investigation and business decisions connected. Identify who can approve a disruptive containment action, how the employee will regain access, and who will confirm that essential work is restored. Retain the investigation record in the organization’s established incident process.
Make the next security review concrete
- List the applications and users still relying on approval prompts, including administrative and recovery accounts.
- Check which authentication methods are actually enforced and where exceptions exist.
- Identify who receives reports of unusual prompts and how those reports reach someone authorized to act.
- Test a reporting exercise and a legitimate account-recovery scenario without exposing live credentials.
Root’s managed cybersecurity services connect identity and endpoint controls with investigation responsibilities. The employee helpdesk service provides the related discussion about reporting and escalation. An engagement review should verify your configuration; a plan name does not establish which control is enabled in a particular environment.