How to Review Conditional Access Exclusions in Entra ID

Conditional Access exclusions are added for good reasons and then forgotten. A service account is excluded to unblock a migration, a group is excluded during an incident, an administrator is excluded to avoid a lockout — and each exclusion quietly becomes permanent. Because an exclusion loosens a policy for whoever it names, the accounts you can least afford to leave unguarded are exactly the ones exclusions tend to accumulate around.

A Conditional Access exclusion review is a periodic read-only pass over who is currently excluded, why, and whether that reason still holds. It does not change policies. This guide sets out a repeatable process: what to collect, what to inventory, what to record, and how to turn the pass into dated evidence you can keep.

This is a suggested operating practice, not a Microsoft requirement or a compliance standard. Adapt the cadence and the fields to how your organisation actually works.

What a Conditional Access exclusion review is

A Conditional Access policy in Microsoft Entra ID targets identities through inclusions and exclusions. When an account or group is both included and excluded, Microsoft is explicit about the outcome: "the exclude action overrides the include action in a policy" (Microsoft Learn, checked 18 September 2026). An exclusion is therefore a deliberate hole in a control, and the review exists to confirm that every hole is still wanted.

The review is deliberately narrow. It answers three questions for each exclusion:

• Who is excluded — a direct user, the members of a group, or the holders of a directory role.
• Why the exclusion exists — the operational reason, recorded in your own words.
• Whether the reason still holds — approved, owned, and not past its intended end date.

It is not a security assessment, a sign-in test, or a judgement about whether the policy itself is well designed. Keeping it narrow is what makes it repeatable. A wider technical reference to how each exclusion type behaves is a separate read; this page is the process.

Why exclusions need periodic review

Microsoft's own deployment guidance is blunt about exclusions: "Use exclusions sparingly, only in situations where the user is trusted. Add users back to the policy or group as soon as possible" (Microsoft Learn, checked 18 September 2026). "As soon as possible" only happens if someone looks. Three forces work against you:

• Exclusions outlive their reason. The migration finishes, the incident closes, the vendor engagement ends — but the exclusion stays.
• Group membership drifts. When a group is excluded, the exclusion follows whoever is in that group today, not who was in it when the exclusion was created. Membership changes without touching the policy.
• Nobody owns them. Conditional Access policies have no built-in owner attribute, so unless ownership is recorded somewhere, an exclusion has no natural custodian to question it.

A periodic review is the control that catches all three. Quarterly is a reasonable default for most small teams; tie it to your existing quarterly access review if you already run one, and review sooner after any significant Conditional Access change.

What evidence to collect before reviewing

You cannot review what you cannot see, and a half-collected export produces a misleading review. Collect a complete, current snapshot of the identity targeting for each policy before you start:

• The policy name and its state (on, off, or report-only).
• For each policy: the included and excluded users, groups, and directory roles.
• For each excluded group: its current membership, including nested members.
• The display names behind the object IDs, so the review is readable by a human.

The Conditional Access exclusion audit uses a downloadable PowerShell exporter to gather this locally: you authenticate to Microsoft Graph on your own machine, and the exporter reads the policies and the identities they exclude. The exporter requests read-only permissions — Policy.Read.ConditionalAccess, User.ReadBasic.All, GroupMember.Read.All, and RoleManagement.Read.Directory — based on documented Microsoft Graph contracts, and it does not broaden them or write anything back.

Whatever you use to collect the snapshot, record when it was taken. An exclusion review is a point-in-time statement, and the date is part of the evidence.

Inventory the direct excluded users

Start with the simplest case: individual accounts named directly on a policy's exclusion list. In Microsoft Graph these appear in the excludeUsers collection on the policy (Microsoft Learn, checked 18 September 2026). For each one, resolve the object ID to a display name and account type, and ask:

• Is this a person, a shared or service account, or an emergency access account?
• Which policy is it excluded from, and does the exclusion still match a current reason?
• Is the account itself still active and still needed?

