Episode Details
Back to Episodes
Your Conditional Access Policy Has Trust Issues: We Need To Talk
Published 3 months ago
Description
(00:00:00) Conditional Access Troubleshooting
(00:00:30) Overbroad Exclusions: The Invisible Leaks
(00:04:56) Device Compliance Gaps: Setting Clear Boundaries
(00:09:02) Token Theft Scenarios: Protecting Against Session Hijacking
(00:12:46) Building a Calming Baseline
(00:18:06) Safe Rollout Test Plan
(00:20:34) Monitoring and Alerts for Healthy CA
(00:25:02) Closing Thoughts and Next Episode Preview
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.
(00:00:30) Overbroad Exclusions: The Invisible Leaks
(00:04:56) Device Compliance Gaps: Setting Clear Boundaries
(00:09:02) Token Theft Scenarios: Protecting Against Session Hijacking
(00:12:46) Building a Calming Baseline
(00:18:06) Safe Rollout Test Plan
(00:20:34) Monitoring and Alerts for Healthy CA
(00:25:02) Closing Thoughts and Next Episode Preview
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.