Your organization deployed multi-factor authentication. The board slide says coverage is at 98%. The compliance auditor signed off.

And attackers are walking past it every single day.

Not by guessing codes. Not by intercepting texts. By exploiting the one thing nobody in the room thought to question — the assumption that having MFA is the same as being protected by it.

Multi-factor authentication is the most widely deployed security control of the last decade. Banks require it. Cloud providers push it. Every security framework recommends it. And for good reason — it genuinely raises the cost of attack.

But here's the uncomfortable truth the industry rarely says out loud: the attack data from 2024 and 2025 shows MFA bypasses have become routine. Not novel. Not nation-state. Routine. The kind of attack any moderately skilled actor can execute with off-the-shelf tooling sold on Telegram for under two hundred dollars a month.

The problem isn't that MFA is broken. The problem is that most organizations deployed it without understanding what it actually protects against — and what it doesn't.

Security teams implemented MFA believing it solved authentication. If an attacker steals a password, MFA stops them. That's the mental model.

The assumption underneath that model is that the attacker is trying to log in as the user. But sophisticated attackers stopped doing that years ago. They don't want your login — they want your session. And once a user has already logged in and completed MFA, the session token that proves who they are becomes the most valuable thing on their machine.

If you can steal the session, MFA becomes irrelevant. The user already passed it for you.

The most common real-world bypass looks nothing like hacking. It looks like a user logging into a perfectly normal Microsoft or Google page — except the page isn't Microsoft or Google. It's an attacker's proxy sitting invisibly between the user and the real service.

This is called adversary-in-the-middle, and the tooling has been commoditized. Frameworks like Evilginx let an attacker stand up a phishing site that transparently relays every request to the legitimate login page. The user sees the real Microsoft login. Enters their real password. Gets the real MFA prompt on their real phone. Approves it. And logs in successfully — to the real service.

The only catch is that the attacker's proxy captured every piece of that interaction, including the session cookie the service issued after MFA succeeded. That cookie is now replayed from the attacker's machine. They're inside the account. No second MFA challenge is triggered because the session is already authenticated.

The second pattern is even simpler: MFA fatigue. An attacker with stolen credentials tries to log in at 2 AM and sends the user twelve push notifications in a row. The user, half-asleep, taps approve to make the buzzing stop. That's not a technical bypass. That's a human one — and the MFA system worked exactly as designed.

Then there's the quieter category: session hijacking through malware, OAuth consent phishing where users grant persistent access to a malicious app, and help desk social engineering where attackers call in pretending to be an executive whose phone was stolen and ask for MFA to be reset. None of these defeat MFA. They route around it entirely.

Here is the shift in thinking that matters: MFA is not a control that protects accounts. It is a control that protects the act of logging in. Everything that happens after a successful login — the session, the tokens, the permissions — is protected by something else entirely. And in most organizations, that something else doesn't exist.

The question worth asking isn't whether you have MFA. It's what happens in the minutes, hours, and days after an authenticated session is established. Can your systems detect a session cookie being replayed from a different device? Does an impossible travel event — logging in from Toronto at 9 AM and Mumbai at 9:05 AM — actually trigger anything? Can a user's active session be forcibly terminated the moment something looks wrong?

If the answers are no, your MFA deployment is protecting the front door while leaving every window on every floor wide open.

Most of what the industry calls "MFA coverage" is actually just login coverage. The harder problem — continuously verifying that an authenticated session still belongs to the person who authenticated it — is where the real defense work lives. And almost nobody has done it well yet.

Tell me something honestly: when was the last time your organization questioned whether MFA was actually stopping the attacks you think it's stopping? Hit reply — I genuinely want to know.

Think clearly.

— DJ Brar SKBSEC | SKB Decoded www.skbsec.com