Six techniques that bypass MFA in 2026 (and how they work)

The second factor did not fail because of a flaw in the technology: it failed because someone approved something they should not have. The six techniques that most often bypass MFA in 2026 share that common thread. The three we see most often are device code phishing, where the victim approves a legitimate code and in doing so hands over their session; AiTM (adversary-in-the-middle), a proxy that sits between the person and the real site and steals the already authenticated token; and consent phishing, where the employee authorizes a malicious application through OAuth that then never needs to ask for their password again. None of them breaks the cryptography of MFA. All of them go around the person.

It is worth saying this up front, because in 2026 the "turn on MFA and you are done" narrative became dangerous. The phishing email or lure is still the door to almost all of these attacks: according to CISA, more than 90 percent of successful cyberattacks start with a phishing email. MFA closed the easy door, the password-only one, so the attacker stopped fighting the password and started fighting the person. This is the map of the six techniques, what each one exploits and, above all, what each reveals about your team's behavior.

What does it mean for an attack to "bypass" MFA?

Bypassing MFA does not mean cracking it. It means going around it. The second factor produces something (a code, an approval on the phone, an already validated session token) and the attacker gets the person to hand that something over, or intercepts it the moment it is generated. The lock stays intact; what changes is who ends up holding the key.

This fits a familiar pattern: Cisco's 90-5-5 framework estimates that close to 90 percent of breaches involve a human factor. Bypassing MFA is that human factor in its most advanced form, because it no longer depends on someone using a weak password, but on someone approving, authorizing or typing under a well-built deception. And the deceptions keep getting better: AI-driven phishing is now three times more effective than traditional campaigns (Microsoft Digital Defense Report 2025), which means more believable lures reaching the inbox that opens the door to each of the techniques below.

1. Device code phishing: you approve a code and hand over your session

Device code phishing abuses a legitimate flow designed for devices without a convenient keyboard, such as TVs or consoles. The attacker starts that flow, obtains a real code from the identity provider, and gets it to you with a believable excuse: "enter this code to complete your sign-in". You type it into the provider's genuine page, approve it with your MFA, and without realizing it you authorize the attacker's session, not yours. It all happens on the official site, with your second factor working correctly. That is why it is so hard to detect: there is no fake page to inspect, there is a code that should never have left your screen.

2. AiTM (adversary-in-the-middle): the proxy that steals your token live

AiTM places an intermediary server between the person and the real site. The victim clicks a link, reaches what looks like the usual sign-in page, enters their username, their password and even approves the MFA. The proxy forwards everything to the authentic site in real time and, when the provider returns the already authenticated session token, it captures it. With that token, the attacker gets in without going through MFA again, because as far as the system is concerned the session is already validated. This is the technique that turned session theft into the preferred way to skip the second factor: it does not steal your password to use later, it steals the session that MFA just approved.

3. Consent phishing: you authorize a malicious app through OAuth

Consent phishing is not after your password or your code: it is after your permission. You receive an invitation to connect an application (a supposed productivity tool, a document viewer) that requests access to your email, your calendar or your files through OAuth. If you approve, you grant it a persistent access token. From then on the malicious app reads your email or sends on your behalf without ever needing your password again, and changing your password does not evict it, because the permission you granted stays alive until someone revokes it. It is a silent attack: it does not trigger suspicious-sign-in alerts because, technically, you gave the consent.

4. MFA fatigue (push bombing): you approve out of exhaustion

MFA fatigue does not deceive with a page, it wears you down with repetition. The attacker already has the password (leaked or bought) and launches a flood of push notifications to the victim's phone, one after another, sometimes at midnight. The bet is simple and unfortunately effective: sooner or later the person, tired or confused, approves one just to make the notifications stop. That single tap hands access to the attacker. We take it apart in detail in MFA fatigue: when the second factor gives in to exhaustion, but the point for this map is that here there is no technology breached, there is a person pushed to the limit until they give in.

