You manage Conditional Access exclusions by treating them as temporary exceptions that need ownership, purpose, and review dates. Keep a register of every exclusion, validate that break-glass accounts are truly emergency-only, check whether the excluded users or devices still need access, and remove exceptions once the underlying issue is fixed or a narrower policy is available.
What makes a Conditional Access exclusion safe to keep?
A conditional access exclusion is safest when it has a clear business reason, a named owner, and an expiry or review date. The key judgement is whether the exception is narrower than the policy it bypasses. If it is acting as a permanent workaround, it is already a control gap rather than an exclusion.
Exclusions should be treated as controlled deviations from the normal access model, not as a convenience setting. That means documenting who approved the exception, which sign-in or device condition it bypasses, and what compensating control exists while it remains in place. A good register makes the exception visible enough to challenge later.
For a broader policy design view, the Conditional Access Guide is useful because it covers policy design, report-only testing, and gap analysis before you rely on exclusions operationally.
How should you review exclusions over time?
Review exclusions on a fixed cadence and also after any material change to the identity, device, or application behind the exception. The review should answer three questions: does the excluded subject still exist, does it still need the exception, and can the policy now be tightened without breaking legitimate access?
In practice, the most useful exclusions review is a closure exercise, not a status check. If an exception was created for onboarding, troubleshooting, migration, or temporary incompatibility, the reviewer should verify whether that temporary condition still exists. If not, remove the exclusion rather than reauthorising it by default.
The review should also include adjacent controls. If the exclusion exists because a device is unmanaged, a user lacks an authentication strength, or an application cannot yet meet a control requirement, the question is whether a narrower Conditional Access policy, device trust requirement, or app-specific control can replace the broad exception.
Which exclusions deserve the closest scrutiny?
Break-glass accounts, highly privileged administrators, and exclusions that apply to many users or devices deserve the most scrutiny. Those exceptions can quietly turn into standing bypass paths, especially when they are created to preserve availability during an incident and then never removed.
Break-glass accounts should be emergency-only, tightly scoped, and monitored separately from normal administrative access. If they appear in an exclusion list, the review should confirm that they are not being used for routine administration, automation, or convenience access. The same scrutiny applies to exclusions that skip device compliance or authentication-strength checks, because they often become the easiest route around the policy.
When exclusions are tied to privileged administration, the Privileged Access Management Guide helps because it addresses break-glass accounts, just-in-time access, session management, and zero standing privilege.
Risk and Threat Considerations
Exclusions are a common place for control drift because they are created under pressure, justified as temporary, and then forgotten. The risk is not only policy bypass, but also the expansion of the blast radius if an excluded account, device, or session is compromised.
Failure mechanism: A bypass path remains active after the original operational need has passed, or the excluded account is reused for broader access than intended. That lets an attacker or careless operator move around the intended Conditional Access boundary without triggering the policy outcome the organisation expected.
Impact: The organisation can end up with persistent, hard-to-see access exceptions that weaken authentication and device trust controls, delay detection of misuse, and make incident containment more difficult when an excluded identity is abused.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Exclusions need accountable ownership, review, and removal as part of account control. |
| AC-6 — Least Privilege | Conditional Access exclusions can create broader access than intended and weaken least privilege. | |
| IA-2 — Identification and Authentication (Organizational Users) | Conditional Access exclusions often bypass user authentication strength requirements. | |
| Recommendation — Review exception-bearing accounts regularly and revoke unnecessary access promptly. Minimise exception scope so excluded access stays narrowly bounded. Verify excluded users still meet authentication expectations or remove the exemption. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Exclusions are access-control exceptions that require ownership, review, and revocation discipline. |
| Recommendation — Document, review, and remove access-control exceptions on a defined schedule. | ||
| CIS Controls v8 | CIS-5 — Account Management | Exclusions should be governed like accounts and exceptions with periodic review and removal. |
| Recommendation — Maintain an exception register and retire unused exclusions quickly. | ||
Practitioner Guidance
What to prioritise: Start with exclusions that protect privileged access, break-glass accounts, and any bypass that covers production systems. Those cases carry the highest consequence if the exception is no longer justified.
What to verify: Check that every exclusion has an owner, a reason, a review date, and evidence that the underlying need still exists. If the exception cannot be explained in one sentence, it is probably too broad or too old.
Common mistake: Treating exclusions as a one-time implementation detail. The safer pattern is to review them as living exceptions and remove them as soon as a narrower policy, device posture, or authentication control can take over.
Practitioner takeaway: The best exclusions process is one that makes temporary bypasses easy to see, easy to challenge, and easy to remove before they become standing access.