Why your MFA rollout probably has a gap

"We have MFA on everything" is the most common sentence we hear right before finding an account that does not. This is not a criticism of the companies; it is a pattern in how identity systems actually work, and it is worth understanding before you assume you are covered.

The legacy protocol gap

Modern MFA policies apply to modern sign-in flows. Legacy protocols like IMAP, POP and older SMTP auth often bypass conditional access entirely unless they are explicitly disabled. In our audits, roughly 70% of companies had at least one of these still enabled tenant-wide, usually for a single old integration nobody remembers configuring.

The service account gap

Service accounts used for automation are frequently exempted from MFA because MFA cannot easily be automated, and then never revisited. We have found service accounts with domain admin rights and no MFA, protected only by a password that had not been rotated in three years.

The break-glass account gap

Every tenant needs an emergency account that works if the identity provider itself has an outage. These accounts are, by design, often exempt from the policies that apply to everyone else, which makes them the highest-value target in the tenant if their credentials leak.

• Audit legacy auth protocols explicitly; do not trust a policy summary that says 'enforced'.

• Inventory every service account and its actual permission level, not its intended one.

• Rotate break-glass credentials on a schedule and store them somewhere separate from the rest of your password vault.

"Enforced" MFA is a policy statement. Whether it is actually enforced everywhere it needs to be is a question you have to go and check, not assume.