Auditing Conditional Access: the policy gaps that matter

EntraGUARD·2026-09-08·9 min

Conditional Access decides who gets in, from where, on what device. It is also where audits find the most consequential gaps, because one missing condition can undo MFA for a whole population. Here is how to audit it.

Conditional Access is the policy engine of Entra ID — the place where "who, from where, on what device, to what" is decided on every sign-in. It is also where audits find the most consequential gaps, because a single missing condition can quietly undo MFA for a whole population. This is a practical checklist for auditing a Conditional Access estate.

Start with coverage, not policies

The first question is not "are the policies good" but "what falls outside them". List every policy, then map the users, applications and platforms each one includes and excludes. The dangerous space is the union of the exclusions: break-glass accounts (legitimate), but also the service accounts, the "temporary" exception group that never got cleaned up, and the guest tenant that no policy targets. Coverage gaps are invisible in the portal's per-policy view; you have to reason across the whole set.

The policies every tenant should have

Baseline MFA for all users, all cloud apps — with only break-glass excluded.
Phishing-resistant MFA for admins — targeting the privileged roles, not just named accounts.
Legacy authentication blocked — the single highest-value policy, since legacy protocols bypass MFA entirely.
Device compliance or hybrid join for access to sensitive resources.
Sign-in risk and user risk policies, where Entra ID P2 licensing allows.
Session controls — sign-in frequency for privileged access and unmanaged devices.

The gaps that matter most

Three findings recur across audits. First, report-only policies that were never enforced — they look like coverage but do nothing. Second, exclusion groups with open membership, where anyone added inherits an MFA bypass. Third, admin portals left unprotected because a policy targets "Office 365" as an app group and misses the Azure management surface. Each of these passes a casual glance and fails a real one.

Break-glass done right. Emergency-access accounts must be excluded from the very policies that could lock you out — but they then need compensating controls: long unique credentials, exclusion from nothing else, and alerting on every use. An excluded account that no one watches is a standing backdoor.

Test the intent, not just the config

A policy can be present and still not achieve its goal. The audit that helps is the one that reasons about outcome: given these policies and these exclusions, can a privileged user reach the admin portal without phishing-resistant MFA? Can a guest reach SharePoint without MFA at all? Answering those questions is exactly what an attack simulation does — it replays the path rather than reading the setting.