Direct user exclusions are the easiest to reason about because they name exactly one identity. They are also the ones most likely to be added "just for now" during an incident and never removed. A short list of directly excluded users, each with a reason and an owner, is the fastest win in the whole review.

Review the excluded groups

Group exclusions are where most of the real risk sits, because the exclusion applies to the group's membership, not to a fixed list of people. A group can be any type of group in Microsoft Entra ID — including dynamic or assigned security and distribution groups — and Microsoft confirms that "policy is applied to nested users and groups" (Microsoft Learn, checked 18 September 2026).

For each excluded group, record:

• The group name and the policy it is excluded from.
• Why the group is used as the exclusion mechanism (for example, a dedicated break-glass group).
• Who owns the group's membership, which is often a different person from who owns the policy.
• Its current members — and whether every current member should genuinely be outside this control.

The critical shift in thinking is this: reviewing a group exclusion is really reviewing the group's membership, because that is what determines who is actually excluded today.

Check transitive and nested membership

A group can contain other groups, and Conditional Access applies to the users those nested groups ultimately resolve to. So a person can be excluded from a policy without appearing in the top-level excluded group at all — they inherit the exclusion through a nested group two or three levels down.

When you review an excluded group, expand it to its effective membership, not just its direct members. A useful discipline:

1. List the group's direct members and any nested groups it contains.
2. Expand each nested group in turn until you reach only users.
3. Treat that full, flattened set as "who is actually excluded".

Microsoft also documents a hard edge here: if users or groups belong to more than 2,048 groups, their access might be blocked, and "this limit applies to both direct and nested group membership" (Microsoft Learn, checked 18 September 2026). You are unlikely to hit that in a small tenant, but it is a reminder that nesting has real consequences. If your export cannot resolve nested membership completely, say so in the review rather than treating the direct members as the whole picture.

Review directory-role exclusions

Conditional Access can also exclude the holders of a directory role — for example, excluding a role from a policy that would otherwise apply broadly. Microsoft limits this to built-in directory roles: "Other role types aren't supported, including administrative unit-scoped roles and custom roles" (Microsoft Learn, checked 18 September 2026). Some roles listed as deprecated can still be selected because they remain in the underlying API.

Role exclusions deserve careful attention because the excluded set changes whenever a role assignment changes. For each excluded role, record which role it is, which policy excludes it, and confirm that excluding everyone who currently holds that role is intended. A role exclusion applied to a privileged role is a large, moving hole; make sure it is a deliberate one.

Record owner, reason, approver, reference and expiry

An exclusion with no recorded reason is indistinguishable from a mistake. The point of the review is to attach durable context to each exclusion, because Conditional Access itself stores none of it — there is no owner field and no expiry field on a policy. Microsoft's own advice is to "encode ownership in the policy name ... and maintain an out-of-band registry that maps each policy to a responsible admin or team" (Microsoft Learn, checked 18 September 2026). Your review is that registry.

For each exclusion, capture at least:

Record ownership at the role or team level rather than tying an exclusion to a single named individual, so the record survives staff changes. This is exactly what the audit captures as local approval information — reconciled against the exported inventory, kept in your own review file, never uploaded.

Distinguish known facts from incomplete evidence

A review is only trustworthy if it is honest about its own gaps. There is a real difference between "this account is not excluded" and "this account did not appear in my export". If a collection stage failed, a group could not be fully expanded, or a policy was skipped, that is missing evidence — not a clean result.

Make the distinction visible in the review itself:

• Known fact: the export completed for this policy, and this identity is present on (or absent from) its exclusion list.
• Incomplete evidence: collection was partial, a group could not be resolved, or a permission was insufficient, so absence cannot be asserted.

The audit tool is built around this principle: incomplete collection stays visible, and missing evidence is not presented as a pass. Carry the same honesty into any manual review. An incomplete export can never prove that an account is not excluded; it can only fail to show that it is.

Review expired and upcoming exceptions

Because you recorded review dates and intended end dates, the review can now do something a live policy cannot: surface exclusions that have outlived their reason. Walk two short lists:

