MFA Bypass: How Attackers Get Around Multi-Factor Authentication
MFA can stop stolen passwords, but attackers increasingly target the authentication flow itself. Learn how MFA bypass works, see real-world examples, and understand which controls make these attacks harder.
A user enters the correct password.
Microsoft asks for MFA. The user approves it. The sign-in succeeds.
A few minutes later, an attacker is inside the account.
At first, that sounds like MFA failed. In many modern attacks, it did not. The authentication system verified exactly what the user gave it. The attacker simply controlled the process around that authentication or stole the session that came after it.
That distinction is important.
Attackers can target more than passwords. They also target push notifications, authentication flows, session tokens, account recovery, and the moment a user decides whether a login request looks legitimate.
MFA still blocks account takeover attempts that rely on a stolen password alone. But not every MFA method provides the same protection, and a successful MFA event does not automatically mean the right person controls the resulting session.
What Is a Multi-Factor Authentication (MFA) Bypass?
A Multi-Factor Authentication (MFA) bypass happens when an attacker gets around the protection MFA is supposed to provide and gains access to an MFA-protected account.
That does not always mean the attacker disables MFA or discovers a technical flaw in the second factor. Sometimes the attacker convinces the legitimate user to complete MFA for them. In other cases, they intercept the authenticated session, replay a stolen token, abuse a legitimate authorization flow, or register a new authentication method after gaining temporary access.
Imagine an attacker already knows a user's password.
If the account uses a simple push notification, the attacker can trigger a login and hope the user presses Approve. If the attacker uses an adversary-in-the-middle phishing site, they can relay the victim's authentication to the legitimate identity provider in real time and capture the resulting session. If they abuse Device Code authentication, the victim may even sign in on a real Microsoft page while unknowingly authorizing the attacker's device.
MFA technically succeeds in all three situations. The problem is that the authentication happens in the wrong context.
This is why defenders should not reduce MFA bypass to one question:
"Did MFA pass?"
A better question is:
"Did this user authenticate the correct session, on the expected device, for the expected application?"
Once you look at MFA this way, the common bypass techniques become much easier to understand.
How Does an MFA Bypass Happen?
Attackers have several ways to get around traditional MFA. Some target the user before authentication. Others target the session after authentication has already succeeded.
1. Adversary-in-the-middle phishing
Adversary-in-the-middle, or AiTM, phishing places attacker-controlled infrastructure between the victim and the legitimate sign-in service. The phishing page behaves like a proxy.
When the victim enters a username and password, the proxy forwards them to the real identity provider. When the real service asks for MFA, the victim completes that step too. The attacker relays the entire exchange in real time.
Once authentication succeeds, the proxy can capture session material that represents the authenticated user. The attacker never needs to guess the MFA code. They let the victim complete MFA and target what comes next.
- Victim
- Attacker-controlled proxy
- Legitimate identity provider
- Password + MFA completed
- Authenticated session captured
This is one reason one-time passwords, SMS codes, and some push-based methods remain vulnerable to phishing. The authentication factor may be valid, but nothing strongly binds it to the legitimate site the user intended to access.
2. MFA fatigue and push bombing
Push-based MFA can create another opportunity when the user only needs to approve a notification. An attacker who already has the password repeatedly attempts to sign in. Each attempt sends a new MFA request to the victim's device.
One request becomes five. Five become twenty. The attacker is waiting for one mistake. The user may approve because they are distracted, think an application needs them to sign in again, or simply want the notifications to stop. Attackers may also contact the victim and pretend to be IT support to make the approval request sound legitimate.
This technique is usually called MFA fatigue, push bombing, or MFA prompt bombing. CISA has documented repeated MFA notification abuse in real intrusions and recommends phishing-resistant MFA as the stronger long-term control.
3. Device Code phishing
Device Code authentication is a legitimate OAuth flow. It helps devices with limited input capabilities complete authentication through another browser or device, but attackers can abuse the same flow.
The attacker starts the Device Code request and gives the generated code to the victim. The victim follows the instructions and may land on Microsoft's legitimate device login page.
That legitimate domain lowers suspicion. The victim enters the code and completes authentication. If MFA appears, they complete that too. But the victim is not authorizing their own device. They are authorizing the session the attacker started.
The attack works because the authentication takes place separately from the device that initiated the request. The victim sees a legitimate authentication page, while the attacker receives the resulting authorization.
4. Session token theft and replay
MFA mainly protects the authentication event. An attacker can avoid that event completely if they steal a valid authenticated session.
AiTM phishing, infostealer malware, browser compromise, and other session theft techniques can expose cookies or tokens created after the user has already authenticated. The attacker then tries to replay that session material from another environment. If the service accepts it, the attacker may gain access without entering the password or completing a new MFA challenge. From the application's perspective, the session has already proved its identity.
This is why resetting a password does not always contain a compromised account. Security teams also need to consider active sessions, refresh tokens, registered authentication methods, OAuth grants, inbox rules, and any other persistence the attacker created after gaining access.
5. MFA registration and account recovery abuse
Attackers can also target the process used to create or recover an MFA method.
Suppose an attacker gets temporary access to an account or successfully social-engineers a help desk. Instead of repeatedly fighting the existing MFA control, they may try to register their own authentication method.
Once they do that, future authentication becomes much easier. A newly registered phone, authenticator, passkey, recovery method, or other factor can give the attacker a legitimate-looking way back into the account.
That makes MFA enrollment, reset, and recovery security events in their own right. Organizations should protect these workflows with strong identity verification and monitor unexpected changes to authentication methods.
Real-Life Examples of MFA Bypass
MFA bypass is not a theoretical technique. The following campaigns show attackers actively building their phishing infrastructure around the fact that organizations already use MFA.
1. Microsoft's 2026 AiTM "Code of Conduct" campaign
Between April 14 and 16, 2026, Microsoft observed a large phishing campaign that targeted more than 35,000 users across over 13,000 organizations in 26 countries. The emails impersonated internal compliance and regulatory communications. After several stages of redirection, victims reached a legitimate sign-in experience that formed part of an AiTM phishing flow.
The attackers proxied the authentication session in real time and captured authentication tokens after the victim authenticated. This allowed them to get around MFA methods that were not phishing-resistant.
Microsoft's investigation shows why checking only the final login page is not enough. A victim can eventually see a legitimate authentication service and still be inside an attacker-controlled authentication chain.
You can read the full Microsoft analysis of the May 2026 AiTM campaign. It details the campaign's lures, infrastructure, and mitigations.
2. The 2026 EvilTokens Device Code campaign
Microsoft also documented a widespread Device Code phishing campaign in April 2026 associated with the EvilTokens phishing-as-a-service toolkit. The attackers automated much of the attack.
Rather than placing a static Device Code in an email and hoping the victim used it before it expired, the infrastructure generated a fresh code when the victim reached the phishing page. The victim was then directed to Microsoft's legitimate Device Login service. After the victim completed authentication, the attacker's backend received valid access to the account.
Microsoft observed stolen tokens being used for follow-on activity including email access, reconnaissance, and malicious inbox rules.
This attack is especially useful for understanding MFA bypass because the victim may authenticate on a genuine Microsoft domain. The dangerous part is not necessarily the login page. It is who initiated the authentication flow.
Microsoft published the full Device Code phishing campaign analysis in April 2026, including its prevention guidance.
3. Scattered Spider and MFA fatigue
MFA fatigue has also appeared in intrusions associated with Scattered Spider. In its joint advisory on the group, CISA describes threat actors sending repeated MFA notification prompts until employees accepted them. The actors also used social engineering against help desks and other identity-focused techniques to gain or maintain access.
The lesson is straightforward: a push notification is still a decision made by a person. If the authentication method allows the user to approve an unexpected request without cryptographically proving which service and session they intend to access, attackers can target that decision.
How To Prevent MFA Bypass
You should not respond to MFA bypass by removing MFA or assuming the control no longer works. The better response is to make authentication harder to relay, make sessions harder to steal and replay, reduce unnecessary authentication paths, and detect when identity activity stops matching normal behavior.
1. Move to phishing-resistant MFA
The strongest improvement is to replace phishable methods with authentication that attackers cannot easily relay. Microsoft recommends phishing-resistant methods including passkeys based on FIDO2, FIDO2 security keys, Windows Hello for Business, and certificate-based authentication.
Passkeys use public-key cryptography and bind the credential to the legitimate service. The private key does not get sent to a phishing page, and the credential created for one origin cannot simply be replayed against another.
Microsoft now describes passkeys as phishing-resistant credentials and recommends moving organizations toward phishing-resistant passwordless authentication. Start with administrators and other high-impact users, then expand the deployment.
Do not leave phishing-resistant MFA as a special control used only by a handful of privileged accounts if the rest of the organization still relies on easily phished methods. A phased rollout should still have a clear endpoint.
2. Harden push-based MFA while you migrate
Not every organization can replace every authentication method immediately. If users still rely on push notifications, remove simple one-tap approval wherever possible.
Use number matching and give users enough context to understand which sign-in they are approving. CISA recommends number matching as a mitigation against push bombing when phishing-resistant MFA is not yet available, while making clear that it does not provide the same level of protection.
Also monitor repeated MFA requests. A sequence of denials followed by one successful approval should trigger investigation, especially when the source IP, location, device, or application does not match the user's normal behavior.
3. Restrict Device Code authentication
If your organization does not need Device Code flow, do not leave it broadly available. Microsoft recommends blocking Device Code flow where possible and controlling it through Conditional Access where the organization has a legitimate requirement for it.
Where you keep it enabled, monitor it as a distinct authentication flow. A Device Code sign-in shortly after a user clicks a link in an unusual email should not be treated as two unrelated events. Put the email activity and identity activity on the same timeline.
4. Protect the session after MFA
Strong MFA reduces credential theft, but defenders also need to protect the session created after authentication. Microsoft Entra's Token Protection can bind supported sign-in session tokens to the device where they were issued. That makes token replay from another device harder.
Use it as one layer alongside Conditional Access, managed-device requirements, risk-based policies, session controls, and Continuous Access Evaluation. The goal is to reduce how useful a stolen token remains after the attacker gets it.
5. Lock down MFA registration and recovery
Treat a new authentication method as a security-sensitive change. Monitor new factors, recovery changes, Temporary Access Pass activity, help-desk resets, device registrations, and authentication-method changes that occur after suspicious sign-ins.
For high-impact accounts, require stronger identity verification before support staff reset MFA or allow a new factor to be registered. An attacker should not be able to bypass strong MFA simply by convincing another employee to replace it.
6. Correlate email, identity, and post-login activity
Many MFA bypass attacks begin with an email and become visible only after authentication. Look at the complete sequence:
- Suspicious email
- Link or authentication request
- Unusual MFA or Device Code activity
- New session
- Mailbox, OAuth, or account changes
Individually, each event may look explainable. Together, they can show the attack clearly.
MFA remains essential, but attackers have adapted to it. They now target the authentication flow, the session, and the person approving the request. A successful MFA event should therefore be one signal in the investigation, not the end of it.
The best defense is not simply to generate more MFA prompts. Use phishing-resistant authentication, reduce unnecessary sign-in flows, protect authenticated sessions, secure recovery processes, and monitor what happens before and after the login.
When MFA succeeds, ask one more question:
Did the legitimate user authenticate the session they actually intended to use?
