MFA bypass is any attack that gets a cybercriminal past multi-factor authentication (MFA) and into an account without legitimately completing every verification step. It can turn a control that looks complete into a false sense of protection. This leaves sensitive accounts and data exposed.
The stakes are immediate: the FBI's Internet Crime Complaint Center (IC3) has logged more than 5,100 account takeover fraud complaints since January 2025, with losses exceeding $262 million, and a valid MFA code handed over by the person it was sent to shows up again and again in these cases.
Key Takeaways
MFA bypass attacks target authentication protocols and sessions, often by manipulating the people involved, while leaving the cryptography behind them intact.
Some of the hardest techniques to detect, including adversary-in-the-middle phishing and session token theft, succeed after a user has legitimately approved a login.
Authentication methods differ sharply in strength, and Short Message Service (SMS) codes and simple push approvals fall to attacks that Fast Identity Online (FIDO)-based authenticators block by design.
Preventing bypass depends as much on disabling legacy protocols and hardening help desk procedures as on enabling MFA in the first place. Monitoring sign-in behavior is equally important.
What Is a Multi-Factor Authentication (MFA) Bypass?
A multi-factor authentication (MFA) bypass occurs when an attacker exploits a weakness in how MFA is deployed, enforced, or trusted to reach an account they should have been locked out of. A bypass can lead to account takeover fraud even though the organization appears to have MFA in place. MFA itself requires multiple factors: a password plus an authenticator code, push approval, hardware key, or fingerprint.
The Federal Bureau of Investigation's (FBI) IC3 described the typical case in a recent alert as a criminal who "manipulates the account owner into giving away their login credentials, including multi-factor authentication (MFA) code or One-Time Passcode (OTP), by impersonating a financial institution employee." A valid code surrendered by the person it was sent to is MFA bypass in its simplest form.
How Does an MFA Bypass Happen?
An MFA bypass happens in one of three ways: MFA is not enforced, a user or support process completes the challenge for the attacker, or the attacker steals a post-authentication session or token.
Technical Gaps Skip or Reuse Authentication
Some paths reach the account without ever requesting the second factor, exploiting configuration and protocol gaps that operate independently of user involvement:
Legacy Authentication Protocol Abuse: Older mail access can use basic authentication for Post Office Protocol 3 (POP3), Internet Message Access Protocol (IMAP), and Simple Mail Transfer Protocol (SMTP), including SMTP basic authentication. Where these modes remain enabled on a cloud email tenant, a valid password alone can authenticate without an MFA prompt.
Unenrolled and Misconfigured Accounts: MFA set to "fail open" offers a way in. Contractors who never finished enrollment and inactive directory accounts do too. Russian state-sponsored actors exploited an account left on default MFA settings at a non-governmental organization to enroll their own device and reach the network.
These gaps matter because MFA can appear active in an admin console while entire access paths quietly ignore it, giving attackers a way in that never triggers the second factor and never generates a suspicious prompt.
Stolen Sessions and Tokens Bypass the Login Entirely
Other technical paths begin after authentication has already succeeded, when the attacker obtains a token that the service trusts as proof of the completed login:
Session Cookie and Open Authorization (OAuth) Token Theft: Malware on the device or a proxy can lift a token after login. A compromised integration offers another route, opening the account with no sign-in page involved.
Consent and Device Code Phishing: The attacker asks the user to approve an application, a form of consent phishing; no password disclosure is required. An attacker-controlled app with mailbox or file permissions holds persistent access through its own token, with no further MFA challenge.
Post-authentication attacks like these are especially difficult to catch because MFA never fires a second time. The intrusion looks identical to legitimate use and can persist long after the original session was intended to end.
User and Support Approvals Complete the Challenge
In this category the second factor fires as designed, but the account owner or a support process completes it on the attacker's behalf. Because the approval is genuine, the login rarely looks suspicious on its own, and each variant works a different angle:
Adversary-in-the-Middle (AiTM) Phishing: A phishing link routes the victim through a reverse proxy between their browser and the real login page. Credentials and the MFA code pass to the legitimate service, while the returning session cookie is copied by an adversary-in-the-middle.
MFA Prompt Bombing (MFA Fatigue): An attacker with a valid password submits it repeatedly, a tactic known as MFA fatigue. This sends approval requests to the user's phone until one gets tapped out of confusion or a wish to stop the alerts.
Help Desk Social Engineering: Posing as a locked-out employee, an attacker asks information technology (IT) support for a password reset or fresh MFA enrollment. Posing as IT, the attacker asks an employee to approve a prompt. Both rely on a pretext built from information that is already public.
SIM Swapping and SMS Interception: Attackers persuade or compromise a mobile carrier into moving the victim's phone number to a Subscriber Identity Module (SIM) card they control, while weaknesses in Signaling System 7 (SS7) let some actors read codes without a swap. SIM swapping remains an account takeover strategy attackers favor.
One-Time Passcode (OTP) Brute Forcing and Code Interception: Without rate limiting or lockout, short numeric codes become guessable. This puts a brute force attack on codes in range. Malware can also read incoming SMS codes and replay them before they expire.
These techniques are among the hardest to catch with technical controls alone, since every step of the login is legitimate from the system's perspective. Detection has to lean on user behavior, help desk process, and out-of-band signals rather than the authentication event itself.
Inside an Adversary-in-the-Middle Attack Chain
Adversary-in-the-middle phishing defeats codes and push approvals while the victim follows the expected login process.
Proxying the Login and MFA Challenge
With the rise of phishing-as-a-service, an operator rents the infrastructure, picks a target, and sends the email.
Lure Delivery: A convincing phishing email carries a link, often behind a multilayer redirect chain.
Proxy Interception: The victim's browser connects to the attacker's reverse proxy, which fetches the genuine login page and presents it over a valid Transport Layer Security (TLS) connection.
Credential Relay: The username and password are forwarded to the real service and logged by the proxy at the same time.
MFA Challenge Forwarded: The real service responds with its MFA prompt, the victim approves the push or enters the code, and the proxy forwards that too, inside the code's validity window.
A one-time code or push approval carries no information about which website the user was viewing, so neither can detect the proxy. The National Institute of Standards and Technology (NIST), in its digital identity guidelines, says that authenticators requiring manual entry of a code "SHALL NOT be considered phishing-resistant because the manual entry does not bind the authenticator output to the specific session being authenticated."
Capturing and Replaying the Trusted Session
Once the legitimate service accepts the relayed MFA response, the attack shifts from authentication to control of the resulting session.
Session Cookie Captured: The service accepts the completed challenge and issues a session cookie, every byte of which flows through the proxy.
Replay and Persistence: The attacker loads the cookie into their own browser and is treated as the signed-in user. Registering a new MFA device from inside that session locks in persistent access.
Nothing in this sequence fails. FIDO standards, including FIDO2 authenticators that use Web Authentication (WebAuthn), close the gap through origin binding: the credential is registered to a specific domain, and at login the browser signs the current origin into the assertion. When that origin is the attacker's proxy domain, the signature does not match and the login fails. Account recovery flows and fallback options that let a user pick a weaker method can remain open, so attackers go after recovery and fallback paths instead of the key.
Real-Life Examples of MFA Bypass
MFA bypass has been a factor in several major breaches of the past five years. Verizon's 2026 Data Breach Investigations Report found that 62% of breaches involved a human element.
The pipeline operator attack of May 2021 began with a compromised password on a legacy virtual private network (VPN) account that had only single-factor authentication. A healthcare organization repeated the pattern in February 2024, when attackers logged into a remote access portal with compromised credentials. The portal had no MFA even though MFA was a company-wide requirement, and ransomware deployment followed.
The same gap affected customers of a cloud data platform between May and June 2024. The threat group UNC5537 used credentials harvested by infostealer malware years earlier to log into accounts with no MFA and exfiltrate data. Old stolen logins like these are material for credential stuffing.
Where MFA was active, attackers worked on the people around it. Lapsus$, active from 2022 to 2023, exploited MFA fatigue by calling employees late at night to coerce approval of prompts, and it ran fraudulent SIM swaps through carriers' customer management tools. The September 2023 intrusions at two hospitality companies went through IT support: one disclosed in a securities filing that its breach stemmed from a social engineering attack on an outsourced IT support vendor. Scattered Spider talks help desk staff into resetting passwords and MFA tokens.
Common Misconceptions About MFA Security
Most misconceptions about MFA come from treating it as a single control, when in practice the methods behind it differ sharply in what they actually resist. The five beliefs below show up most often in security reviews and post-incident reports:
"Any MFA Stops Phishing": The attack chain above works against code- and push-based methods. Phishing resistance belongs to FIDO/WebAuthn and public key infrastructure (PKI) authenticators, which refuse to authenticate to the wrong domain.
"SMS Codes Are as Safe as an Authenticator App": SMS lacks end-to-end protection and remains exposed to carrier compromise, number swapping, and SS7 interception. NIST classifies SMS and voice codes as restricted authenticators. Organizations that keep them must offer an alternative and maintain a migration plan.
"MFA Fatigue Only Catches Careless Users": Prompt bombing succeeded against employees at security-conscious companies, partly because attackers timed prompts for the middle of the night and paired them with chat messages posing as the help desk. A plain approve/deny screen gives no context about who is logging in, which is why security awareness training now covers unprompted approvals.
"Passwords Stop Mattering Once MFA Is On": Prompt-bombing campaigns and legacy protocol logins start with a valid password, one reason MFA falls short as a standalone control.
"Enrollment Means the Account Is Protected": Enrolling in an authenticator app may not remove SMS as a fallback. Contractors who never finished enrollment and inactive accounts can persist inside an identity and access management program that looks complete on paper. So can an attacker's self-registered device after session theft.
Recognizing these gaps matters because each one shapes where investment and policy should go next. Treating MFA as a spectrum of controls rather than a single checkbox is what separates a program that looks compliant from one that actually withstands the attacks in circulation.
How to Prevent MFA Bypass
Preventing MFA bypass starts with choosing authentication methods that resist the attacks described above, then closing every path that skips them. The Cybersecurity and Infrastructure Security Agency's (CISA) phishing-resistant MFA guidance ranks these methods as follows.
MFA Method | Phishing and AiTM | Prompt Bombing | SIM Swap and SS7
|
|---|---|---|---|
FIDO/WebAuthn keys and passkeys; PKI smart cards | Resistant | Not applicable | Not applicable |
Authenticator app codes | Vulnerable | Not applicable | Not applicable |
Push with number matching | Vulnerable | Resistant | Not applicable |
Push notification without number matching | Vulnerable | Vulnerable | Not applicable |
SMS or voice codes | Vulnerable | Not applicable | Vulnerable |
Stronger Authentication and Training Reduce User-Driven Bypass
The strongest methods remove decisions or transferable codes from the authentication process. Interim controls can add context to approvals, while training helps users recognize requests that still reach them.
Phishing-Resistant MFA First: The first candidates are administrators and anyone with broad access to customer or financial data, since those accounts draw targeted attacks. Properly configured FIDO keys and passkeys block the AiTM and prompt-bombing paths when weaker recovery methods are unavailable, and they fit the identity pillar of a zero trust model.
Number Matching for Push Approvals: Where push notifications remain, requiring the user to type a number shown on the login screen into the app makes blind approval substantially harder. This is the standard interim mitigation for organizations not yet on FIDO, although live social engineering can still trick a user into entering the number shown to the attacker.
Training on the Specific Attacks: Employees should treat MFA codes like passwords, deny prompts they did not generate, and report unexpected help desk calls. Realistic phishing simulations build those reflexes.
Stronger authenticators reduce what an attacker can steal, while number matching adds context to prompts. Training helps users respond when technical controls still require judgment.
Broader Enforcement and Monitoring Close Remaining Gaps
Beyond authenticator choice, closing the remaining bypass paths depends on enforcement across protocols, identity hygiene, and continuous monitoring of what happens after sign-in:
Legacy Protocol Blocking: Blocking basic authentication for POP3, IMAP, and SMTP with a conditional access policy removes a common bypass path, since these legacy authentication modes cannot support MFA.
Conditional Access and MFA Coverage Review: Organizations can review MFA configuration for fail-open and re-enrollment behavior, then confirm coverage across active, internet-facing protocols and applications, including third-party app consent grants. Adaptive authentication that steps up verification on unusual geolocation or prompt volume narrows the rest.
Sign-In and Token Monitoring: A bypass in progress leaves visible traces in repeated denied prompts and logins from two distant locations within minutes. Token use from unfamiliar devices is another signal. Correlating those signals is the core of account takeover protection.
Help Desk Verification Standards: Help desks can require identity checks that do not rely on caller-provided details before resetting passwords or enrolling a fresh factor. Organizations can also disable inactive accounts in both the directory and MFA system. Capping failed logins and MFA prompts per account in a short window blunts OTP brute forcing and prompt bombing.
Together, these controls shrink the surface area where a bypass can succeed and shorten the window in which one goes unnoticed. Without them, even the strongest authenticator can be undermined by an unmonitored protocol, a dormant account, or a help desk process willing to trust a caller.
Building MFA That Holds Up
Unenforced authentication creates a gap between the MFA an organization thinks it has and the MFA an attacker actually encounters. Approvals obtained through people or support processes create another. A session that outlives its legitimate use leaves the same kind of opening. Closing those gaps combines configuration, process, monitoring, and phishing-resistant authentication. A complete inventory of legacy protocols, app consent grants, and re-enrollment paths provides the clearest measure of what to strengthen next.
Frequently Asked Questions
Can MFA Be Bypassed?
Yes. Attackers bypass MFA without breaking its cryptography by intercepting sessions after a legitimate login, tricking users or help desks into approving access, taking over phone numbers to receive SMS codes, or connecting through authentication modes that never request a second factor.
What Is MFA Fatigue?
MFA fatigue, also called push bombing, is a social engineering attack in which someone who already has a victim's password repeatedly triggers login attempts so that approval prompts flood the victim's phone. The goal is a single accidental or exasperated tap on "Approve." Number matching makes blind approval far harder, although live social engineering can still mislead a user.
What Is Phishing-Resistant MFA?
Phishing-resistant MFA covers FIDO2/WebAuthn security keys and passkeys along with PKI-based smart cards. Both bind the login to the real domain. The user has nothing to read out, type, or hand to a caller, so a convincing phone script has nothing to collect, provided weaker recovery or fallback methods are unavailable.
Can Legacy Authentication Protocols Bypass MFA?
They can when they use basic authentication. Basic authentication for POP3, IMAP, and SMTP has no mechanism for prompting beyond a password, so a valid password is the entire login until a conditional access policy blocks that authentication mode.