MFA Is On. That Doesn't Mean You're Protected.

Why MFA Coverage Is Not the Same as MFA Protection

Most small businesses that have deployed multi-factor authentication believe they've solved the authentication problem. In most IT conversations, MFA is the starting point - "the low hanging fruit". It's assumed the basics are covered once enabled. The dashboard shows MFA enabled. The box is checked. But coverage and protection are not the same thing, and the gap between them is exactly where account compromises happen.

Registration gaps

Enabling MFA in a tenant does not mean every user has completed MFA registration. It means the policy exists. Until a user completes enrollment, they typically authenticate with password alone, and in many tenants, that window stays open indefinitely.

This is especially common with shared mailboxes, service accounts, employees who were onboarded before MFA was required, and anyone who dismissed the registration prompt. A tenant can show 95% MFA adoption and still have many unprotected accounts, often belonging to the people with the most access.

Legacy authentication

This is the most consistently exploited a frequently overlooked gap in M365 environments.

Legacy authentication protocols, such as SMTP, IMAP, POP3, MAPI, and older Office client connections, were built before modern authentication existed. They cannot perform MFA challenges. An attacker with a valid credential can authenticate directly through these protocols, bypassing Conditional Access entirely.

If legacy authentication is not explicitly blocked, MFA is not a complete control. The attacker simply navigates around it.

Exclusions and exceptions

Conditional Access policies are only as strong as their scope. In practice, most tenants accumulate exceptions, sometimes for legitimate reasons, sometimes because something broke and an exclusion was the fastest fix.

Commonly, specific users are excluded from MFA policies because they complained, service accounts are excluded because a legacy integration broke, IP-based trusted location rules haven't been reviewed since the company went remote, and named locations are far broader than intended. Each exclusion weakens the control. Enough of them, and the control is rendered ineffective.

But even a well-constructed Conditional Access policy can have exploitable gaps.

Token theft is increasingly common. An attacker who steals a valid session token through adversary-in-the-middle phishing inherits an already-authenticated session. MFA was completed legitimately by the real user. The attacker uses the resulting token and therefore, Conditional Access sees a valid, compliant session.

Device compliance policies that don't account for personal devices, named location rules built around IP ranges that have never been audited, and session lifetime settings that leave tokens valid for hours or days — all of these mean a stolen session can outlast the response to the breach that created it.

Break-glass accounts

Break-glass accounts are emergency administrator accounts intended to be used when normal authentication mechanisms fail, for example, when locked out of primary admin, the MFA system is down, or there is an identity provider outage. They exist for good reasons.

However, they are commonly misconfigured and excluded from MFA requirements and from Conditional Access policies, and often use passwords that haven't been reset in years. Moreover, these accounts typically hold Global Administrator privileges. If discovered and compromised, the attacker has unrestricted tenant access with no authentication hoops to jump through.

Properly managed break-glass accounts are tightly controlled, monitored, and secured with physical credential storage (i.e., stored somewhere physically secured). In most SMB tenants, they're just forgotten admin accounts with no guardrails.

What this means practically

MFA is necessary; however, it's not sufficient. The questions that matter are not "do we have MFA?" but rather:

• Is legacy authentication blocked for all users and protocols?

• Are there accounts that have never completed MFA registration?

• When were Conditional Access policy exclusions last reviewed?

• Are break-glass accounts monitored and inventoried?

• Is there protection against token theft, or does MFA stop at the initial sign-in?

  
  

If the only question you can answer is whether MFA is turned on, you don't have MFA protection, you have MFA coverage. The dashboard still shows MFA enabled. The box is still checked. And the gap is still there.