MFA fatigue is an account incident, not a notification problem

01 · decision point

Treat repeated prompts as evidence the first factor may be known

A push request normally follows a sign-in attempt. When prompts arrive without an action you started, someone may already know the username and password or may be testing another active session. CISA describes push bombing as repeated notifications intended to cause an accidental or frustrated approval. Silencing the phone stops the interruption but does not remove the attacker's knowledge or invalidate a session they may already control.

Capture the time, service name, displayed location, device, and any number shown without sharing a live code. Deny the request if the interface offers that choice, then stop interacting with the notification. Do not accept a follow-up call claiming to be the help desk. An attacker can create the prompts and call immediately to make the activity look like a coordinated support process.

02 · decision point

Contain the account from an independently opened route

Use a trusted device or known bookmark to open the real service. Change a reused password, inspect recent sessions, sign out unfamiliar devices, and review registered phones, authenticators, security keys, passkeys, recovery email, and forwarding rules. For a work or school account, contact the authorized security or identity team through a known internal channel. Administrators may have logs and revocation controls the user cannot access.

Start with the identity that can reset other accounts: primary email, password manager, single sign-on, and administrator accounts. If the same password was reused, replace it everywhere with unique values. Preserve evidence before removing unfamiliar methods when the organization may need an investigation. A successful denial means that one request failed; it does not prove the password remains private or that another prompt will not follow.

03 · decision point

Understand what number matching changes

Number matching requires the user to enter or select a value shown in the sign-in session, which makes blind approval harder. Microsoft's current Entra documentation describes it as a security improvement for Authenticator push notifications and says it is enabled for those notifications. CISA recommends number matching when an organization cannot yet implement phishing-resistant MFA. These controls reduce accidental approvals but remain dependent on user intent and the integrity of the sign-in context.

A convincing fake page can relay a legitimate sign-in and show the same number, so matching does not create the domain binding of a passkey or FIDO security key. Always ask whether you initiated the sign-in and whether the browser is on the verified service. If no action was started, reject the request regardless of location accuracy, familiar device name, help-desk story, or matching digits.

04 · decision point

Move high-impact accounts toward phishing-resistant methods

Passkeys and FIDO security keys are bound to the legitimate relying-party domain, which can prevent a copied page from using the credential for another site. Register at least two independent authenticators where supported, and keep recovery codes in protected offline storage. Avoid making one phone the only holder of push approvals, synced passkeys, email, and recovery messages for the same critical account.

Organizations should combine stronger methods with rate limits, risky-sign-in detection, user reporting, and a rehearsed response process. Training alone cannot compensate for an endless approval stream. Users need a clear way to report fraud, administrators need authority to revoke sessions and methods, and incident notes should record whether the password, recovery channel, or device was also compromised.

Practical sequence

Respond to an unexpected approval request

1. 01

   Deny the prompt and do not engage with a caller or message that references it.

2. 02

   Record non-secret details such as time, service, location, and device label.

3. 03

   Open the real service independently and replace the password from a trusted device.

4. 04

   End unfamiliar sessions and review every registered authentication and recovery method.

5. 05

   Report a managed account through the organization's known security channel.

6. 06

   Register a phishing-resistant method and an independent backup after containment.

Original research element

Triage the prompt by what happened before it

This original response matrix separates normal friction from an active credential incident.

Continue on login.com

Related independent guidance

• Prepare a managed-device replacement before prompts fail
• Migrate Microsoft Authenticator without losing the trusted session
• Map the accounts an attacker could use for recovery
• Understand why live verification values must not be shared