MFA push bombing attacks turn a security control into a nuisance: an attacker sends repeated approval prompts until a tired or distracted employee accepts one. This 2026 guide shows how to train staff to stop MFA fatigue attacks quickly and report them with useful detail.
TL;DR
- MFA push bombing is repeated unsolicited sign-in prompts designed to force one accidental approval.
- The correct response in 2026 is deny, stop interacting, report and verify through a known route.
- Number matching and phishing-resistant authentication reduce risk, but staff training still matters.
- Cyber Aware phishing simulations let teams rehearse pressure tactics without using real accounts.
Why this matters
Multi-factor authentication blocks many account-takeover attempts, but it depends on a person recognising whether they initiated the sign-in. Push bombing attacks exploit late-night alerts, busy workdays and the temptation to make notifications stop.
MFA fatigue push bombing staff training must teach a simple rule: never approve a prompt that was not started by the employee. Start with awareness training so the whole team understands that a denied prompt is valuable information, not an inconvenience.
In 2026, Cyber Aware security awareness training should pair that rule with a realistic drill. Staff need to identify the prompt, stop engaging and report it before an attacker finds a moment of confusion.
What you'll need
- 20 minutes for the lesson and 10 minutes for the response drill.
- Screenshots or approved test examples of push, number-matching and passkey sign-ins.
- The organisation’s exact route for reporting suspicious authentication prompts.
- A known contact route for verifying an unusual access request.
- A short incident template including time, device and application.
- A list of approved authentication methods used by the organisation.
Never run training that asks staff to approve a real unexpected sign-in. Use a test environment or screenshots.
Step 1: Define an unsolicited prompt
Explain that an authentication prompt is expected only after the employee starts a sign-in or a known action, such as changing a password. A prompt that arrives without that action is unsolicited, even if it displays a familiar company name.
Show two examples: a sign-in prompt immediately after a deliberate login and a prompt that arrives while the employee is not signing in. The difference is context, not the appearance of the notification.
Expected outcome: Staff can say whether a prompt was expected before they touch it.
Common mistake: Assuming an urgent prompt must be an IT request.
Step 2: Teach the four-action response
Give staff a fixed sequence for 2026: deny the prompt if a deny option is present; stop interacting with further prompts; report the event; verify any claimed IT request through a known channel.
Do not make staff improvise. A short printed rule near the reporting route reduces the chance that someone accepts one prompt just to end the notifications.
Expected outcome: Staff can state the four actions in order.
Common mistake: Repeatedly tapping deny without reporting the pattern.
Step 3: Explain number matching and context
Number matching requires a person to enter or select a number shown during a sign-in. It creates more friction than a simple approve button, but it is not permission to approve a sign-in the employee did not initiate.
Teach staff to compare the application, device and location details only after they confirm that they began the sign-in. An attacker can still use a phone call, chat message or fake support request to pressure someone into matching a number.
Expected outcome: Staff know that number matching verifies intent, not a vague instruction from another person.
Common mistake: Entering a number because a caller says they are from IT.
Step 4: Rehearse a pressure scenario
Run a two-minute role-play. A staff member receives three prompts while a simulated colleague sends a chat message claiming a shared file requires immediate approval. The learner states the four-action response and uses the known reporting route.
Phishing simulations can reinforce adjacent social-engineering cues: urgency, authority and a request to bypass normal verification. Cyber Aware should vary the scenario across 2026 so it does not become predictable.
Expected outcome: Staff refuse an unexpected prompt even when an urgent message accompanies it.
Common mistake: Making the simulation so obvious that the lesson never tests pressure.
Step 5: Teach out-of-band verification
If someone claims a prompt is legitimate, staff should verify it through a known phone number, service desk portal or internal directory. They should not use a link, phone number or chat thread supplied by the suspicious message.
This check should take less than 2 minutes. It is faster than recovering a compromised administrator, email or finance account.
Expected outcome: Staff can name a trusted verification path.
Common mistake: Replying to the suspicious caller or chat message to confirm identity.
Step 6: Capture useful report details
A useful MFA fatigue report contains the time, application name, device, number of prompts and whether anything was approved. It does not require the employee to investigate a sign-in log or confront a suspected attacker.
Make reports easy. Cyber Aware human risk reporting can show which users need a refresher without turning an authentication event into public blame.
Expected outcome: Security receives enough detail to investigate within 2 minutes of the report.
Common mistake: Waiting until the next day because no prompt was approved.
Step 7: Target the follow-up
Review which teams receive the most prompt-related support requests, but do not assume a high-volume group is careless. They may have more access changes, travel or application logins.
Use human risk reporting to target practical follow-up based on reported events, overdue learning and simulation behaviour. Cyber Aware security awareness training should reinforce the four-action response after a safe practice event.
Expected outcome: Refresher content reaches people who need it without blanket messages.
Common mistake: Treating every denied prompt as proof the account is safe.
Troubleshooting
A prompt arrives after a deliberate sign-in
Confirm the application and device match the action just started. If details differ, deny it and report the event.
There is no deny button
Dismiss the prompt, do not approve it, stop interacting and report it through the known route.
A caller says IT needs an approval now
End the call and contact IT through the service desk or directory. Do not use a phone number supplied by the caller.
An approval was accepted by mistake
Report it immediately, change the account password if instructed and follow the incident response process. Fast reporting limits the attacker’s window.
Tools and resources
- A four-action MFA prompt card: deny, stop, report, verify.
- A two-minute role-play involving prompts and a fake support message.
- A report template that records time, application, device and prompt count.
- Cyber security gap assessment for mapping authentication training and incident-response evidence to wider controls.
What to do next
Run one no-fault MFA fatigue drill in the next 30 days, then measure whether staff can report an unexpected prompt within 2 minutes. Use the result to set the next Cyber Aware training reminder.
FAQ
What is MFA push bombing?
MFA push bombing is an attack in which someone sends repeated authentication prompts hoping a user approves one accidentally. It is also called MFA fatigue or push fatigue.
Should staff deny an MFA prompt they did not initiate?
Yes. Staff should deny or dismiss an unexpected prompt, stop interacting and report it immediately through the approved route.
Does number matching stop MFA fatigue attacks?
Number matching adds friction and helps reduce accidental approvals, but staff must still reject prompts they did not initiate. A scammer can pressure a user to enter a number.
What should staff include in an MFA prompt report?
Include the time, application, device, number of prompts and whether anything was approved. That is enough for security to begin an investigation.
What if a staff member approved a prompt by mistake?
They should report it immediately and follow the account-recovery process. Quick reporting is more important than trying to solve the issue alone.
How often should MFA fatigue training run?
Run a short practice scenario at least twice a year and after any authentication-method change. Reinforce the four-action response in 2026.
One last thing
A denied prompt is not a failed security event. It is an early warning that gives the organisation a chance to investigate before an account takeover succeeds.