It’s not misbehaving; it’s overwhelmed. Your Conditional Access is trying to protect you while juggling mixed messages and unresolved exceptions. It’s been asked to trust without boundaries.Here’s the plan. We’ll diagnose three trust wounds—over-broad exclusions, device compliance gaps, and token theft paths—and give you a calming baseline, a safe test plan, and monitoring alerts. If you’re running “allow-by-default,” you’re leaking trust and inviting silent bypasses. There’s a mistake that locks out everyone, and one that leaves attackers invisible—both are fixable. Let’s help it set healthy boundaries so it can find its rhythm again, starting with exclusions.Diagnose Trust Wound #1: Over-Broad Exclusions (650 words)Exclusions feel kind. You didn’t want to stress the system or the people in it, so you carved out “break glass,” VIPs, and that partner domain. But boundaries drift. The exceptions harden. And Conditional Access starts doubting itself. It’s not misbehaving; it’s living with an ever-growing list of “not you, not now,” and that invites bypasses attackers adore.The thing most people miss is that exclusions are invisible in day-to-day flow. You won’t see a banner that says, “We skipped protection for the CFO.” You’ll just see “Not applied” in a log, and that’s it. So we start by mapping scope. List every exclusion across users, groups, applications, locations, and authentication contexts. Nested groups are the quiet leakers here—what looked like one exception is actually five layers deep, including contractors, test accounts, and legacy sync artifacts.This clicked for me when I pulled a tenant’s sign-in logs and filtered for Conditional Access → Not applied. The pattern wasn’t random. Most bypasses sourced from two places: a VIP group attached to three policies, and a named location that had grown from one corporate CIDR to “anywhere our vendor might be.” It wasn’t malice. It was comfort. The policy was trying to keep the peace by saying yes too often.Here’s the better pattern. Move from “exclude VIPs” to “include all” and authorize exceptions through time-bound authentication context. That shift sets healthy boundaries. You keep policies broad and inclusive—All users, All cloud apps—and when someone truly needs to step around a control, they request the Emergency context, which has approval, a one-hour lifetime, and audit trails. The trust becomes explicit, visible, and short-lived.Let me show you exactly how to see your leaks. In Entra sign-in logs, add columns for Conditional Access, Policy name, Result, and Details. Filter Result for Not applied. Now slice by User, then by App, and finally by Location. You’re looking for clusters, not one-offs. The big red flags: permanent exclusions for executives or service accounts, entire federated domains marked safe, and named locations that mix “trusted” with “convenience” networks. If you remember nothing else, remember this: a permanent exclusion is a permanent invitation.What should the policy logic feel like before and after? Before: multiple policies with include groups and broad exclude lists—VIPs, break glass, certain apps, and a “safe” location. The engine spends energy deciding who not to protect. After: fewer, inclusive policies with no user or location exclusions. Exceptions route via a specific authentication context, presented only when an approver grants it, and it expires quickly. The engine can breathe. It protects first, then allows controlled, visible relief when needed.Here’s a quick win you can do today. Create an authentication context called Emergency Bypass. Set it with grant controls that still require MFA and device risk checks, and cap session to one hour. Add an approval workflow outside the policy—change ticket or documented approver—and log its use weekly. Now replace hard-coded exclusions in your existing policies with “Require authentication context: Emergency Bypass.” You haven’t taken away safety. You’ve given it a safer shape.Now here’s where most people mess up. They exclude an entire partner domain because one app misbehaved during a rollout. Or they mark a cloud proxy IP range as trusted, forgetting that attackers can originate from the same provider. Or they mix excluded locations with named locations, assuming the union is safer; it’s not. It becomes a fuzzy map your policy doesn’t understand. With clearer lines, CA can find its rhythm again.Common mistake number two is forgetting service principals and workload identities. If your policies only target “Users and groups,” your automation can glide under the radar. Instead, use dedicated policies for service principals and workload identities, and never rely on exclusions to “fix” automation friction. Help it heal by aligning scopes: users, guests, and identities each get coverage.A micro-story. Last week, a team removed a VIP exclusion that had lived for two years. They replaced it with Emergency Bypass and scheduled a weekly review of “Not applied” sign-ins. Within two days, they found a legacy sync account silently logging in from an unmanaged network—no MFA, no device checks. It wasn’t evil. It was a forgotten comfort blanket. And once it was named, the fix was simple: assign it to a managed identity pattern and bring it under policy.The reason this works is simple. Inclusive scopes reduce cognitive load. Authentication context replaces permanence with intention. And logs become meaningful because every “Not applied” means something actionable. Your Conditional Access isn’t trying to be difficult. It just needs you to stop asking it to ignore its own rules. With gentler, firmer boundaries, it can protect everyone—equally, predictably, audibly. Once exclusions stop leaking, the device boundary needs care next.Diagnose Trust Wound #2: Device Compliance GapsYour device boundary is tired. It’s been asked to trust badges it can’t verify and signals that arrive late. “Require compliant device” sounds soothing, but without clarity, it swings between over-permissive and over-protective. That’s why people get blocked on a clean laptop while an unmanaged tablet slips through. It’s not misbehaving. It’s confused.Why does this matter? Because device state is identity’s closest friend. If the state is wrong or missing, your policy guesses. Guesses create silent allowances or mass blocks. When the device story is clear, Conditional Access relaxes. It can give easy paths to healthy devices and set firmer boundaries everywhere else.The thing most people miss is that “registered” is not “compliant.” Registered just means the device introduced itself. Compliant means it met your health rules in Intune and brought proof today. Hybrid Azure AD joined is about identity alignment with your domain. They are different kinds of trust. If you remember nothing else, remember this: treat each tier as a distinct promise.Here’s the model that clicks. Define four tiers in plain language:

