MFA fatigue, MFA bypass, and the reset desk: three ways MFA actually fails

Multi-factor authentication is bypassed in three distinct ways, each needing a different answer. Attackers exhaust the user with repeated prompts until one is approved, steal an already-authenticated session so no factor is ever challenged, or ask a help desk to reset the factor and issue a new one. Phishing-resistant MFA closes the first two. Nothing in the authentication stack closes the third.

The third is the one to plan around, because organizations that have done the hard work of deploying phishing-resistant MFA often still have the reset path wide open.

One: MFA fatigue, also called push bombing

The attacker already holds a valid password, usually from a breach or a phishing page. What they lack is the second factor. So they authenticate repeatedly, generating a stream of push notifications to the legitimate user’s phone, and wait.

CISA documents the technique in its advisory on Scattered Spider: the group “sent repeated MFA notification prompts leading to employees pressing the ‘Accept’ button (also known as MFA fatigue)” (CISA, advisory AA23-320A).

It works because approving is one tap and investigating is not, and because a person woken at 2am, or mid-meeting, will often clear the notification simply to stop it. Frequently the prompts are paired with a call from “IT” explaining that the alerts are a known glitch and asking the user to approve one so the ticket can be closed.

What closes it: number matching, which requires the user to type a digit shown on the sign-in screen rather than tapping approve; limiting or throttling repeated prompts; and alerting on prompt volume. Passwordless and phishing-resistant methods remove the prompt entirely.

What does not close it: telling users to be careful. The prompt arrives at a moment of the attacker’s choosing, and the user has no information the attacker does not also have.

Two: MFA bypass through session theft

This one defeats correctly implemented MFA without ever breaking a factor.

The attacker puts a proxy between the user and the real login page. The user enters their password on what looks like the genuine site, receives a real MFA challenge from the real service, and satisfies it. The proxy relays every step, and at the end captures the session token the service issues. The attacker replays that token and is inside, authenticated, without possessing the password or the second factor.

This is adversary-in-the-middle phishing, and it is why security teams sometimes investigate an intrusion where the logs show a clean login, MFA satisfied, session legitimately issued, and the wrong person with access. Trusona has covered the mechanics in detail in vishing and real-time phishing kits.

What closes it: phishing-resistant MFA. Passkeys and FIDO2 security keys bind the credential to the origin, so a credential registered for your real domain simply will not produce a valid response for the attacker’s proxy domain. This is a genuine structural fix rather than a mitigation, and it is the reason phishing-resistant MFA is worth the deployment cost.

What does not close it: one-time passcodes of any kind, whether by SMS, email, or authenticator app. If a code can be read aloud or typed into a page, it can be relayed. Push approval has the same weakness.

Three: the reset desk, which is the bypass nobody patches

Here the attacker does not attack the factor at all. They call the IT help desk as an employee who cannot get in, and ask for the factor to be reset or moved.

CISA records the group conducting “spearphising [sic] calls to convince IT help desk personnel to reset passwords and/or transfer MFA tokens,” and, in its July 2025 update, posing as employees “to convince IT and/or helpdesk staff to provide sensitive information, reset the employee’s password, and transfer the employee’s MFA to a device they control” (CISA, advisory AA23-320A). MITRE tracks the technique as Impersonation (T1656).

Phishing-resistant MFA reaches its limit here. A passkey is bound to the origin, so it cannot be phished, and it can still be deleted and re-enrolled by an administrator, because it has to be. People lose devices. The recovery path exists by design, in every platform, and it is the softest part of an otherwise hard control.

Mandiant found voice phishing involved in 11% of all intrusions, and 23% of cloud intrusions, where it ranked first (Mandiant, M-Trends 2026). Google Threat Intelligence tracked UNC6671 targeting financial services with spoofed help desk numbers, tracing $10.69 million in ransoms (Google Threat Intelligence, August 2026).

And the pretext is unfalsifiable by design. The caller’s claim is that they cannot use their authentication, which means every method you would normally verify them with is, by their account, unavailable.

What does not close it: any control that lives inside the authentication system. The request is arriving outside it, addressed to a person.

Why the three are worth separating

Because the standard security program treats “MFA” as a single control and reports on its coverage as a single number, and that number conceals which of the three you have actually addressed.

An organization can be fully deployed on passkeys, report excellent phishing-resistance coverage, and still lose an account to a phone call. The credential got stronger while the path around it stayed exactly where it was.

How to tell which one hit you

The three failure modes leave different traces, and the response differs, so it is worth being able to distinguish them from the logs.

