
A Conditional Access exclusion switches a policy off for that account completely, and it stays that way until someone removes it. List every exclusion, give each one a named owner and a reason, keep the few you deliberately need, such as emergency access accounts, and remove the rest.
Multi-factor authentication for all users is one of the first Conditional Access policies a Microsoft 365 tenant gets. The word "all" is reassuring. The exclusion list underneath it is where the real coverage is decided, and it is the part of the policy that rarely gets a second look after go-live.
The short answer
Exclusions are normal and sometimes necessary. The risk is not that they exist, but that they outlive the reason they were added. A short, regular review closes the gap:
- Find every account and group excluded from every Conditional Access policy.
- Name who each exclusion is for, who owns it and why it is still needed.
- Keep the deliberate ones, document them and watch how they are used.
- Remove everything else, testing changes in report-only mode first.
Why exclusions pile up
Exclusions are almost always added for a good reason at the time. A rollout is under way and something breaks: the scanner that emails documents cannot complete a multi-factor prompt, a director is travelling and cannot sign in, a service account used by an older application keeps failing. Someone adds the account to the exclusion list so work can continue.
The rollout finishes. The exclusions stay. Microsoft's own guidance on managing exclusions notes that over time more users get added and the list grows. Nobody owns the list, so nobody shrinks it.
Months later, the policy still reads "all users", the dashboard still shows it as on, and a handful of accounts quietly skip it. Some of them, such as shared mailboxes and service accounts with long-standing passwords, are exactly the accounts an attacker would try first.
What an exclusion actually does
In Microsoft Entra ID, exclusion wins. If an account is both included and excluded in the same policy, it is excluded. Microsoft states plainly that the exclude action overrides the include action.
That has three practical effects:
- The policy does nothing for that account. If the policy requires multi-factor authentication, the excluded account signs in with a password alone, unless another policy covers it.
- Group exclusions are wider than they look. Exclusions apply to nested users and groups. If a group is excluded, anyone added to that group later is excluded too, and Microsoft points out that users can be added to such a group to bypass the policy.
- People often do not know. Microsoft lists limited visibility as a problem with exclusions: users might not know they are excluded, and accounts that once qualified for an exclusion may no longer do so.
The exclusions you should keep
A review is not about reaching zero. Some exclusions are deliberate and recommended.
Emergency access accounts. Microsoft recommends two or more cloud-only emergency access, or break-glass, accounts, excluded from policies that could otherwise lock every administrator out of the tenant. These should use strong sign-in methods stored securely, should not belong to any one person, and their sign-ins should be monitored so any use is noticed straight away.
A test exclusion during a new rollout. When a new policy is introduced, Microsoft advises applying it to a small set of users first and excluding at least one administrator to avoid lockout. That exclusion belongs to the rollout and should be removed when the rollout ends.
Anything else needs a documented reason, an owner and an end date. If an exclusion cannot be explained in one sentence, it is a candidate for removal.
A five-step exclusion review
- List every policy and every exclusion. In the Microsoft Entra admin centre, open each Conditional Access policy and record the excluded users, groups, roles and guest types. Expand excluded groups so you can see who is actually in them.
- Name an owner and a reason for each. For every excluded account, write down who it is for, who in the business is responsible for it and why it still cannot meet the policy. Accounts with no owner or no reason go on the removal list.
- Check how each excluded account is used. Review the sign-in logs for excluded accounts. The Conditional Access tab in each sign-in record shows which policies applied. An account that has not signed in for months, or signs in from places you do not expect, is a priority.
- Fix the underlying problem, then remove the exclusion. Replace scan-to-email logins with a supported method, move travelling staff onto an approved sign-in method, and retire or replace old service accounts. Test the change with the policy in report-only mode before enforcing it, so you can see what would have been blocked.
- Put the remaining exceptions in a named group. Instead of excluding individual accounts, exclude one clearly named group per policy, so the list lives in one place and can be reviewed on a schedule.
Keeping the list short after the review
A one-off clean-up drifts back unless the list has an owner. Three habits help:
- Every new exclusion gets a ticket. Who asked, why, and when it will be removed.
- Exclusion groups are reviewed on a schedule. With Microsoft Entra ID P2 or Microsoft Entra ID Governance, access reviews can ask members or owners to confirm the exclusion is still needed and remove those who do not respond. Without those licences, a calendar reminder and a short checklist do the same job by hand.
- Policy changes are checked against the baseline. Any change to a Conditional Access policy, including its exclusions, is recorded in the audit log. Reviewing those changes regularly catches exclusions added in a hurry.
This is the same discipline as reviewing guest accounts: access that was granted for a reason should be taken back when the reason ends. We covered that side in our article on reviewing Microsoft 365 guest accounts.
Frequently asked questions
Should anyone be excluded from an MFA policy for all users?
Yes, but very few accounts. Microsoft recommends excluding two or more cloud-only emergency access accounts from policies that could lock administrators out. Temporary exclusions during a rollout are also normal. Everything else should have a documented reason and an owner, or be removed.
How do I find every exclusion in Conditional Access?
Open each policy in the Microsoft Entra admin centre and check the Exclude tab under users, and any excluded groups, roles or guest types. Expand excluded groups to see their members. The What If tool can also show which policies apply, or do not apply, to a specific user.
Do excluded users know they are excluded?
Often not. Microsoft lists this as one of the visibility problems with exclusions. A user who was excluded during a rollout may never be told, and may never notice that they are no longer asked for a second factor.
Can exclusion reviews be automated?
Yes, if exclusions are managed through a Microsoft Entra group. Access reviews can recertify group members on a schedule and remove anyone who is not confirmed. Access reviews need Microsoft Entra ID P2, Microsoft Entra ID Governance or Enterprise Mobility + Security E5.
What licence do I need for Conditional Access?
Conditional Access needs Microsoft Entra ID P1, which is included in Microsoft 365 Business Premium, E3 and E5. Tenants without it rely on security defaults, which work differently and do not have per-policy exclusion lists.
Where to start
Pick your most important policy, usually multi-factor authentication for all users, and write down every exclusion it has today. If any name on the list makes you ask "why is that there?", the review has already paid for itself.
Onprem2Cloud IT Solutions Co. is a Microsoft CSP partner based in Muntinlupa City, Metro Manila. We review Conditional Access policies and their exclusions, fix the reasons accounts were excluded in the first place, and roll out changes safely in report-only mode before they are enforced. See our cybersecurity services or contact us to arrange a review.
What's happening
Our latest news and trending topics
