What Is MFA Fatigue—and Can Passkeys Stop Push-Bombing Attacks?

An unexpected sign-in approval on a phone is not harmless background noise. If it appears repeatedly, an attacker may be testing a stolen password and trying to turn the account owner's impatience, confusion, or muscle memory into the final authentication factor. The technique is called MFA fatigue, MFA bombing, push bombing, or push fatigue.

The attack exploits a workflow in which entering the correct password triggers a yes-or-no push notification on a registered device. Multi-factor authentication is still blocking the attacker—until the user approves. A single mistaken tap can transform failed password attempts into a valid session, which is why both the credential that starts the flow and the authentication method that finishes it matter.

Quick answer

MFA fatigue is a social-engineering attack that floods a user with authentication prompts until one is approved. The prompts often indicate that an attacker already has the account password, although some recovery flows can generate requests without it. Never approve a prompt you did not initiate. Deny it, open the service independently, change the password from a clean device, review sessions and recovery settings, and report the activity.

A passkey can stop this specific pressure point when it replaces the account's password-plus-push sign-in path. Instead of sending an approval request after a reusable password is entered, a passkey signs a fresh challenge for the legitimate website or app. Private key material remains under the authenticator or credential provider and is not sent to the relying service, which stores a public key; synced passkeys may be encrypted and copied across the user's trusted devices. There is no generic “Approve” prompt for an attacker to trigger merely by knowing a password.

That protection is only as complete as the account's remaining routes. If the provider still accepts a password followed by push MFA—or allows a weaker recovery method—an attacker may choose that fallback. A passkey does not stop unsolicited pushes from another account, revoke a session that is already stolen, or repair a compromised device. Treat passkey enrollment as one part of hardening the entire sign-in and recovery chain.

How an MFA push-bombing attack works

1. The attacker identifies an account. An email address or username may come from a breach, public profile, phishing campaign, or workplace directory.
2. The attacker reaches the MFA step. Commonly, that means a password was phished, reused from another breach, guessed, or stolen by malware. Some self-service recovery workflows can also generate challenges.
3. The identity provider sends a push. A phone displays an approval request because the provider sees a sign-in attempt that passed the first step.
4. The attacker repeats or adds pressure. Prompts may arrive back-to-back, late at night, or alongside a call pretending to be IT support. The goal is to make approval feel like the quickest way to end the disruption.
5. One approval can complete the attacker's session. If no additional conditional-access or step-up control intervenes, the attacker can then inspect data, register another authenticator, change recovery settings, create persistence, or target connected services.

MITRE ATT&CK tracks this behavior as Multi-Factor Authentication Request Generation (T1621). MITRE notes that attackers can repeatedly generate pushes, text messages, or calls and recommends stronger authentication methods, limits on the number of requests, location or device restrictions, monitoring, and user training. The key signal is not just a failed sign-in; it is a burst of challenges that does not correspond to an action the user initiated.

Push approval, number matching, TOTP, and passkeys are not equivalent

CISA's number-matching fact sheet recommends number matching when an organization cannot yet implement phishing-resistant MFA, while making clear that number matching is not as strong. Microsoft likewise identifies number matching as protection against accidental approvals in Microsoft Authenticator.

Number matching connects the phone prompt to the browser transaction. That is better than a context-free approval button, but it still asks the user to make the security decision. A caller posing as support may tell the victim which number to select. Rate limits, sign-in context, device compliance, risk policies, and help-desk verification procedures remain important.

Why passkeys change the attacker's problem

A passkey uses a public-private key pair scoped to a relying party—the website or app accepting the credential. The relying service stores the public key. Private credential material remains under the authenticator or credential provider, which produces a signature over a fresh challenge after the user authorizes its use. The legitimate service verifies the challenge, relying-party identity, origin, user-presence or user-verification signals, and signature.

NIST's current authenticator guidance explains that WebAuthn and FIDO2 can provide phishing resistance through verifier-name binding: the authenticator output is cryptographically bound to the authenticated service identifier. By contrast, manually entered OTP and out-of-band methods are not phishing-resistant because an impostor can relay their output.

