How to Audit Conditional Access Policies Across Multiple M365 Tenants

Conditional Access is one of the highest-leverage security controls in Microsoft 365 — and one of the easiest to get quietly wrong. A tenant can look secure at a glance and still have zero enforced policies, or policies with exclusions broad enough to make them meaningless. Here's what to actually check, and why doing it by hand across more than a couple of tenants stops being practical fast.

What "good" Conditional Access actually looks like

At minimum, a well-configured tenant should have:

At least one policy requiring MFA for all users, with a tightly scoped exclusion list (break-glass accounts only, not "anyone who complained about the prompt").
Legacy authentication blocked — protocols like IMAP, POP, and older Office clients can't satisfy MFA at all, so a Conditional Access policy that doesn't address them leaves a wide-open bypass.
Policies actually enabled, not sitting in "Report-only" mode indefinitely. Report-only is a legitimate staging step — the problem is when it never graduates to enforced.
No accidental full-tenant exclusion — a policy scoped to "All users" with an exclusion group that turns out to include most of the company.

The most common real-world gaps

In practice, the same few issues show up over and over:

Zero enabled policies. Not misconfigured — just never turned on. This happens more than you'd expect, especially in tenants that were set up quickly and never revisited.
Security Defaults and Conditional Access both off. Worth calling out specifically: Security Defaults is Microsoft's free baseline (enforces MFA tenant-wide, no license required), and it's a legitimate alternative to Conditional Access for a tenant without Entra ID P1. The real problem is a tenant with neither — no baseline MFA enforcement of any kind.
Legacy auth allowed by omission. The tenant has an MFA policy, but nothing blocking legacy protocols — so an attacker with a stolen password can often still get in through a channel the policy never considered.
Break-glass accounts that aren't actually excluded correctly, or conversely, an exclusion list that's grown well beyond the two accounts it should be.

The manual approach — and where it breaks down

Microsoft's own "What If" tool is genuinely useful for testing how a specific sign-in would be evaluated against your policies, one tenant at a time, one scenario at a time. It's the right tool for debugging a single policy. It is not a tool for auditing posture across ten tenants on a Tuesday morning.

Checking Conditional Access by hand means logging into each tenant, opening the policy list, checking each policy's state and scope individually, and doing it again next month to see what changed. That's a workflow that holds up for one or two tenants and quietly becomes your whole Tuesday once you're past five.

Why this needs to be a repeatable check, not a one-time audit

Configuration drifts. A policy someone set to Report-only "temporarily" during a rollout stays that way for eight months. An exclusion group grows. The point of an audit isn't just catching a problem once — it's catching it again, the next time it happens, without redoing the manual work from scratch.

This is exactly the kind of check ScopedIQ automates as part of its security scan: a live read of each connected tenant's Conditional Access policies (and Security Defaults status, cross-referenced so a tenant using Conditional Access properly isn't falsely flagged for having Security Defaults off), across every client tenant, on one dashboard — re-run on demand instead of re-checked by hand.