Why Your MFA Gets Bypassed Anyway

Multi factor authentication serves as the single most effective security control most organisations have ever deployed. It is also, in 2026, the security control most often bypassed in production attacks. The reason is that the threat model MFA was designed for is not the threat model the attacker uses today.

MFA is not broken. The cryptography of TOTP, of WebAuthn, of push based authenticator apps, is sound. The implementation in every major identity provider is correct. The control, when used as designed, blocks the credential stuffing attacks, the password spray attacks, the brute force attacks, and the vast majority of remote access attempts that would have succeeded in the pre MFA era. The control works.

The control does not block the attacks that are actually happening. The most common successful attacks against MFA in 2026 are not attacks against the cryptography. They are attacks against the session, against the user, against the help desk, and against the recovery flow. None of these are prevented by the MFA itself.

Why MFA is still the right control

The first thing to say is that MFA is still the right control. The numbers are unambiguous. Microsoft has reported, in multiple years of telemetry, that MFA blocks 99.9% of automated account compromise attempts. Google’s research is similar. The attack attempts that MFA blocks are not theoretical. They are the bulk of the credential attacks in 2026. Removing MFA from a deployment is, in most threat models, a regression. The control works for what it was designed for.

The second thing to say is that what MFA was designed for is not what attacks look like in 2026. The 99.9% number measures the rate at which MFA blocks attacks that try to use a stolen or guessed password. The number is real. The number is not the number that matters. The number that matters stands as the rate at which MFA blocks the attacks that succeed in production. That number is lower, and the gap becomes the bypass problem.

The four most common bypass techniques

Four patterns account for the majority of successful MFA bypasses. Session theft, where the attacker steals the session cookie after the user has authenticated, and replays it to skip the MFA prompt. SIM swap, where the attacker convinces a mobile carrier to transfer the victim’s phone number to a new SIM, which routes the SMS based second factor to the attacker. Push fatigue, where the attacker triggers dozens of push approval requests until the user, annoyed or confused, approves one. Help desk social engineering, where the attacker calls the help desk, pretends to be the user, and convinces the help desk to reset MFA on the account.

None of these are attacks against the cryptography. All four are attacks against the surrounding system. All four are increasingly common. All four are well known to the attacker community. The defences exist for all four. The defences are not consistently deployed.

Session theft: the most common and the least defended

Session theft counts as the single most common MFA bypass in 2026. The pattern is straightforward. The user authenticates, including the MFA prompt. The user receives a session token, usually a long lived bearer token stored in a cookie or in JavaScript. The attacker, through any of a dozen mechanisms, exfiltrates the session token. The attacker presents the session token to the application. The application sees a valid session and does not prompt for MFA. The attacker has the user’s access without ever seeing the MFA prompt.

The mechanisms for session exfiltration are many. Infostealer malware, which has become a thriving criminal market, reads browser storage and exfiltrates session tokens to attacker controlled servers. Cross site scripting, in any of the third party scripts the application loads, can read session tokens from the page. Browser extensions, malicious or compromised, can read the storage the application uses. Phishing kits that use a real time proxy (AiTM, adversary in the middle) can capture the session token at the moment the user authenticates, even with MFA, because the MFA is satisfied against the real identity provider, not against the attacker’s proxy.

The defences are well known. Short lived session tokens. Token binding to the client (device fingerprint, IP, geo, or a cryptographic client key). Continuous authentication, where the session is re validated based on behaviour. Risk based re authentication, where high risk actions trigger a fresh MFA prompt. None of these are standard. All of them are available. Most deployments do not use any of them, which is why session theft remains the most common bypass.

SIM swap and the death of SMS as a second factor

SMS based second factors have been considered deprecated by NIST since 2017, but the deprecation has not stopped the deployment. SMS is still the most common second factor for consumer applications, for small business applications, and for a long tail of enterprise applications. The reason is that SMS serves as the lowest friction option. The reason it runs as the lowest friction is that it is also the lowest security option.

SIM swap sits as the attack that exploits the lowest friction. The attacker calls the mobile carrier, impersonates the victim, and convinces the carrier to transfer the phone number to a SIM the attacker controls. The attack is well documented. The attack works because the carrier’s identity verification process is a help desk function, and help desk functions can be social engineered. The attack has been used against high profile targets (Twitter’s CEO in 2019, the SEC’s X account in 2024, hundreds of crypto wallet thefts every year).