The FIDO Alliance's passkey overview describes passkeys as FIDO credentials that can replace passwords and legacy password-plus-OTP flows. Google's passkey documentation further explains that the operating system and browser restrict a passkey to the website or app that created it, while the website stores only the public key.

This design removes two ingredients an MFA bomber usually depends on: a reusable password that can start repeated sign-ins and an approval prompt whose context the user must interpret. But a provider may offer multiple authentication policies at once. If “use password instead,” SMS recovery, push MFA, help-desk reset, or an old application password remains active, the attacker will probe that alternate route. Passkeys strengthen a route; account configuration determines whether weaker routes remain.

What to do when an unexpected MFA prompt appears

1. Deny it. Do not approve the prompt, enter a number shown by an unknown caller, or share a one-time code. If the app offers “report suspicious activity,” use it.
2. Do not follow links in the notification, email, or text. Open the provider's official app or type a known address from a trusted bookmark.
3. Change the password from a clean device. Generate a unique replacement that is not used anywhere else. If malware may be involved, clean or replace the affected device before trusting the new credential.
4. Review active sessions. Sign out unfamiliar devices and, for a serious incident, use the provider's option to sign out everywhere. A password change does not always revoke every session, token, or connected application.
5. Inspect authentication and recovery methods. Remove unknown phones, authenticators, passkeys, security keys, app passwords, recovery addresses, and trusted devices.
6. Check for account changes. Look for forwarding rules, delegated access, connected OAuth apps, new API tokens, modified payment details, and messages or files created by someone else.
7. Enroll a phishing-resistant method. Prefer a passkey or FIDO security key where supported. If push remains necessary, enable number matching, sign-in context, and rate limits where the provider or administrator offers them.
8. Regenerate recovery codes. Store the new codes through a protected path and invalidate the old set. Verify recovery before removing the last working authenticator.
9. Report the incident. Workplace accounts may require immediate security-team notification because one compromised identity can expose shared cloud resources.

NIST explicitly includes authentication fatigue in its authenticator threat model. Its out-of-band guidance also says verifiers sending push notifications should impose a reasonable rate or total limit since the last successful authentication. Those provider-side controls matter because an individual password manager cannot observe or throttle prompts generated inside a separate identity service.

Harden the whole account, including recovery

Start with the highest-impact identities: primary email, Apple or Google accounts, workplace single sign-on, financial services, telecom accounts, and any service that can reset other credentials. Use a different random password for every account that still needs one. Reuse turns a breach at one service into an attempted sign-in at many others, while a unique password contains the blast radius.

Enroll more than one strong authenticator when the provider permits it, but avoid creating an undocumented maze of fallbacks. Record which passkeys or hardware keys protect the account, where the recovery codes are stored, and which email address or phone number remains a recovery route. Keep a protected recovery copy available before removing the old method. The strongest everyday sign-in is not enough if the recovery desk can be socially engineered into bypassing it.

For managed organizations, technical controls should reduce the number of decisions users must make under pressure. Disable simple one-tap approval, require number matching during migration, restrict authentication from unexpected locations or unmanaged devices, monitor repeated challenges, and limit prompt frequency. Move high-risk roles to phishing-resistant credentials and train help-desk staff to treat “my MFA stopped working” as a possible takeover attempt rather than only a convenience issue.

Krypt's answer: replace reusable credentials and preserve recovery context

Krypt is a zero-knowledge password manager that keeps readable vault data out of a company-managed server. For sites and apps that support them, Krypt 2.0.0 Free can create, store, list, delete, and use third-party website passkeys through Android Credential Manager on Android 14+ and Apple Credential Provider extensions on iOS/iPadOS 17+ and macOS 14+.

When the website permits a passkey to replace password-plus-push authentication, using a Krypt-managed passkey removes the reusable password and blind push approval from that route. For accounts that still require passwords, Krypt can generate and keep a unique credential. It can also hold encrypted recovery codes, secure notes, and private account context so the user can document authenticators and recovery paths instead of leaving codes in screenshots, email drafts, or unencrypted notes.

