Conditional Access Exclusions: Intended Exceptions Creating Long-Term Bypass Risk

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
• Excluded group used as a staging ground — attacker adds a compromised account to the excluded group to bypass controls
• Trusted location with a stale or overly broad IP range used by an attacker operating from a network within the excluded range
• Service account exclusion exploited after credentials are exposed in a code repository or configuration file
• Former employee account that was individually excluded remains accessible long after departure
• Policy intended for a migration that ended months ago still excluding a large group of users

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

• Conditional Access MFA bypass paths
• Admins with risky MFA settings
• Break-glass accounts
• Dormant users