We still hear some version of "we're fine, we have MFA" at least once a week. It's usually said with real confidence, and it's usually wrong, or at least incomplete. Having MFA turned on somewhere in your tenant is not the same thing as having MFA that actually resists the attacks criminals are running right now.
The attack that doesn't need to break anything
One of our clients had an admin who got 37 push notifications between 1:50am and 2:40am. Thirty-seven. He finally tapped approve on the 38th just to make his phone stop buzzing, assuming it was some kind of glitch. It wasn't a glitch. It was an attacker who already had his password from a previous breach dump, sitting there spamming the login attempt until exhaustion did the work that a password alone couldn't.
This is called MFA fatigue, or push bombing, and it's one of the most common ways we see otherwise well-protected accounts get taken over. It doesn't exploit a vulnerability in Microsoft's or Google's authentication system. It exploits a 2am brain that just wants the noise to stop.
The other ways MFA gets walked around
- SIM swapping. If your second factor is a text message, an attacker who convinces (or bribes) a mobile carrier employee to port a number can intercept that code without touching your network at all.
- Adversary-in-the-middle phishing kits. Tools like Evilginx sit between the user and the real login page, capturing the session cookie after MFA succeeds. The user thinks they logged in normally. The attacker now has a live, authenticated session and never needed the password again.
- Legacy authentication protocols. Older protocols like SMTP AUTH, IMAP, and POP3 were built before MFA existed, and if they're still enabled on a mailbox, they can often bypass modern authentication entirely.
- Help desk social engineering. A confident phone call to IT support claiming a lost phone has reset more MFA registrations than any piece of malware we've seen this year.
MFA fatigue attacks don't need a vulnerability. They need an exhausted employee at 2am who just wants the notifications to stop.
What actually reduces this risk
None of this means MFA is a bad idea. It remains one of the highest-value controls a business can put in place. It just means the version of MFA most companies have isn't the version that holds up under a real attempt. Here's what we push clients toward:
- Turn on number matching and additional context. Instead of a single tap, the user has to enter a number shown on the sign-in screen. It sounds small, but it kills the vast majority of fatigue attacks because the attacker can't see what number to feed the victim.
- Disable legacy authentication protocols tenant-wide. Unless you have a very specific, documented reason to keep SMTP AUTH or similar enabled, turn it off. Most businesses don't need it and don't even know it's on.
- Move privileged accounts to phishing-resistant MFA. FIDO2 security keys or Windows Hello for Business bind the login to a physical device or hardware trust, which adversary-in-the-middle kits can't intercept the same way.
- Lock down identity verification at the help desk. Require a callback to a pre-registered number, or manager approval, before resetting MFA on any account, especially privileged ones.
- Watch for impossible travel and session anomalies. If a login looks normal but the location, device, or application pattern doesn't match the user's history, that's worth an alert, not a shrug.
- Tie access to device compliance through conditional access. A stolen session cookie is far less useful to an attacker if your policies also check whether the device itself is managed and healthy.
Most of the businesses we work with didn't choose any of this on purpose. The defaults got turned on during setup, legacy protocols got left running because nobody wanted to break the finance department's old email tool, and the help desk process was written by whoever was busiest that week. None of it was a deliberate decision. That's exactly why it's worth having someone look at it with fresh eyes.