5. MFA downgrade: they push you to a weaker method

MFA downgrade takes advantage of the fact that many accounts allow several second-factor methods, some strong and some weak. The attacker, often calling or writing as if they were support, convinces the person to "temporarily switch" to a more vulnerable method, such as a code by SMS or email, or to disable the strong method "to fix an issue". Once the account accepts the weak factor, intercepting it is far easier. It is pure social engineering aimed at the security configuration: it does not attack MFA, it attacks the person's decision about which MFA to use.

6. Passkey enrollment hijacking: they register their key, not yours

Passkeys are among the most resistant methods there are, but the resistance lives in the correct key. In this attack, a criminal who already has a foot in the door (a stolen session, a leaked password) uses the moment of enrolling a passkey to register theirs on your account, not yours. From that instant they hold a legitimate, permanent authentication factor over your identity, indistinguishable from a real one to the system. They did not break the passkey: they slipped into the process of setting it up. It is proof that even the strongest method depends on the process around it being protected and on the person recognizing when something in that process does not add up.

Summary table: what each technique exploits and what it reveals about behavior

What they have in common and how to validate that the team learned

Read together, the six tell the same story: the attacker stopped fighting the second factor and moved on to fighting the person who operates it. None of them cracks cryptography. All of them depend on a moment of human decision under pressure, haste or misplaced trust. Phishing-resistant MFA and a good configuration help, a lot, but social engineering exists precisely to go around technology: that is why no technical control, however solid, closes the topic on its own as long as there is a person to convince.

This is exactly the ground of human risk management (HRM): treating people's behavior as a surface that is measured and reduced, not a course that gets completed.

And here comes the uncomfortable question: how do you know your team would recognize one of these traps in the real moment? Sending a training email is not enough. There is peer-reviewed evidence that completing a training does not on its own predict a reduction in real failures (Ho et al., IEEE Symposium on Security and Privacy 2025; Lain et al., IEEE Symposium on Security and Privacy 2022).

The only thing that proves someone learned is testing their behavior again weeks later, with a different scenario, and seeing whether this time they stop. That is the retest, and we explain it separately in What a retest is and why it proves behavior changed. Without that second test, an employee who "passed the course" and an employee who genuinely changed look exactly the same, until the day the real attack arrives.

At Fensivo we work on exactly that point: preparing each person's behavior against email-based deception with personalized simulations, delivering the training in the minute of the failure and, above all, validating the change with a retest three weeks later. We do not chase the attacker's infrastructure or promise to stop session theft or OAuth abuse by technical means; our ground is the person's decision, which is what these six techniques exploit. You can see how we approach it in our use cases.

So the next time someone tells you they have already enabled MFA across the whole company, it is worth asking: would your people know not to approve that code, not to authorize that app, not to give in to the tenth midnight push? And do you have a way to check it before an attacker does?

Sources and references

• CISA, "4 Things You Can Do To Keep Yourself Cyber Safe": https://www.cisa.gov/news-events/news/4-things-you-can-do-keep-yourself-cyber-safe
• Cisco, "The 90-5-5 Concept: Your Key to Solving Human Risk in Cybersecurity", 2025: https://blogs.cisco.com/security/the-90-5-5-concept-your-key-to-solving-human-risk-in-cybersecurity
• Microsoft, "Microsoft Digital Defense Report 2025": https://www.microsoft.com/en-us/security/security-insider/threat-landscape/microsoft-digital-defense-report-2025
• Ho, G. et al., "Understanding the Efficacy of Phishing Training in Practice", 2025 IEEE Symposium on Security and Privacy: https://ieeexplore.ieee.org/document/11023357
• Lain, D., Kostiainen, K. and Čapkun, S., "Phishing in Organizations: Findings from a Large-Scale and Long-Term Study", 2022 IEEE Symposium on Security and Privacy: https://ieeexplore.ieee.org/document/9833766