Conditional Access exclusions are sometimes necessary and legitimate. But they are also one of the most common sources of long-term security drift in Microsoft 365. An exclusion added during an incident, a migration, or a user escalation can persist for years without anyone reviewing whether it is still needed.

Overe surfaces exclusions across Conditional Access policies — excluded users, groups, roles, trusted locations, service accounts, and break-glass identities — and flags those that appear stale, poorly scoped, or undocumented. The risk is not the act of excluding something, but the failure to review and expire exclusions over time.

Exclusions are particularly dangerous because they are silent. A policy that enforces MFA for 99% of users appears secure. The 1% that are excluded may never surface in an alert unless specifically reviewed.

• Attacker obtains credentials for an excluded user and signs in without any MFA or policy challenge, gaining access without any authentication friction
• Excluded group used as a staging ground — attacker adds a compromised account to the excluded group to bypass controls for that account specifically
• Trusted location with a stale or overly broad IP range used by an attacker operating from a network within the excluded range, allowing unauthenticated access from an attacker-controlled host
• Service account exclusion exploited after credentials are exposed in a code repository or configuration file, providing a persistent unauthenticated access path
• Former employee account that was individually excluded from a policy for operational reasons remains in an active-but-excluded state after departure, providing a credential-only access path with no MFA requirement
• Policy intended for a migration that ended months ago still excluding a large group of users who are no longer migrating but are still bypassing controls
• A trusted location IP range that has not been updated since an office closure or VPN change includes ranges no longer controlled by the organisation, effectively expanding the bypass perimeter to external networks

Exclusions are legitimate in specific, documented circumstances. Break-glass accounts should be excluded from most policies to ensure emergency access — but they should be monitored and never used for routine activity. Service accounts used by automation that cannot satisfy MFA are often legitimately excluded — but the exclusion should be scoped to the specific app and IP range required. Migration or rollout periods often create temporary exclusions that should have a defined end date.

An exclusion is acceptable when it has a named owner, a documented reason, a defined scope, and a review date. An exclusion without any of these is a risk, not a managed exception.

Before modifying any Conditional Access exclusion:

• Enumerate all exclusions across all Conditional Access policies — users, groups, roles, locations, and device states
• For each exclusion, confirm whether there is a documented business reason and a named owner
• Check whether excluded users or groups have had recent sign-in activity and whether any activity appears unusual
• Review whether trusted location definitions used as exclusions are still accurate and maintained
• Identify exclusions that have existed since before a defined date without any review
• Check whether excluded identities also appear in other Overe risk signals — dormant accounts, risky MFA, or Defender incidents
• Confirm whether any excluded users have left the organisation

1. Use Overe to enumerate all Conditional Access exclusions across the tenant in a single view
2. For exclusions without documentation or a named owner, investigate before removing — some may be operationally critical
3. For exclusions tied to former employees or departed contractors, remove immediately
4. For service account exclusions, validate that they are still required and tighten scope to the minimum necessary
5. For trusted location exclusions with stale IP ranges, update or remove them
6. Establish a review schedule for all exclusions — treat them like access reviews, not set-and-forget configuration
7. Test removal of exclusions in report-only mode before enforcement to understand the impact

Where direct remediation is required, Overe provides links to the appropriate Microsoft admin controls to complete the action safely.

Microsoft: Access reviews for Conditional Access excluded users - https://learn.microsoft.com/en-us/entra/id-governance/conditional-access-exclusion

Microsoft: Conditional Access policy components - https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-policies

Microsoft: Use access reviews to manage users excluded from Conditional Access - https://learn.microsoft.com/en-us/entra/id-governance/conditional-access-exclusion

After investigating Conditional Access exclusions, review these related risk areas:

• Conditional Access MFA Bypass Paths — exclusions and bypass paths are related but distinct; an exclusion is an explicit policy exception, a bypass path is a gap in policy scope; both should be reviewed together to build a complete picture of who can authenticate without MFA
• Admins with Risky MFA Settings — excluded admin accounts with weak MFA represent a compound risk; the exclusion removes the policy protection and the weak MFA leaves no backup control
• Break-Glass Accounts — break-glass accounts are intentionally excluded from most CA policies; ensure they are the only accounts with this status, that they are monitored, and that the exclusions are reviewed on the same cycle as all others
• Dormant Users — users who were excluded from policies and have since become dormant represent forgotten exceptions; check for overlap between excluded identities and dormant accounts that have no active owner
• Legacy Authentication Exposure — some exclusions are created specifically to allow legacy protocol access; confirm these are still required, tightly scoped to the minimum necessary, and have not expanded in scope since creation