Conditional Access exclusions look simple in the portal — a few names on an "Exclude" tab — but they behave in ways that are easy to misread. A single group exclusion can cover people who were never named. A role exclusion changes silently when assignments change. The "guest or external users" selector hides six distinct categories behind one control. Understanding what each exclusion type actually represents is the difference between a review that means something and a list of names that reassures nobody.
This is a technical reference to how identity exclusions work in Microsoft Entra Conditional Access. It covers direct users, groups, nested membership, directory roles, and the full guest-and-external-user model, with the exact behaviour Microsoft documents. If you want the step-by-step process instead, see how to review Conditional Access exclusions.
How identity exclusions are represented
A Conditional Access policy targets identities through include and exclude assignments. The governing rule is simple and absolute: "When organizations both include and exclude a user or group, the user or group is excluded from the policy. The exclude action overrides the include action" (Microsoft Learn, checked 18 September 2026).
Underneath the portal, Microsoft Graph represents this on the policy with separate include and exclude collections (Microsoft Learn, checked 18 September 2026):
| Graph property | What it holds |
|---|---|
excludeUsers | User IDs excluded from the policy (and/or the GuestsOrExternalUsers value) |
excludeGroups | Group IDs excluded from the policy |
excludeRoles | Directory role IDs excluded from the policy |
excludeGuestsOrExternalUsers | A structured selector of guest / external user types and tenants |
Each has a matching includeUsers, includeGroups, includeRoles, and includeGuestsOrExternalUsers. The includeUsers collection also accepts the special values None, All, or GuestsOrExternalUsers. Reading exclusions accurately means reading all four exclude collections together — a name absent from excludeUsers may still be excluded through excludeGroups or excludeRoles.
Direct excluded users
The most literal exclusion is a user named directly on a policy, stored in excludeUsers. It applies to exactly that one account and changes only when someone edits the policy.
Direct user exclusions are the easiest to audit because there is no indirection: the object ID resolves to one identity, and that identity is the whole scope of the exclusion. Microsoft does note a practical limit — there is a cap on how many individual users can be added directly to a policy, and the recommendation is to "place them in a group and assign the group to the policy" when the list grows (Microsoft Learn, checked 18 September 2026). That recommendation is exactly why most real exclusions are group-based.
Excluded groups
A group exclusion, stored in excludeGroups, applies to the group's membership rather than to a fixed list of identities. A group can be "any type of user group in Microsoft Entra ID, including dynamic or assigned security and distribution groups" (Microsoft Learn, checked 18 September 2026).
This has one consequence that dominates every review of group exclusions:
- The excluded set is whoever is in the group right now. Add a member, and they are excluded without the policy being touched. Remove a member, and they are no longer excluded — again with no policy change.
- Dynamic groups move on their own. If the excluded group is a dynamic group, membership recalculates from a rule. The exclusion then follows an attribute-driven population that can change without any human action at all.
A group exclusion is best read as a pointer to a membership list, not as a decision about named people. That is why reviewing a group exclusion is really reviewing the group's current, effective membership.
Nested and transitive group membership
Groups can contain other groups, and Conditional Access resolves through the nesting: "Policy is applied to nested users and groups" (Microsoft Learn, checked 18 September 2026). A user who is a member of a group that is itself a member of the excluded group is excluded, even though they appear nowhere in the excluded group's direct membership.
To read a group exclusion correctly you have to expand it to its transitive (effective) membership: flatten every nested group down to the users it ultimately contains. The direct-members view can badly understate who is actually excluded.
Microsoft also documents a boundary condition worth knowing: 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." Deep nesting is not free. For a review, the practical rule is: never treat a group's direct members as the exclusion scope — resolve the nesting, and if you cannot resolve it fully, record that the membership evidence is incomplete.
Directory-role exclusions
Conditional Access can exclude the holders of a directory role, stored in excludeRoles. This targets everyone currently assigned the role — a moving population, like a group. Two constraints matter:
- Built-in roles only. Microsoft states that "other role types aren't supported, including administrative unit-scoped roles and custom roles" (Microsoft Learn, checked 18 September 2026). A warning in the same documentation confirms policies "don't support users assigned a directory role scoped to an administrative unit or directory roles scoped directly to an object."
- Deprecated roles can still appear. Some roles listed as deprecated remain selectable "because they still appear in the underlying API," so an exclusion may reference a role you no longer actively use.
Because the excluded set is defined by role assignment, a role exclusion changes whenever someone is granted or removed from that role. Excluding a privileged built-in role from a broad policy is a large, dynamic exclusion; it should be a conscious decision, recorded with a reason, not a leftover.
Guests and external users
External identities are targeted through their own structured selector — includeGuestsOrExternalUsers and excludeGuestsOrExternalUsers — rather than as ordinary users. Microsoft categorises external users "based on how they authenticate (internally or externally) and their relationship to your organization (guest or member)" (Microsoft Learn, checked 18 September 2026). Six types can be selected, individually or together:
| External user type | What it represents |
|---|---|
| B2B collaboration guest users | Most users normally thought of as guests; external account, guest-level permissions, UserType of Guest |
| B2B collaboration member users | External account with member-level access, common in multi-tenant organisations; UserType of Member |
| B2B direct connect users | Users accessing via B2B direct connect (for example Teams shared channels); no object in your directory |
| Local guest users | Credentials managed in your directory, designated as guests by setting UserType to Guest |
| Service provider users | Users from an organisation acting as your cloud service provider (for example a CSP) |
| Other external users | External users not represented by the other categories |
When you exclude "guests and external users", you are excluding whichever of these six types are selected — not necessarily all external identities. Reading the selection precisely matters: excluding B2B collaboration guest users is a different scope from excluding all external types.
The legacy "all guests" selection
Older policies used a single "All guest and external users" choice. Microsoft has replaced it: "The 'All guest and external users' selection has now been replaced with 'Guest and external users' and all its sub types. For customers who previously had a Conditional Access policy with 'All guest and external users' selected [it] will now see 'Guest and external users' along with all sub types being selected. This change in UX doesn't have any functional impact on how policy is evaluated" (Microsoft Learn, checked 18 September 2026). So a policy created under the old model now shows all six sub-types selected, with no change to how it behaves — useful to know when an older policy looks different from a newer one.
External tenants: all or selected
For the selected external user types, you can scope by tenant: "One or more tenants can be specified for the selected user types, or you can specify all tenants" (Microsoft Learn, checked 18 September 2026). An exclusion can therefore mean "these external user types, from these specific partner tenants" or "these types, from any tenant." When reviewing, capture both the type selection and the tenant scope; "external guests excluded" without the tenant scope is an incomplete statement.
Microsoft also documents a common pattern for external users that is worth recognising in an export: to keep risk-based policies from affecting external users, organisations "create a group ... that contains all of your organization's external users. Then, add this group as an exclusion." That is a group exclusion doing the work of an external-user exclusion — a reminder to read group exclusions and external-user selectors together.
Why a group exclusion differs from a direct user exclusion
The single most useful distinction in this whole subject:
- A direct user exclusion names a fixed identity. It changes only when the policy is edited. What you see is what is excluded.
- A group or role exclusion names a population. It changes whenever membership or role assignment changes, with no policy edit. What you see is a pointer; the real scope is today's effective membership.
Treating a group exclusion as if it were a fixed list is the mistake that makes a review worthless. The list of names you read last quarter may not be the list of names excluded today.
Common interpretation mistakes
- Reading direct members as the full scope. Nested membership means the effective, flattened set can be much larger. Always resolve transitively.
- Assuming "guests excluded" means all external users. It means the selected sub-types, for the selected tenants — no more.
- Ignoring the exclude-overrides-include rule. An account that looks included can be fully excluded because it also sits in an excluded group or role.
- Treating an exclusion from one policy as an exemption from all. Each policy is evaluated independently; another policy can still apply.
- Forgetting that role and dynamic-group exclusions move on their own. No policy edit is needed for the excluded population to change.
What exclusion inventory does not tell you
An accurate inventory of exclusions is necessary but not sufficient. It does not tell you:
- Whether an excluded account can sign in. Exclusion from one policy is not access. Microsoft advises testing exclusion criteria because "the combination of other policies can require MFA for those users" (Microsoft Learn, checked 18 September 2026). Effective sign-in is evaluated across all applicable policies, not from one exclusion.
- Whether the policy design is sound. An inventory is a factual list of who is excluded, not a judgement about whether your policies are well built.
- Whether an absence is real. If collection was incomplete — a group could not be expanded, a permission was insufficient — absence from the inventory is missing evidence, not proof of non-exclusion.
How to review these exclusions
With the mechanics clear, the review is a disciplined pass over each type: resolve direct users, expand every excluded group to its transitive membership, confirm each excluded role's intent, and read the guest/external selector with its tenant scope. Record an owner, reason, approver, reference, and review date for each. The full step-by-step is in how to review Conditional Access exclusions.
To do this against your own tenant, CertPilot's free audit lets you review your current exclusions locally: export with a read-only PowerShell script, open the file in a browser workbench, and record approvals and reasons. It reads the snapshot and produces deterministic findings, JSON, CSV, and PDF evidence — all in the browser tab, with nothing uploaded and no connection to Microsoft. It inventories and reconciles exclusions; it does not edit policies, evaluate sign-in, or produce a security score, and its findings were validated against documented Microsoft Graph contracts and synthetic responses rather than live-tenant proof.
Frequently Asked Questions
Can a group be excluded from Conditional Access?
Yes. A group ID in the policy's excludeGroups collection excludes the group's members. The group can be a security or distribution group, and assigned or dynamic. The exclusion applies to whoever is in the group at evaluation time, so it changes as membership changes — without the policy being edited.
Do nested group members inherit an exclusion?
Yes. Microsoft states that policy is applied to nested users and groups, so a member of a group nested inside an excluded group is excluded even though they are not a direct member. When reviewing, expand each excluded group to its full transitive membership rather than reading only its direct members.
Can directory roles be excluded from Conditional Access?
Yes, for built-in directory roles. Administrative unit-scoped roles and custom roles are not supported. The exclusion applies to everyone currently assigned the role, so the excluded population changes as role assignments change. Some deprecated roles remain selectable because they still exist in the underlying API.
How are guests and external users represented in exclusions?
Through a structured selector (excludeGuestsOrExternalUsers) offering six types: B2B collaboration guest users, B2B collaboration member users, B2B direct connect users, local guest users, service provider users, and other external users. You can scope the selected types to all tenants or to specific tenants. The older "All guest and external users" option now maps to all six sub-types being selected, with no functional change.
Does excluding an account from one policy exempt it everywhere?
No. Each Conditional Access policy is evaluated independently. An account excluded from one policy can still be in scope of another, so an exclusion is not a guarantee of unrestricted sign-in. Microsoft recommends testing exclusion criteria for exactly this reason.