Close a Conditional Access coverage gap

Prerequisites

  • Product permission entra.read for the coverage matrix, policies, conflicts and break-glass views.
  • Product permission entra.admin to run or save a Conditional Access simulation, and to confirm a break-glass account.
  • Tier 1 consent for the Conditional Access inventory and directory objects; tier 2 consent adds the group membership, device and MFA registration data that make cohort resolution and control coverage accurate.
  • Entra ID P1 for Conditional Access itself. Without it the domain reports unlicensed and no consent will change that.
  • A completed collection. The matrix is computed from the cached snapshot, not from a live Graph call.

Route

/entra/conditional-access, with URL-backed Coverage, Exposure, Policies, Conflicts, Break-glass and Simulate sub-tabs at /entra/conditional-access/:sub.

How to find the weakest cell and name who is exposed

  1. Open /entra/conditional-access on the Coverage sub-tab and read the headline sentence: how many users and applications are matched by no enforced policy, and how many of those principals hold privileged roles.

  2. Expand How this is counted and read the assumptions before you quote the number anywhere. The matrix states its own model rather than presenting a figure on trust.
  3. Read one matrix per application class. Rows are cohorts with their size; columns are the grant controls. A cell is enforced, partial, report-only or none — and report-only protects nobody, which is why it is a separate state from enforced.
  4. Pick the weakest cell that matters: prefer a none or report-only cell on a privileged or administrator cohort over a larger gap on a low-risk cohort.
  5. Select the cell to open the coverage detail. Read how many of the cohort are covered, which policies produced that coverage, and the list of principals who are not covered. Users with no registered MFA method are marked.
  6. Note that the uncovered list is a bounded sample of a larger total where the drawer says so. Use it to characterise the gap, not as the authoritative remediation list.

Expected result: One cohort, one application class and one control identified as the gap, with named examples of who is exposed.

Verification: Open the policies named in the drawer on the Policies sub-tab and confirm their state and scope in the Microsoft Entra admin center before you plan a change.

How to prioritize application-class exposure

  1. Open /entra/conditional-access/exposure after confirming the snapshot age.
  2. Start with the first application class: rows rank the worst open severity first and use uncovered-control proportion only as a tie-break.
  3. Expand the row and read each finding’s exposure, blast radius, and reviewed first step.
  4. Export the exposure rows to CSV when a review artifact is required; retain the snapshot time with it.
  5. Return to /entra/conditional-access/coverage and verify the corresponding cohort, application class, and control cells before proposing a change.

Expected result: A severity-ordered application class and its specific exposed controls are selected for review.

Verification: The expanded finding and Coverage cell identify the same application class and gap; verify the involved policies in Entra before acting.

How to check conflicts, exclusions and break-glass exposure

  1. Open the Policies sub-tab and filter to the policies involved. Each policy shows whether it is enabled and enforced, report-only, or disabled.

  2. Open a policy and read its effective user count, excluded user count, grant controls, application scope and last modified time. A large exclusion set is the usual reason a cell reads partial rather than enforced.
  3. Read the conflicts listed on the policy, then open the Conflicts sub-tab for the tenant-wide view grouped by conflict kind. A control that is granted by one policy and undermined by another is a coverage problem the portal cannot show you, because it shows one policy at a time.
  4. Open the Break-glass sub-tab. Detection is heuristic on purpose, so confirm or reject each candidate yourself; the decision is stored locally and never written to Entra.
  5. Decide explicitly which exclusions must survive the change — emergency access accounts, service accounts with a compensating control — and which exist only because nobody removed them.

Expected result: A change proposal that names the policy to alter, the exclusions to keep, and the conflicts it must not make worse.

Verification: Every exclusion you intend to keep is either a confirmed break-glass account or has a documented owner and compensating control.

How to model the change before proposing it

  1. Open the Simulate sub-tab. Choose the change kind — enable, disable, set to report-only, or delete — and select the policy. The candidate list is filtered to policies for which that change is meaningful.

  2. Narrow the sign-in contexts if you only care about a subset; by default the simulator runs every context it publishes.
  3. Select Simulate. Read the result as a diff, not as a verdict. Newly blocked principals cannot satisfy the new control — that is a hard block, not friction. Protection lost is the silent risk of a cleanup: a control that used to apply no longer does. Newly challenged can satisfy the control and will see an extra prompt.
  4. Read the break-glass impact first and never dismiss it. A change that locks out emergency access is the one failure mode that cannot be fixed from inside the tenant.
  5. Select Simulate & save to keep the run as evidence for the change review. Saved simulations are listed with their counts, break-glass impact and a marker when they are based on older data than the current snapshot.
  6. Export the policy set as policy-as-code for the change record. The export resolves identifiers to names alongside the raw values, in JSON for tooling or Markdown for a review document, and carries the snapshot timestamp.

Expected result: A saved, dated simulation and a policy export that together describe the current state and the predicted change.

Verification: Re-open the saved simulation and confirm the counts and break-glass figure match what you are about to propose. Treat the model as evidence for a review, never as proof — it is an offline model of the snapshot, not a Microsoft what-if evaluation.

How to roll out and confirm

  1. Make the change in the Microsoft Entra admin center through your approved change process. Nothing in this feature writes a policy.

  2. Deploy in report-only first and let it run long enough to cover a full working cycle, including out-of-hours and service account sign-ins.
  3. Review the report-only results in Microsoft’s own sign-in logs before enforcing. Confirm the affected population resembles the simulated newly challenged and newly blocked sets.
  4. Enforce the policy, keeping the exclusions you decided to preserve.
  5. Return to the app, select Refresh on the freshness badge, and wait for the collection to finish.
  6. Re-run the saved simulation against the new snapshot, then re-read the coverage matrix. Do both: the re-run confirms the model no longer predicts a change, and the matrix confirms the cell actually moved.

Expected result: The target cell reports enforced coverage for the cohort, and the headline uncovered figures fall by roughly the population you modeled.

Verification: The uncovered list for that cell is empty or reduced to the exclusions you deliberately kept, and the Conditional Access pillar on /entra reflects the change in the next score.

Safety and rollback

Every Conditional Access read in this feature is read-only, and the simulator is pure computation over the cached snapshot — no policy is created, modified, enabled or deleted by this product. The local writes are the saved simulation and the break-glass confirmation, both stored per tenant, both recorded in the audit trail, and both discardable without touching Entra.

The real change happens in Entra and is rolled back there. Report-only is the rollback plan: it is the only stage where an enforcement mistake costs nothing. Never enforce a new control without a confirmed break-glass account excluded and tested, and never quote a simulated count as a guaranteed outcome. Exports contain policy structure and identifiers — treat them as sensitive governance material and keep real tenant, object and user identifiers out of tickets, prompts and shared examples.

Troubleshooting

Symptom Resolution
The Conditional Access tab reports the domain is blind Grant the missing tier from /entra/setup, re-check permissions, then collect.
The domain reports unlicensed The tenant lacks Entra ID P1; consent will not help.
The simulator says there is nothing to simulate The tenant has no Conditional Access policies collected. Start from the Coverage sub-tab.
Simulate returns a permission error Simulation requires entra.admin because it enumerates cohort membership broadly.
A saved simulation no longer applies It references a policy that has since been deleted or changed. Rebuild the change and simulate again.
A saved simulation is marked as based on older data It predates the current snapshot. Re-run it before quoting the numbers.
A cell still reads partial after the change Exclusions or a report-only policy remain. Open the cell detail and read the policies applying.

Back to top

Azure Support Agent is open source under the MIT License.

This site uses Just the Docs, a documentation theme for Jekyll.