MFA prompt bombing: the second factor fails at the human edge

The Hacker News framed the issue on May 26, 2026 in a way identity teams should take seriously: MFA is not the same thing as resilient MFA. The second factor was supposed to close the hole left by stolen passwords. If an attacker has the username and password, they still need another approval. In theory, that logic is solid. In practice, the attacker can stop trying to steal the factor and start attacking the user's reflex.

MFA prompt bombing does exactly that. Once credentials are compromised, the attacker starts a sign-in and pushes repeated approval requests to the user. The user sees phone notifications, often without enough clear context, and after enough interruptions may approve one simply to make the noise stop. This is not a cryptographic breakthrough. It is a design failure where a security decision becomes a repeated workplace interruption.

That is why “MFA is enabled” is not a sufficient answer. CISA has been pushing phishing-resistant MFA because a basic push approval without stronger binding to the login session cannot handle every attack path. If the user cannot clearly see where the request came from, which device is signing in, or whether a number must match the real session, the second factor becomes a human gamble: will someone press the wrong button today?

The better defense starts with admitting that MFA is a spectrum, not a single control. At the weaker end are push approvals that ask for a simple tap. Stronger versions add number matching, login context, rate limits, and risk signals. The most resilient approaches rely on device-bound, key-based, or cryptographic challenge mechanisms, the direction reflected in the NIST digital identity guidelines.

For administrators, this is an operational problem, not just a training slide. The system should detect unusual bursts of MFA prompts, suspicious login context, and attempts that depend on user fatigue. The user needs an easy way to report a suspicious prompt, and the security team should treat that report as a possible credential compromise. If the only instruction is “do not click,” the design has already pushed too much risk onto a person under pressure.

Microsoft's documentation on authentication methods shows how different these controls really are: SMS, app push, temporary passcodes, FIDO2 keys, and certificates do not provide the same level of defense. Organizations that deployed MFA only to satisfy a checkbox now need to inspect the configuration. The question is no longer whether the account has a second factor. The question is whether an attacker can turn that second factor into spam until the user gives in.