table of contents
A single exclusion can turn a strong Conditional Access design into a shortcut around MFA, device checks, or location rules. That risk got sharper in June 2026, because Microsoft changed how some low-privilege sign-ins are handled when resource exclusions are present.
If you manage Microsoft Entra ID, this is the review that keeps quiet exceptions from becoming a clean bypass path. Start with the policies that cover All resources, then work outward through users, groups, roles, workloads, locations, devices, guest accounts, service accounts, emergency access accounts, and legacy authentication.
Quick table of contents
- Why Conditional Access exclusions create bypass risk
- Where bypass risk hides
- A step-by-step audit process
- Practical checklist before enforcement
- Conclusion
- FAQ
Why Conditional Access exclusions create bypass risk
Conditional Access works best when the policy scope is broad and the exceptions are narrow. Microsoft’s Plan Your Microsoft Entra Conditional Access Deployment guidance pushes that same idea, start broad, then tighten the few places that truly need a carve-out.
The problem starts when exclusions grow for convenience. A group gets added for testing, a service account stays exempt after a project ends, or a guest account gets a temporary pass that never expires.
Microsoft’s 2026 change makes this even more important. Sign-ins that request only low-privilege scopes like openid, profile, email, and offline_access no longer sidestep Conditional Access the way some teams expected when resource exclusions exist. Rollout began on March 27, 2026, and enforcement starts June 15, 2026.
If a policy looks safe because the excluded app or account is “special,” treat that as a warning, not a control.
The risk is highest when a policy targets All resources and the excluded item has broad trust inside the tenant. That can hide paths around MFA, compliant device checks, and sign-in restrictions.
Where bypass risk hides
The quickest way to spot trouble is to map each exclusion type to its likely blast radius. That gives you a clean view of what can slip through and why.
| Exclusion type | Common bypass risk | What to verify | Safer move |
|---|---|---|---|
| Users and groups | One membership change can dodge MFA or device rules | Check static groups, dynamic groups, and nesting | Use smaller, time-bound exceptions |
| Directory roles | Privileged roles often get broad trust | Review why the role is excluded | Separate admin access from user access |
| Workload identities and service accounts | Automation can become a long-lived blind spot | Confirm app owner, scope, and sign-in pattern | Tie the exception to one app and one purpose |
| Named locations | VPN or cloud egress can make a bad source look safe | Review trusted IP ranges and geo logic | Keep location trust narrow and documented |
| Devices | A trusted device rule can miss unmanaged endpoints | Check compliance, join state, and filters | Require managed, compliant devices |
| Guest accounts | External users can move around weaker controls | Review sponsor, group access, and renewal dates | Apply stricter controls to guests |
| Emergency access accounts | Overuse weakens break-glass design | Confirm monitoring and secure storage | Exclude only where truly needed |
| Legacy authentication | Old protocols can bypass modern controls | Find IMAP, POP, SMTP AUTH, and basic auth use | Block legacy auth and migrate clients |
Microsoft’s Conditional Access Templates: Simplify Security page is useful when you want a clean baseline before you add exceptions back in. Templates help reduce the messy policy sprawl that makes exclusions hard to trace.
A few bypass patterns to watch closely
A guest account excluded from a broad policy can become the easiest path for external access. That is especially true when the guest also belongs to a shared app group.
A service account used by a scanner, sync job, or old script often looks harmless. Still, if it sits outside MFA and device controls, an attacker who steals its token or password gets a quiet entry point.
A location exclusion is fragile when the trusted IPs belong to a VPN provider, a cloud host, or a partner network. Those ranges can expand, shift, or get reused by someone you never intended to trust.
Legacy authentication deserves its own look. Older mail protocols and basic-auth flows often survive in printers, scanners, and line-of-business tools, and they can undercut the rest of your policy design.
A step-by-step audit process
Start with the policies that matter most. In the Entra admin center, look for policies that target All resources or very broad app scopes, then list every exclusion tied to them.
- Export the current policy set.
Capture the assignment, grant, session, and exclusion settings for each policy. A spreadsheet is fine if it stays current. - Record the business reason for every exclusion.
Ask who requested it, when it was approved, and when it should expire. If nobody can answer that fast, the exception is already stale. - Check the excluded identities and assets against real sign-in data.
Use sign-in logs and Usage & insights to see which users, apps, and service principals are active. Compare that activity to the exception list. - Test risky apps in report-only mode first.
This is the safest way to see whether a policy will trigger MFA, require a compliant device, or block access. Test the paths that use the excluded app or account, not only the main browser flow. - Review emergency access design on its own.
Break-glass accounts should be rare, tightly controlled, and monitored. They should not become a casual exception for every hard problem in the tenant. - Check legacy authentication before you enforce.
Find clients and protocols that still use basic auth, then confirm the policy blocks them as expected. Old mailbox tools and scanners often surface here. - Re-test after remediation.
Remove one exclusion at a time when you can. That makes failures easy to trace and avoids a broad outage. - Document the final decision.
Keep the reason, owner, expiry, and compensating control in the policy record. Audit teams care about that trail almost as much as the setting itself.
If the review turns up a stack of old exceptions, Book a Discovery Call with Bud Consulting to map the risk surface and clean up the policy set.
Practical checklist before enforcement
Use this list right before you move a policy out of report-only mode.
- Every exclusion has a named owner.
- Every exclusion has a business reason.
- Every exclusion has an expiry date or review date.
- Emergency access accounts are documented and monitored.
- Guest access is limited and reviewed on a schedule.
- Service accounts and workload identities are tied to a single purpose.
- Named locations match current corporate egress ranges.
- Device-based exceptions still require managed or compliant endpoints.
- Legacy authentication is blocked or isolated.
- Sign-in logs show no unexpected access through the excluded path.
- The policy was tested in report-only mode first.
- A rollback plan exists if the rule causes a service issue.
If even two of these are missing, the exception list needs another pass.
Conclusion
The safest Conditional Access design is broad on coverage and narrow on exceptions. That matters even more now, because Microsoft’s 2026 enforcement changes make some old assumptions about resource exclusions obsolete.
Audit the exclusions that hide behind convenience, then prove each one still deserves a place. If you can’t explain why a user, group, role, workload, location, device, guest, or service account is outside the rule, you probably already found a bypass risk.
FAQ
What Conditional Access exclusions are the riskiest?
The riskiest ones are usually broad user or group exclusions, privileged role exclusions, and long-lived service account exceptions. Guest accounts and named locations can also create easy bypass paths when nobody reviews them.
Should emergency access accounts be excluded from Conditional Access?
Usually yes, but only with a tight design. Break-glass accounts need a documented purpose, strong storage controls, monitoring, and a very small exception set.
Why does the June 2026 Microsoft change matter?
Microsoft is changing how some low-privilege sign-ins are enforced when resource exclusions are present. That means older assumptions about “safe” excluded apps may no longer hold.
What should I look for in sign-in logs?
Focus on sign-ins for excluded users, groups, roles, workload identities, and apps. Then compare those events with MFA prompts, device claims, and any access that should have been blocked.