• Past their date. Any exclusion whose intended end date has passed is a candidate for removal. Confirm the reason has genuinely ended, then plan the removal through your normal change process — the review flags it; it does not remove it.
• Coming up. Exclusions due for revisit before the next review get an owner and a date now, so they do not silently roll over.

Microsoft's guidance to "add users back to the policy ... as soon as possible" only becomes real when someone acts on a list like this. The review's job is to produce the list and assign the follow-ups; removing an exclusion remains a deliberate change made in Entra.

Create dated review evidence

The output of the review is a dated artifact: what was reviewed, when, by which role, and what was decided about each exclusion. That artifact is the thing you keep, hand to an auditor, or compare against next quarter.

The audit produces this locally. You can save a review file to reopen later, download the identity inventory and the findings as CSV, and use your browser's own print dialog — choosing Save as PDF — to produce a review record. Everything is processed in the browser tab; nothing in the export is uploaded to CertPilot, and nothing is saved automatically. Files you explicitly save, download, or print stay wherever you put them, under your control.

For evidence that lives in a shared workspace rather than a local file, CertPilot's Access Reviews register records access decisions, completion, and a dated Access Review Register PDF — a natural home for the follow-ups this exclusion review produces.

What this review cannot prove

Being clear about the limits is what keeps the evidence credible. An exclusion review is an identity-exclusion inventory and approval reconciliation — nothing more.

• It is not effective sign-in evaluation. Knowing an account is excluded from one policy does not tell you whether it can sign in. Microsoft is explicit that you should "test the exclusion criteria of a policy" because "the combination of other policies can require MFA for those users" (Microsoft Learn, checked 18 September 2026). Exclusion from one policy is not exemption from all of them.
• It is not a security assessment or vulnerability scan. It does not judge whether your policies are well designed or your tenant is secure.
• It is not certification. No exclusion review produces a compliance certificate; it produces evidence that a review happened.
• It does not change anything. There is no remediation, no policy edit, and no score. Removing an exclusion is a separate, deliberate action in Entra.
• The audit tool's findings are deterministic and offline. They were validated against documented Microsoft Graph contracts and synthetic responses, not live Microsoft compatibility proof. The exporter's permission set is documentation-derived and has not been independently verified against a live tenant.

How CertPilot's local tool fits into the workflow

CertPilot's free tool supports this exact process without becoming part of your identity plane. You export locally with the read-only PowerShell script, understand what each exclusion type means, open the export in the browser workbench, record approvals and reasons, and produce dated JSON, CSV, or PDF evidence — all locally, with no account, no upload, and no connection from the browser to Microsoft. You can run the local exclusion review whenever you need a fresh, dated snapshot.

It is a review and evidence surface, not a controller. It reads a snapshot you produced; it never edits a policy, never removes an exclusion, and never signs in on your behalf. If your exclusions include break-glass or emergency-access accounts, review those against the break-glass exclusion guidance as a distinct case.

Frequently Asked Questions

How often should Conditional Access exclusions be reviewed?

There is no Microsoft-mandated cadence for reviewing exclusions in general. Quarterly is a sensible default for most small teams, aligned to an existing access-review rhythm, with an extra review after any significant Conditional Access change. Microsoft does specify a separate cadence for emergency access accounts — validate them at least every 90 days and test their sign-in regularly, for example every quarter — which is a good floor to match.

What should be recorded for each exclusion?

At minimum: the owner (as a role or team), the operational reason, the approver, a supporting reference such as a ticket or change record, and a review or expiry date. Conditional Access stores none of this itself, so the review record is where that context lives.

Does reviewing exclusions change any policies?

No. A review is a read-only pass. It inventories who is excluded, reconciles that against recorded approvals, and flags exclusions to revisit. Removing an exclusion is a separate, deliberate change made in Microsoft Entra through your normal change process.

Can an incomplete export prove an account is not excluded?

No. If collection was partial — a group could not be fully expanded, a policy was skipped, or a permission was insufficient — absence from the export means the evidence is incomplete, not that the account is safely outside every policy. Record it as incomplete rather than as a clean result.