Krypt does not control the identity provider. It cannot stop the provider from sending pushes, rate-limit authentication attempts, detect sign-ins on the provider's servers, revoke its sessions, or remove fallback methods. Krypt's built-in TOTP context does not itself use push approvals where a site accepts authenticator codes, but another push fallback may remain enabled. NIST does not classify manually entered OTP as phishing-resistant because it can be relayed. Prefer a passkey or FIDO2/WebAuthn security key where the provider supports one.

Krypt Pro's YubiKey unlock must not be confused with website authentication. On supported Android, iPhone, and macOS devices, it adds hardware proof to the process of unlocking the Krypt vault. It does not enroll the key with third-party websites, add MFA to those accounts, or block their push notifications. Website security keys are configured separately in each service's security settings. Krypt's YubiKey vault unlock is unavailable on iPad in the current release, while Krypt website passkeys are available through the supported iPadOS credential-provider path.

Finally, Krypt cannot recover a forgotten vault PIN from a server. Keep the Recovery Kit and Rescue Key through a separate protected path, and test the recovery plan before changing critical account authenticators. Strong authentication without usable recovery can turn device loss into permanent lockout; weak recovery can turn strong authentication into a detour.

Checklist: migrate away from push fatigue without locking yourself out

1. Inventory accounts that send yes-or-no push approvals, beginning with email and single sign-on.
2. Use the provider's official security page to review active sessions, enrolled authenticators, and recovery methods.
3. Create a passkey or enroll a FIDO security key if the provider supports it.
4. Test that credential in a separate browser or device before removing the old method.
5. Store new recovery codes in an encrypted vault and keep an independently protected recovery copy where appropriate.
6. Remove unknown authenticators, unused app passwords, and obsolete phone numbers.
7. Where push must remain, require number matching and sign-in context, and ask the administrator about prompt rate limits and risk policies.
8. Generate a unique random password for any fallback that cannot yet be removed.
9. Document the final sign-in and recovery routes so future device replacement does not require an emergency downgrade.

For more context on choosing phishing-resistant methods, read Do You Still Need a Password Manager if You Use Passkeys? and What Is a YubiKey, and How Does It Work?.

FAQ

What should I do if I receive an MFA prompt I did not request?

Deny the request and do not enter a displayed number or share a code. Open the provider through a trusted bookmark or its official app, change the password from a clean device, review active sessions and recovery methods, revoke unfamiliar access, and report the event. Repeated prompts usually mean someone knows the username and may already know the password.

Do passkeys completely stop MFA fatigue attacks?

Passkeys can remove the password-plus-push flow for an account when the provider lets the passkey replace that sign-in path. They do not stop push prompts for another account or for a password, recovery, or legacy fallback that remains enabled. Review and harden every remaining sign-in and recovery route.

Is number matching the same as phishing-resistant MFA?

No. Number matching makes a blind one-tap approval harder because the user must associate the prompt with a sign-in transaction, but CISA describes it as weaker than phishing-resistant MFA. Passkeys and other FIDO authenticators bind cryptographic authentication to the legitimate service instead of relying only on user judgment.

Does Krypt's YubiKey unlock protect my online accounts from push bombing?

No. Krypt Pro's YubiKey feature is an additional hardware proof for unlocking a Krypt vault on supported devices. It does not enroll that YubiKey as MFA on third-party websites, disable their push notifications, or approve their sign-ins. Configure website passkeys or security keys separately in each provider's security settings.

Technical references

MITRE ATT&CK documents MFA Request Generation (T1621), including push fatigue, detection, and mitigations. CISA's Implementing Number Matching in MFA Applications explains its role and limits. NIST SP 800-63B covers authentication-fatigue threats, out-of-band authenticators and phishing resistance. Microsoft documents number matching for Microsoft Authenticator. The FIDO Alliance provides its passkey overview, and Google explains passkey security and relying-party binding.

Use Krypt to replace reusable passwords with supported website passkeys, keep remaining credentials unique, and protect recovery codes and account context in an encrypted vault.