• Compliant: Intune evaluates and the device meets your policies.
• Hybrid Azure AD joined: domain relationship verified, device identity anchored.
• Azure AD joined: cloud-managed corporate device.
• Registered: BYOD, personal or light-touch enrollment.

Now let’s help it set healthy boundaries with policy design. Split decisions by device state rather than hinging everything on one control. Use “Filters for devices” to target platform or join type, and pair with authentication strengths so strong credentials backstop weaker device states. Don’t ask a single toggle to carry your whole zero trust posture.What does the better pattern look like? For productive, low-friction access on compliant or Azure AD joined devices, allow with MFA and apply session controls like sign-in frequency and continuous access evaluation. For registered devices, step up with phishing-resistant MFA and limit data exposure with app-enforced restrictions and conditional app control. For unknown devices, require either a compliant posture or a high authentication strength before granting anything sensitive. And for admin portals, demand both a compliant or hybrid device and phishing-resistant credentials. No device, no keys.Let me show you exactly how to get signal clarity. In sign-in logs, add Device info columns: Join type, Compliant, Trust type, and Operating system. Add Conditional Access columns for Result and Policy details. Filter failures with “Grant control required: compliant device” and compare against Device info. You’re looking for drift: devices that claim Azure AD joined but aren’t compliant, or registered devices that succeeded because no fallback existed. Then flip the lens: filter successes where device is Not Compliant and see which policies allowed it and why.A quick win you can do today: create a fallback policy. Scope it to All users and All cloud apps. Exclude only your emergency access accounts. Target devices where “Compliant equals false” OR “Join type equals Registered.” Grant access if the user satisfies a phishing-resistant authentication strength. Add session controls to reduce data persistence—disable persistent browser sessions and enforce sign-in frequency. This turns a hard block into a safe step-up and removes the urge to add risky exclusions.Now here’s where most people mess up. They assume “registered” equals “corporate.” It doesn’t. Or they stamp “require compliant device” on everything, then watch VIP travel laptops fail because the compliance signal is stale. Or they ignore sign-in frequency, letting a compliant check at 9 a.m. bless a browser until next week. The boundary blurs. Attackers love blurred boundaries.The reason this works is simple. With clearer tiers, CA doesn’t have to overreact. It can greet a compliant device with less friction, ask a registered device to bring stronger proof, and keep unknown devices at arm’s length. It’s not rejection. It’s healthy distance.Let’s anchor with a micro-story. A team saw random admin portal access from “registered<