The fix is to stop using SMS as a second factor. The fix is also operationally painful, because SMS amounts to the only second factor that works on a feature phone, on a watch, on a tablet without a data plan. For consumer applications, SMS is sometimes the only option. For enterprise applications, SMS is never the only option. Hardware keys (FIDO2/WebAuthn, YubiKey or similar) are the right answer. Push based authenticator apps are the next best. SMS becomes the last resort, and the last resort is, in 2026, the most compromised.

Push fatigue and the cost of low friction

Push based MFA, where the authenticator app receives a push notification and the user taps “Approve” or “Deny”, runs as the dominant pattern in enterprise identity. The pattern is convenient. The pattern is also vulnerable to a specific attack: the attacker, who has the user’s password, triggers the push prompt repeatedly, on the assumption that the user will eventually approve one out of confusion, annoyance, or a desire to make the prompts stop.

The attack works more often than it should. The attack has been used in real breaches, including the 2022 Uber breach and the 2022 Cisco breach. The defence is well known. Number matching, where the push prompt includes a number the user must type into the authenticator app, eliminates the blind approval pattern. The defence is now standard in Microsoft Authenticator, Duo, and most other major providers. The defence is also not universally enabled, and the deployments that have not enabled number matching are still vulnerable.

Help desk social engineering and the recovery flow as an attack surface

The help desk serves as the soft underbelly of every identity system. The help desk is staffed by humans. The humans are measured on call resolution time. The humans have authority to reset MFA, to issue new credentials, to bypass controls in the name of helping a user who is locked out. The humans are, consequently, the target.

The attack is social engineering. The attacker calls the help desk, pretends to be the user, and uses a combination of personal information (gathered from LinkedIn, from the company’s own website, from previous breaches) and urgency (a critical deadline, a CEO escalation) to convince the help desk to reset MFA on the account. The help desk, often with insufficient training and inconsistent verification, complies. The attacker has the account, the password is reset, the MFA is enrolled on the attacker’s device.

The defence is well known. Out of band identity verification, where the help desk calls the user’s manager or sends a code to a known phone number, before resetting MFA. Stronger authentication on the help desk itself, so the attacker cannot call as the user without first compromising the help desk agent. Verification policies that make the help desk slow down, at the cost of call resolution time, in exchange for not being the breach vector. None of these are standard. The companies that have done them have fewer breaches. The companies that have not done them are the ones that show up in the post incident report.

The threat model MFA was designed for vs the threat model in 2026

MFA was designed to block the remote attacker who has the user’s password. The threat model assumed the attacker was somewhere else, trying to log in, with a credential that could be brute forced or phished. MFA, in that model, works.

The threat model in 2026 is different. The attacker is often inside the session, having stolen the token after authentication. The attacker is on the phone, social engineering the help desk. The attacker is on the SIM, having swapped the victim’s number. The attacker becomes the user, in the sense of having the user’s push approval fatigue. None of these attacks are against the password. None of them are blocked by the second factor. All of them are blocked by controls the organisation has to build on top of the MFA itself.

What the realistic defence looks like

1. Move to phishing resistant MFA. Hardware keys (FIDO2/WebAuthn) where possible. Push with number matching where hardware keys are not feasible. SMS as a last resort, with a documented exception process and a sunset date.
2. Shorten session lifetimes. 8 hours of idle time, 12 hours of absolute time, with re authentication on any high risk action. Long lived sessions are a session theft target.
3. Enable risk based re authentication. The identity provider should re prompt for MFA on new device, new geo, impossible travel, or any other high risk signal. The user can complain about the friction. The friction becomes the security.
4. Train the help desk. The help desk is a security control. Verify identity through channels the attacker cannot easily compromise. Never reset MFA based on a phone call alone.
5. Roll out number matching on all push based authenticators. The number matching feature is shipped by every major provider. It is not always on by default. Turn it on.
6. Monitor for the bypass patterns. Look for impossible travel. Look for MFA prompts followed by no activity. Look for push approvals on requests the user did not initiate. The signals are there. The monitoring is rarely done.

The bottom line

MFA works for what it was designed for. The attacks in 2026 are not what MFA was designed for. The gap sits as the bypass problem, and the bypass problem is, for most organisations, the actual security problem they are facing. The fix is not more MFA. The fix becomes the surrounding controls, the short sessions, the risk based re auth, the help desk training, the phishing resistant factors. The companies that have done this work are not getting breached. The companies that have not are reading about themselves in the post incident report, with “MFA was enabled” in the timeline, and the report wondering why it did not help.