We get past MFA on most engagements, and we almost never break it. Here is how, and what actually stops us.

MFA WON THE LAST WAR

Give MFA its due, because it earned it. For years the dominant way into an organization was a password, and passwords were a disaster: reused across sites, dumped by the billion in breach corpuses, sprayed and stuffed at scale by anyone with a list and a script. MFA broke that economy. Once a second factor stood between a stolen password and a live session, the password alone stopped being enough, and a whole category of cheap, high-volume attacks lost its payday. That is a real win, and it is why MFA is rightly considered table stakes. If you do not have it, the rest of this is academic: turn it on first.

But attackers are not sentimental, and they do not keep fighting a war they have lost. When the password stopped being the prize, they did not try harder to guess passwords. They looked at the whole login system and asked a simpler question: what is the softest thing here that still gets me a session? The answer was almost never the prompt itself. It was the moment just after the prompt, the people standing next to it, and the weaker doors left unlocked behind it. That is where we live on an engagement, and it is worth walking through how, because the pattern is consistent and the fixes are knowable.

WE DON'T BREAK MFA. WE GO AROUND IT.

The mental model that matters is this: MFA authenticates an event. You prove who you are at the instant of login, the system is satisfied, and it mints you a session, a token in your browser or app that says "this one is allowed, do not ask again for a while." That token is the thing of value. The prompt is just the turnstile in front of it. Almost everything we do is aimed at getting a valid session without ever standing at that turnstile ourselves, or by getting you to walk through it for us.

The session is the prize. This is the route you saw in our debrief this week. Infostealers like the Atomic macOS Stealer, and malicious browser extensions like the Edgecution campaign, are not after your password. They are after the live session cookies already sitting in your browser, the ones minted after you sailed through MFA this morning. Lift those, replay them from our infrastructure, and the application treats us as you, mid-session, no prompt required. You did everything right. You used a strong password and a second factor. It does not matter, because we did not attack the login. We attacked the thing the login produced.

Adversary-in-the-middle gets you to do it for us. When we do want fresh access, we often do not phish a password and an MFA code as two separate prizes. We stand a reverse proxy between you and the real login page. You click our link, you see what looks like the genuine sign-in, you type your password, you approve the real MFA prompt on your real phone, and everything works, for you. In the same instant, we capture the session the real service hands back. This is not theoretical. Microsoft has tracked adversary-in-the-middle campaigns that hit more than ten thousand organizations, stealing passwords and hijacking sessions even where MFA was fully enabled. From the victim's side it is invisible, because nothing failed.

Push fatigue beats the strongest second factor in the world. If your MFA is a push approval, we do not need to defeat it. We need to be annoying. We trigger approval after approval, often at the end of a long day or the middle of the night, until someone taps approve to make their phone stop buzzing, or because they assume a coworker kicked off a legitimate login. The cryptography is flawless. The human holding the phone is the bypass, and the human is always in scope.

The help desk is part of your MFA whether you planned it that way or not. Every MFA deployment has a reset path, because real people lose phones and get locked out. That path is a target. We call support, we present as one of your employees, we sound stressed and credible, and we ask them to reset or re-enroll the second factor to a device we control. This is the signature move of the most effective intrusion crews operating today, and it works because the reset process is usually softer than the login it protects. You can buy the best authenticators on the market, and a five-minute phone call to an undertrained help desk hands us the keys anyway.

The weakest factor you still accept sets the real bar. Many environments roll out strong MFA but leave weaker methods enabled as a fallback: SMS codes that a SIM swap intercepts, email codes, or legacy flows. We do not engage the strong factor; we ask for the weak one. The same logic applies to OAuth consent and device-code phishing, where we get you to authorize an application or approve a sign-in through a legitimate flow, and the platform issues us tokens with MFA already considered satisfied. Your security is set by the weakest option you still allow, not the strongest one you advertise.

Your security is set by the weakest option you still allow, not the strongest one you advertise.

And we rarely rely on just one of these in isolation. A real intrusion chains them. We might use adversary-in-the-middle to capture a first session, then call the help desk to enroll our own authenticator so the access survives the original cookie expiring, then leave a weak fallback in place as a quiet way back in for when the first path gets noticed. Each route covers a different weakness in the same system, and used together they are far more durable than any one of them alone. This is also why fixing a single route is rarely enough. Close the session theft and we move to the help desk. Harden the help desk and we go looking for the fallback you left enabled. The system has to be treated as a system, which is the entire argument of this piece.

