Microsoft 365 tenant · Identity & authentication

Keep Conditional Access policies free of broken references and unprotected exclusions

When it fails: Conditional Access policies contain silent configuration errors. Policies that point to deleted objects, have no target resource, leave exclusions uncovered or rely on groups any admin can edit do not protect what their name suggests.

CB-M365-AUTH-034mediumactivemanualprofile hardened

Description

The set of Conditional Access policies is reviewed at least quarterly, and after each change, against these rules:

  1. No policy includes or excludes a deleted user, group or role (shown as an unknown object ID).
  2. Every enabled policy has at least one target resource, user action or authentication context.
  3. Every object excluded from a policy is covered by another policy that gives an equivalent protection (for example a dedicated policy for service accounts), except the emergency access accounts.
  4. Groups used to include or exclude users in policies are role-assignable groups or are placed in a restricted management administrative unit, so that only privileged administrators can change their membership.
  5. Microsoft-managed policies are not left in Report-only: each one is set to On, or to Off with a documented equivalent.
  6. Authentication method policies do not reference deleted groups.

The Maester tests MT.1035, MT.1036, MT.1038, MT.1066, MT.1067, MT.1184 and MT.1224 automate most of these checks. The Conditional Access gap analyzer workbook helps with rule 3.

Rationale

Conditional Access fails open: a policy targeting a deleted group applies to nobody, a policy without resources does nothing, and an exclusion without a fallback is a permanent hole. Attackers who obtain a Groups Administrator or User Administrator role add themselves to an exclusion group to escape MFA. None of these errors raise an alert; only a review finds them.

Impact

Moving exclusion groups into a restricted management administrative unit means that User and Groups Administrators can no longer change them; the Conditional Access team or a Privileged Role Administrator must do it. The review takes a few hours per quarter.

Applies when

Requires: Microsoft Entra ID P1

Audit

  1. Sign in to the Microsoft Entra admin center (https://entra.microsoft.com) as at least a Security Reader (Global Reader to also read administrative units).
  2. Browse to Entra ID > Conditional Access > Policies and open each policy:
    • Users and Target resources show no unresolved object ID (a GUID instead of a name);
    • Target resources is not empty;
    • every excluded user or group is either an emergency access account or is included in another enabled policy with an equivalent grant.
  3. Filter the policy list on the name prefix Microsoft-managed: and check that none is in Report-only.
  4. For each group used in a policy, open it under Entra ID > Groups and check that Microsoft Entra roles can be assigned to the group is Yes, or that it is a member of an administrative unit with Restricted management set to Yes (Entra ID > Roles & admins > Admin units).
  5. Browse to Entra ID > Authentication methods > Policies and check that the target groups of each method still exist.
  6. Alternative in PowerShell (Microsoft Graph, scope Policy.Read.All, Group.Read.All): list the policies with Get-MgIdentityConditionalAccessPolicy, collect the IDs in Conditions.Users.IncludeGroups and ExcludeGroups, and resolve each with Get-MgGroup -GroupId <id>; an error means a deleted group. Or run Maester (read-only) with the tests listed in the notes.
  7. Fail on any broken reference, any enabled policy without target, any uncovered exclusion, any exclusion group editable by non-privileged administrators, or any Microsoft-managed policy left in Report-only.

Remediation

  1. Sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator.
  2. Remove deleted objects from the policies, or delete policies that no longer have a purpose.
  3. Add the missing target resources, or delete untargeted policies.
  4. For each uncovered exclusion, create a dedicated policy for the excluded population (for example service accounts restricted to trusted locations), or remove the exclusion.
  5. Create an administrative unit with Restricted management administrative unit set to Yes (Privileged Role Administrator), and move the include and exclude groups into it. New groups can also be created as role-assignable.
  6. Review each Microsoft-managed policy in report-only mode, exclude the emergency access accounts, then set it to On or Off.
  7. Record the review date and repeat it every quarter.

Rollback

Remove a group from the restricted management administrative unit to give back the delegated administrators' rights on it.

References

Mappings

FrameworkIDRelation
NIST SP 800-53 Rev. 55.1.1CM-6related
NIST SP 800-53 Rev. 55.1.1AC-2related

How this control relates to the other framework's: equivalent, stricter, looser, partial or related.

Threats mitigated

People and lifecycle

Authors
Introduced inv0.1.0
Created, updated2026-10-24, 2026-10-24
Translationsfr