MFA is enabled. That doesn't mean you're protected.

We do a lot of security assessments where the client tells us confidently that MFA is deployed across the organization, then we run through the actual configuration and find three or four gaps that, combined, mean the attacker doesn't really have to defeat MFA at all — they just have to find the exemption.

MFA is one of the highest-value security controls a business can deploy. It genuinely does stop the vast majority of credential-based attacks. But "we have MFA" is only true if it's true for every account, every login path, and every session. Here are the gaps we see most often.

Gap 1: The admin exemption

MFA is rolled out to staff. The owner and two admins say "the constant prompts drive me crazy, exempt me for now." Six months later, "for now" has become permanent. Those three accounts have the highest privileges in the tenant. An attacker who compromises one of them has full tenant control.

This gap is common because it feels like a small compromise ("it's just me, I know how to spot phishing"), but the math doesn't work. Attackers specifically target admin accounts because the payoff is so much bigger. Every phishing simulation we run finds at least one admin who clicks — and in the real world, one click on an admin without MFA is a full breach.

Fix: Conditional Access policy in Microsoft 365 that requires MFA on every account with any admin role. No exemptions. If the extra prompts are annoying, that's what Windows Hello and hardware security keys are for.

Gap 2: Legacy authentication still on

MFA only works on modern authentication protocols. If legacy protocols (Basic Auth, older POP/IMAP, ActiveSync in some configurations) are still enabled in your tenant, an attacker who has valid credentials can bypass MFA entirely by using a legacy client to authenticate. This is one of the most common paths to business email compromise even in "MFA-enabled" tenants.

Microsoft has been disabling legacy auth by default in new tenants for a couple of years now, but older tenants often still have it on for compatibility with old email clients or applications that nobody's ever audited.

Fix: disable legacy authentication in the Microsoft 365 admin center, plus a Conditional Access policy that blocks it explicitly. Any application that breaks needs to be updated to use modern auth, not exempted.

Gap 3: SMS as the MFA factor

SMS-based MFA is much better than no MFA. But SMS can be intercepted through SIM swap attacks, and attackers targeting high-value accounts have been known to do exactly that. In 2026, SMS should be your fallback, not your primary MFA factor.

Fix: use authenticator apps (Microsoft Authenticator, Google Authenticator, Authy) as the primary factor, with SMS as backup only for account recovery. For high-privilege accounts, consider hardware security keys (YubiKey or similar) as the primary factor.

Gap 4: MFA fatigue attacks

This is the newer one. An attacker has valid credentials (usually from a breach dump or from a phish). They try to log in and trigger an MFA prompt on your phone. You dismiss it. They try again. And again. Fifty prompts in a row at 2 AM. Eventually a tired user hits Approve just to make the prompts stop.

This has been a real attack vector in serious breaches (Uber 2022, several others since). It works because push-notification MFA is designed to be frictionless — one tap and you're in. That same frictionlessness is the vulnerability.

Fix: switch push MFA to "number matching" mode, where the user has to type a code shown on the login screen into the authenticator app (not just approve a prompt). Microsoft Authenticator supports this. It adds two seconds to legitimate logins and completely eliminates the fatigue attack vector because the attacker doesn't have the number to give you.

Gap 5: Session token theft

This one is the newest and hardest to defend against. Modern attacks (adversary-in-the-middle phishing kits like EvilProxy) don't try to steal your password anymore. They set up a fake login page that proxies your real login through to Microsoft or Google, capture the resulting session cookie, and log in as you from their infrastructure. MFA happened — but for the attacker's session, not yours. From Microsoft's perspective, the login is legitimate.

This is why MFA alone is no longer sufficient for high-value targets. You need Conditional Access policies that also check things like device health, location, and sign-in risk score — so even a valid session token from an unusual device or country gets blocked or challenged.

Fix: Conditional Access with device-compliance requirements (only company- managed devices can access certain resources), sign-in risk policies (block or step-up when Microsoft's risk engine flags the login), and shorter token lifetimes for privileged accounts.

How to actually check where you stand

The self-diagnostic:

1. How many accounts in your tenant have zero MFA methods enrolled? (Should be zero.)
2. How many admin accounts have MFA exemptions in Conditional Access? (Should be zero.)
3. Is legacy authentication still enabled anywhere? (Should be no.)
4. What's the primary MFA method for your admin accounts — authenticator app, SMS, or hardware key? (Should be authenticator or key, not SMS.)
5. Do you have number-matching turned on for push MFA? (Should be yes.)
6. Do you have Conditional Access checking device compliance for admin roles? (Should be yes, if you have Business Premium or above.)

If you can't answer any of these, that's a signal. Our Comprehensive Security Assessment includes a full audit of MFA and Conditional Access posture as part of the Identity and Access Management section — priced from $2,500 one-time, and typically pays for itself the first time it catches a gap that would have turned into a breach.