Phishing defense guide

MFA Push Fatigue Attacks and Prompt Bombing

Attackers may already know the password and pressure the user to approve one prompt.

Security guideIndependent educational resource

Decision point

MFA Push Fatigue Attacks and Prompt Bombing matters when it changes who can sign in, recover access or approve a sensitive action. Start with those consequences before changing settings.

For MFA Push Fatigue Attacks and Prompt Bombing, this is a message-verification decision page. Its goal is to separate the claimed urgency from independently verified facts. Open the provider from a saved bookmark or known app instead of using the message link.

Why this matters

Attackers may already know the password and pressure the user to approve one prompt.

On this page
  • Priority decision
  • Recommended workflow
  • Verification checklist
  • Incident response
  • Common mistakes
  • Frequently asked questions

Priority decision

Deny the request, secure the account independently and report the event.

Advertisement

Recommended workflow

  1. Deny the request, secure the account independently and report the event.
  2. Identify the legitimate owner, backup owner and provider-controlled recovery route.
  3. Use a trusted device and open the provider independently.
  4. Replace reused credentials and remove access that no longer has a current owner.
  5. Enable the strongest reliable authentication method and protect its fallback.
  6. Test recovery before removing an existing working method.
  7. Record completion and review triggers without storing secret values.

Verification checklist

AreaEvidenceReview trigger
OwnershipNamed owner and backup owner are currentRole, family or vendor change
CredentialUnique entry in a trusted password managerReuse, breach or suspected exposure
AuthenticationPrimary and backup method testedNew device or provider change
RecoveryContacts and codes are protected and currentPhone, email or relationship change
Sessions/accessUnknown devices, apps and roles removedAlert, departure or shared-device use

Common mistakes

  • Sharing the password instead of using named accounts, roles or delegation.
  • Removing the only working authenticator before testing recovery.
  • Trusting a phone number, link or QR code supplied by the suspicious message.
  • Changing one password while leaving reused copies active elsewhere.
  • Keeping passwords, backup codes or private keys inside an inventory or checklist.

Frequently asked questions

Can Password Tools Hub access or inspect an account?

No. The site provides independent educational content and local planning tools.

Should passwords be changed on a fixed schedule?
Which account should be protected first?

Usually the primary email, password manager or administrator identity that can reset other services.

Is MFA enough when a password is reused?

No. Replace reused credentials and enable strong authentication; the controls address different risks.

What belongs in an account inventory?

Provider, purpose, owner, backup owner, recovery route and review trigger—not the password or recovery code.

Related planning tools

Use the breach response prioritizer, session revocation checklist and incident report template.

Technical reference points

Standards and source notes

This page is maintained by the Password Tools Hub Editorial Team. General password guidance is checked against NIST SP 800-63B and the OWASP Authentication Cheat Sheet. Product interfaces can change; use the linked provider documentation for the final account action.

Apply MFA Push Fatigue Attacks and Prompt Bombing to a real account

For MFA Push Fatigue Attacks and Prompt Bombing, write down the account owner, recovery email, trusted devices and the action that would cause the greatest damage. Then use the guidance above to reduce that specific risk. A generic “secure” status is less useful than knowing who can recover the account and how unauthorized access would be detected.

Verification before you finish

  1. Confirm the change from a trusted device.
  2. Test the new sign-in or recovery method.
  3. Check that an old session or fallback has not been left active unintentionally.
  4. Store recovery information away from the primary device.
  5. Record the next review owner if the account is shared or business-critical.