WHY THIS KEEPS WORKING

The uncomfortable common thread is that none of these are exotic, and none of them are bugs in MFA. They are the predictable result of treating MFA as a checkbox instead of a system. Organizations buy MFA, measure it as a coverage percentage, "ninety-six percent of accounts have MFA enabled," and report it as done. But coverage is the wrong metric, because the attacker is not testing your coverage. The attacker is testing the three soft edges that coverage does not capture: the session that lives on after the prompt, the humans who can reset the factor, and the weaker factors still accepted as backup.

There is also a quieter reason it persists. The fixes are friction, and friction loses to convenience until someone forces the issue. Phishing-resistant factors require enrollment and hardware or platform support. Short session lifetimes mean people re-authenticate more often. Locking down the help desk means a slower, more suspicious reset experience for legitimately locked-out staff. Every one of these is a small tax on daily work, and so they get deferred, and the deferral is invisible right up until the morning it is not. We are, in effect, paid to make that deferral visible before someone less friendly does.

If you want one question to ask your own team, make it this: not "what percentage of our accounts have MFA," but "if an attacker held a valid session token for our CFO right now, how long would it keep working, from how many devices, and who would notice." The first question has a comfortable answer that means very little. The second has an uncomfortable answer that tells you exactly where you stand. The distance between those two questions is the distance between a checkbox and a control.

WHAT ACTUALLY RAISES THE BAR

Here is the good news, and it is genuinely good: the organizations that stop us are not the ones with the highest MFA coverage. They are the ones who understood that MFA secures a moment and built controls around everything after it. The list is knowable and most of it is achievable this quarter.

Move to phishing-resistant MFA, and mean it. FIDO2, WebAuthn, passkeys, and PKI-based methods are what CISA calls the gold standard, and the reason is simple: the credential is cryptographically bound to the real origin and never leaves the device. Our reverse proxy cannot relay it because it is not the real domain, and there is no code to phish because there is no code. This single change shuts down adversary-in-the-middle and one-time-code phishing at the same time. It is the highest-leverage move on this entire page.

The usual objection is that this is hard, that users resist new authenticators and that some legacy applications cannot support them. Both are true, and neither is a reason to wait. Passkeys, FIDO2, and WebAuthn are now built into every major operating system and browser, which has quietly removed most of the cost that made this a multi-year project not long ago. The realistic path is not all-or-nothing. Classify applications by risk and put phishing-resistant MFA in front of the high-value ones first, the email, the identity provider, the admin consoles, and remote access, then migrate the long tail on a schedule. Start where a stolen session does the most damage rather than waiting for a perfect rollout that never arrives.

Retire the weak fallbacks. Phishing-resistant MFA does nothing if SMS is still an accepted backup for the same account, because we will simply ask for the backup. Pick the strong factor and remove the weak ones for anything that matters. Your real security level is whatever your weakest enabled method allows.

Harden the session, not just the login. Shorten session lifetimes so a stolen token dies quickly. Require re-authentication for sensitive actions. Where your platform supports it, bind sessions to a device so a cookie lifted onto our machine simply does not work. Layer conditional access on device posture, location, and risk. The goal is that authenticating once stops being a permanent pass.

Treat the help desk as a security control. Require real identity proofing before any MFA reset, use callbacks to known numbers, refuse resets over chat, and alert on every reset and re-enrollment event. This is where the most capable crews concentrate, precisely because it is where MFA is usually softest.

Watch the session, not just the gate. MFA is a one-time check at the door. You also need continuous signal: stolen-token reuse, impossible travel, a session token suddenly used from a new device or network, anomalous behavior inside an authenticated session. The login passing is not proof that the session belongs to the person who passed it.

Test it, do not assume it. "We have MFA" and "our accounts are hard to take over" are different sentences, and the gap between them is exactly what an assumed-breach engagement measures. Have someone actually run these routes against you, find which one works, and watch how far a single stolen session travels before anyone notices.