Conditional Access is the policy engine that decides who gets into your Microsoft 365 tenant, from where, on what device, and with what risk. When it is right, it is the strongest control you own. When it is subtly wrong, it gives you a false sense of security that is worse than no policy at all.
Most teams have Conditional Access policies. Far fewer have audited them. This guide covers what to check, the failures that hide in plain sight, and how to audit policies without reading JSON one by one.
Why auditing Conditional Access is different
Everyone talks about setting up Conditional Access. The harder problem is auditing the policies you already have. A tenant with ten enabled policies can still be wide open because:
- One policy excludes "All users" or a break-glass account that is used daily
- A policy grants MFA but only for a subset of apps
- Legacy authentication is not blocked anywhere
- A policy exists but is in "Report-only" mode and enforcing nothing
- Policies conflict, and the effective result is not what anyone intended
Those are coverage and configuration questions, not setup questions. They are exactly what an audit is for.
The core things to check
1. Is MFA required for all users — and separately for admins? A baseline policy covering all users and all cloud apps, plus a dedicated policy for directory roles, closes the most common gap.
2. Is legacy authentication blocked? Protocols like IMAP, POP, and SMTP AUTH cannot enforce MFA. If no policy blocks them, every other control can be bypassed.
3. Do policies have real scope? A policy with no include scope does nothing. A policy with "All users" excluded effectively protects nobody.
4. Are there broad exclusions? Break-glass accounts are needed, but broad or stale exclusions quietly become the weakest link.
5. Is anything in report-only? Report-only policies enforce nothing. They are for testing, not production.
6. Is there risk-based coverage? Sign-in risk and user risk policies (which require the right licensing) add real protection beyond a static MFA rule.
7. Is there a policy per enabled policy? Each policy should be reviewed individually — not just "do we have policies?" but "does this policy do what it claims?"
How to audit Conditional Access
By hand, you open each policy in the Entra admin center, read the assignments and controls, and reason about the effective result. It is doable for a handful of policies and painful beyond that.
Automated, you pull the policies through Microsoft Graph and evaluate them against a set of checks — coverage, scope, exclusions, legacy auth, report-only state — and get a pass/fail per policy. That is what a hosted audit does: it reads every enabled policy and flags the ones with gaps, mapped to the relevant control (for example CISA SCUBA's MFA and legacy-auth policies).
The identity-driven frameworks — CIS, CISA SCUBA, EIDSCA — all lead with exactly these checks, because Conditional Access is where identity risk concentrates. You can see the identity benchmark coverage on our EIDSCA page.
Do not audit it once
Conditional Access drifts more than almost anything else in the tenant. Admins tweak exclusions during an incident and forget to remove them. A new app needs a policy exception. Someone leaves and their account stays in a role.
A quarterly audit is a reasonable baseline; anything under active change deserves monthly. The value is the series — seeing when a policy changed and whether coverage slipped.
The short version
Conditional Access is your most important control and your easiest place to develop false confidence. Audit not just whether policies exist, but whether each one actually covers what it should. Then keep auditing, because the policies you review today are not the policies you will have in six months.
Run an audit to evaluate every Conditional Access policy in your tenant against the identity frameworks, in minutes.