If We Have MFA, How Are Accounts Still Getting Hacked?

You've probably been told some version of the same cybersecurity advice for years: use a strong password, don't reuse it, and turn on multi-factor authentication.

So that's exactly what you do. Your password is 12+ characters long, and MFA is enabled. Your phone is sitting right next to you. You haven't given anyone your verification code.

But somehow, an attacker is logged into your account.

How did that happen?

The answer isn't that MFA doesn't work. MFA is one of the best things we have for preventing account takeovers, especially when a password has been stolen.

The problem is that attackers know this too.

So instead of only asking, "How do I get this person's password?", attackers have gotten much better at asking a different question:

"How do I get around the part where MFA protects them?"

First, What Is MFA Actually Doing?

Let's say you're logging into your work account. You enter your username and password. That's one factor: something you know.

Then your phone asks you to approve the login. That's another factor: something you have.

The basic idea is that stealing one credential shouldn't be enough to impersonate you. If an attacker gets your password in a data breach, they still shouldn't be able to log in because they don't have your second factor.

That's a huge improvement over passwords alone. But there's an important detail hidden inside this process. MFA primarily helps prove your identity during authentication.

Once you've successfully logged in, the application doesn't ask you for your password and MFA code every time you click something. That would be incredibly annoying.

Instead, it creates a session.

Your browser receives something like a session cookie or token that essentially tells the application:

"We've already authenticated this user. They're good."

So now what happens if an attacker doesn't steal the thing you use to prove your identity? What if they steal the thing that says you've already** proved it?**

Attack #1: Just Annoy You Until You Say Yes

Imagine you're sitting on your couch and suddenly your phone asks:

Approve sign-in?

You didn't try to log in, so you hit deny. Thirty seconds later, another request appears.

Deny.

Then another…And another.

Maybe one arrives while you're distracted. Maybe you're expecting to log into something for work anyway. Maybe the attacker sends so many that eventually you assume something is broken and press Approve just to make them stop.

This is often called MFA fatigue or MFA bombing.

The attacker may already have your username and password. The only thing standing between them and your account is you approving that second factor. So they turn the security control into an annoyance.

What's interesting about this attack is that the attacker hasn't technically "broken" MFA. MFA did exactly what it was designed to do. It asked the legitimate user for approval. The attacker attacked the human interaction with the control instead.

That's why newer authentication systems have introduced protections such as number-matching, additional login context, rate limiting, and stronger phishing-resistant authentication methods.

But attackers have another option.

What if they can convince you that you're logging into the real website?

Attack #2: Put the Attacker in the Middle

Most people understand a traditional phishing page. You receive an email saying something like:

"Your Microsoft 365 session has expired. Sign in to continue."

So click on the link, and the page looks legitimate. You enter your password, but now the fake website records it.

MFA makes this type of basic credential theft much less useful because the attacker still needs your second factor.

So a more sophisticated phishing attack can introduce something between you and the legitimate service.

You → Attacker's phishing site → Real login page

Instead of creating a completely fake login experience, the attacker acts as a proxy between you and the real authentication service.

You enter your username and password. The attacker then forwards them to the legitimate website. The legitimate website says, Great. Now I need MFA. That MFA request comes back through the attacker to you. Once, you approve it, the attacker forwards that too.

From your perspective, you just successfully logged in. From the legitimate service's perspective, you also successfully logged in.

And sitting in the middle is the attacker.

This type of technique is often described as adversary-in-the-middle (AiTM) phishing. The attacker didn't crack your password nor defeat the cryptography behind MFA. All they had to do was convince you to complete the authentication process for them.

Attack #3: Steal the Proof That You Already Logged In

After your password and MFA are successfully verified, the application needs some way to remember that you're authenticated. Depending on the application and authentication architecture, that might involve session cookies, access tokens, refresh tokens, or other authentication artifacts.

You don't normally see any of this. You just notice that you don't have to enter your password every time you open another email or navigate to another page. But those artifacts can be extremely valuable.

Think of it like you're about to go to a concert. At the entrance, security checks your ticket and ID. Once they've verified you, they put a wristband around your wrist. Inside the venue, nobody asks to see your ID and ticket every five minutes. They look at the wristband. The difficult identity check already happened.

Now imagine someone could perfectly steal your wristband.

They wouldn't necessarily need your ticket. They wouldn't need your ID. And they don't need to convince security to check them again.

They have the one thing that says:

"This person has already been checked."

A stolen authenticated session can create a similar problem.

If an attacker obtains a usable session artifact and the service accepts it, the attacker may be able to act within an already-authenticated session without triggering the exact same login flow again. Which means there may be no new MFA prompt to defeat.

So…Is MFA Useless?

No.

And this is where cybersecurity advice sometimes gets weird. Someone hears about attacks that can bypass certain MFA flows and concludes:

"Well, I guess MFA doesn't work anymore."

That's like hearing that someone stole a badge to enter an office and concluding that access badges are useless.

Security controls don't have to stop every possible attack to be valuable.

MFA dramatically raises the cost of account compromise compared with passwords alone. A stolen password that once gave an attacker immediate access may now be insufficient. The attacker's job becomes harder.

But security is rarely about finding one magical control and declaring the problem solved. It's all about layers.

Not All MFA Is the Same

Even the phrase "I have MFA enabled" can mean very different things.

SMS codes are MFA. One-time codes from an authenticator app are MFA. Push notifications are MFA. Hardware security keys are MFA. Passkeys can provide strong phishing-resistant authentication.

But these methods don't all respond to phishing in the same way.

A six-digit code can potentially be entered into the wrong website. A push notification can potentially be approved by the wrong person at the wrong time. Phishing-resistant methods such as FIDO2/WebAuthn-based security keys and passkeys are designed differently. Authentication is cryptographically tied to the legitimate website, making it much harder for an attacker operating a fake domain or proxy to simply capture and replay what the user provides.

That's an important evolution. We went from asking:

"Can we add another step to the login?"

to asking:

"Can we make that step difficult to give to the wrong website in the first place?"

Authentication Isn't the Finish Line

There's a bigger security lesson hiding underneath all of this. For a long time, we treated authentication like a gate.

You're outside → You prove who you are. → The gate opens. → You're inside.

But modern security architecture can't assume that everything is trustworthy simply because authentication succeeded.

Credentials can be stolen. Users can be tricked. Devices can be compromised. Sessions can be hijacked.

That's why organizations layer authentication with other controls: short-lived sessions, token protection, device checks, conditional access policies, risk-based authentication, session revocation, behavioral analytics, logging, monitoring, and requiring users to reauthenticate before particularly sensitive actions.

The question isn't only:

"Did this person successfully complete MFA?"

It's also:

"Does what they're doing after authentication still make sense?"

An employee who normally logs in from Chicago at 9 a.m. suddenly authenticating from somewhere unusual might deserve another look.

An account that normally downloads five documents suddenly downloading 5,000 might deserve another look.

A user suddenly attempting administrative actions they've never performed before might deserve another look.

Authentication gives us evidence about identity but it doesn't necessarly give us unlimited trust. The goal isn't just to make sure the right person gets in, it's to make sure what happens afterward still looks like the right person.

MFA raised the bar for attackers, but it didn't eliminate the attack surface. As authentication gets stronger and stronger, securing what happens before, during, and after login becomes just as important.