The Conditional Access exclusions that quietly undo MFA
Most tenants I review have MFA "enforced". Most of them also have a handful of exclusions that mean it isn't. Here is where they hide.
When I'm asked to look at a Microsoft 365 tenant, the first thing I check isn't whether MFA is turned on. It almost always is. The question is who it is turned on for, and the answer is usually "everyone, except...".
Those exceptions are the interesting part. Every one of them was added for a reason that made sense on the day. Nobody went back.
Where the gaps live
The exclusion group that grew. The policy excludes a group called something like CA-Exclude-MFA. It was created for one vendor account during a migration. Two years later it has forty members: ex-contractors, a shared mailbox someone signs into, the CEO's assistant, a few people who "had trouble with the app". Open the group and read the membership. Then ask who owns it. Nobody will.
Break-glass accounts without a fence. You should have emergency access accounts excluded from Conditional Access; that part is right. But they need a long random password in a safe place, no licences, and an alert the moment they sign in. Half the tenants I see have the exclusion and none of the rest.
Trusted locations. "Don't prompt for MFA from the office" was a kindness in 2019. It is now a policy that says anyone on the office Wi-Fi, including the guest network if the ranges overlap, is trusted. Check the named location's IP ranges against what the network team actually runs today. They have usually changed.
Selected apps instead of all apps. A policy targeting "Office 365" and a few named apps leaves everything else open: Azure management, Graph Explorer, third-party apps registered later. Target all resources and exclude deliberately, not the other way around.
Device platform conditions. A policy that only applies to Windows and macOS is a policy that doesn't apply to anything that presents a different user agent. Platform is a hint, not a control. If the intent is "only managed devices", say that with a device compliance or hybrid join requirement.
Report-only forever. A well-designed policy sitting in report-only mode for eighteen months is doing exactly nothing. Report-only is a staging step, not a destination.
How I find them
- Export every policy. The Entra portal will do it one at a time; the Graph PowerShell module will do it in one go:
Get-MgIdentityConditionalAccessPolicy | ConvertTo-Json -Depth 10. - For each policy, list the excluded users, groups and roles. Resolve the groups to people.
- Open the sign-in logs, filter for interactive sign-ins where Conditional Access shows Not applied or Success with no MFA, and look at who those accounts are.
- Use the What If tool for the accounts you're worried about. It is the fastest way to see what a specific person is actually subject to.
The output of that is a short list of named accounts that can sign in with a password alone. That list is the real MFA coverage of the tenant, whatever the dashboard says.
Fixing it without breaking things
Don't delete the exclusion group. Empty it one member at a time, with a reason recorded against each removal, and give each person a week's warning. Vendor accounts move to a policy of their own with a tighter scope. Shared mailboxes stop having people sign into them directly. The break-glass accounts get their alert.
It's unglamorous work. It is also the single change that most improves a tenant's security posture, because the attacker doesn't care about your policy. They care about the forty accounts it doesn't cover.
Written from the field, not a lab. If something here has changed since, it probably has; the newer posts are the place to look.