Prompt fatigue leaves a burst of denied or unanswered authentication attempts against one account, followed by a single approval. The password was already valid, so the failures are second-factor failures rather than password failures. If you are not alerting on prompt volume per account per hour, this pattern is present in your logs and nobody is reading it.

Session theft leaves almost nothing at the authentication layer, which is the tell. One clean sign-in, MFA satisfied, no repeated attempts. The divergence appears afterwards: a session used from an IP or device that does not match the sign-in, or a session that remains active while the user authenticates separately somewhere else. Where the sign-in looks perfect and the aftermath does not, look for a proxy rather than a stolen password.

The reset desk leaves an administrative event rather than an authentication one, and it is usually in a different system. A help desk ticket, a credential reset, an authenticator deleted and re-enrolled, often minutes apart, and correctly performed by a real employee. Correlating ticketing records against authentication-method changes is the check that surfaces it, and it is rarely built.

The reason to separate them is that each demands a different fix. Prompt fatigue needs number matching. Session theft needs origin-bound credentials. The reset desk needs identity verification in front of a human decision, and the first two controls do nothing for it.

Closing the third one

The reset path cannot be fixed with a better factor, because the whole premise is that the factor is unavailable. It is closed by verifying the human before the reset happens.

That means checking the person against something they do not control. A government-issued ID verified against the authority that issued it — in the US, state DMV records over the AAMVA network — tests a record the caller cannot influence, unlike a voice, a knowledge answer, or a code. SIM swap and port-out detection surfaces a number that recently changed hands, which is the strongest single signal on a reset call, and CISA lists SIM swap among these groups’ core techniques. Man-in-the-middle and anti-replay detection confirm the session is live and direct rather than relayed; Trusona’s implementation is patented (US Pat. 10,601,859).

Four operational points decide whether it holds:

Verify before clearing the factor, not after. Once the enrolment is deleted, the registration window is open and whoever completes it next controls the account.

It has to work with no pre-registration. The caller’s stated situation is that they cannot use anything they enrolled. A verification method that depends on an enrolled factor cannot serve the population that reaches your agents.

Revoke sessions when the reset follows suspicion. A new factor on an account an attacker already occupies changes nothing.

Measure the override rate. Every process has an exception path. If agents can be talked through it under pressure, your coverage is whatever fraction of calls nobody pushed on.

The per-platform reset procedures, and where the identity decision sits in each, are covered in how to reset MFA safely.

ATO Protect runs that check in front of the reset: a government ID verified against its issuing authority in real time, with SIM swap detection and patented man-in-the-middle and anti-replay detection, no pre-registration, no app download, and no selfie or liveness challenge. See ATO Protect use cases and ATO Protect for IT Help Desk.

Frequently asked questions

What is an MFA bypass attack? Any attack that obtains access to an account protected by multi-factor authentication without legitimately satisfying the factor. The three main forms are prompt fatigue, session theft through an adversary-in-the-middle proxy, and social engineering a help desk into resetting or transferring the factor.

What is an MFA fatigue attack? An attacker who already has a valid password authenticates repeatedly, generating a stream of push notifications until the user approves one to stop the interruptions. CISA documents the technique, also called push bombing, in advisory AA23-320A. Number matching and prompt throttling are the standard mitigations.

What is phishing-resistant MFA? Authentication whose credential is cryptographically bound to the legitimate site’s origin, such as passkeys and FIDO2 security keys. Because the credential will not produce a valid response for an attacker’s lookalike domain, it cannot be relayed through a proxy, and there is no code to read aloud.

Does phishing-resistant MFA stop all MFA bypass? No. It closes prompt fatigue and session theft, which are the two attacks against the credential itself. It does not close the account recovery path, because any authenticator can be deleted and re-enrolled by an administrator when a user loses their device, and that path is reached by contacting a person rather than by attacking the credential.

How do attackers bypass MFA without stealing a password? By capturing an authenticated session token through a real-time phishing proxy, or by persuading a help desk to reset the factor and issue a new one to a device they control. Neither requires knowing the password.

Why is the help desk considered an MFA bypass? Because the help desk can reset a password and rebind MFA through conversation alone. An attacker who reaches it does not need to defeat the second factor; they ask for it to be reissued. CISA documents this as a core technique.

How do you protect the MFA reset process? Verify the person’s identity before the factor is cleared, against a source they do not control, using a method that works for someone with no usable enrolled factor. Then revoke existing sessions when the reset follows suspected compromise, and measure how often agents bypass the verification step.

Deploying phishing-resistant MFA is the right call and it hardens two of the three doors. The third one is opened by asking politely, and no authenticator can close it.