Contact
← All vlogs
Identity & Access9 min · Script ready — not yet recorded

Conditional Access Done Right: A Framework for Scaling Policy

Most Conditional Access deployments start clean and get messy within six months. This episode walks through a policy framework that scales — naming, layering, exclusions, and the one tenant-wide guardrail every environment should have.

Episode not yet live

This brief is script-ready. Subscribe to @cyberzonic on YouTube to be notified when it publishes.

Overview

Conditional Access is the control plane of modern identity security. It is also the first thing that becomes unmanageable when a tenant grows. This episode gives you a practical framework for scaling policy without losing control: how to name policies, how to layer them, how to handle exclusions, and why every environment needs a tenant-wide guardrail you never touch.

Key takeaways

  • Name policies with a consistent schema so you can read your tenant at a glance
  • Layer policies by purpose: baseline, workload, user-risk, sign-in-risk, device-state
  • Exclusions are a risk register — every exclusion must have a named owner and an expiry date
  • Every environment needs a 'break-glass' policy guardrail that blocks risky configurations
  • Report-only mode is not optional — it is how you validate every policy before enforcement

Episode script

Welcome back. Today we're talking about Conditional Access — the policy engine inside Microsoft Entra ID that decides who gets in, from where, on what device, with what trust. If identity is the new perimeter, Conditional Access is where you draw that perimeter. And most teams draw it badly. Let me show you a framework that scales.

Start with naming. Every policy in your tenant should follow a strict naming schema. Here's one that works: Category dash Target dash Intent dash Environment. So for example, 'CA001-AllUsers-RequireMFA-Production' or 'CA012-Admins-BlockLegacyAuth-Production.' This sounds trivial. It is not. When you open a tenant six months into a rollout and see forty-three policies called 'New Policy 17,' you lose the ability to reason about your security posture. Consistent naming is the first line of defence against drift.

Next, layering. Think of Conditional Access policies as layers, not a pile. There are five layers worth separating:

Layer one — baseline. These are the policies that apply to everyone, every session, with no exceptions: block legacy authentication, require MFA for all users, require compliant devices for privileged roles. Baseline policies are short, simple, and change rarely.

Layer two — workload. These target specific cloud apps or services: require MFA for Office 365, require device compliance for Azure management, block access to SharePoint from unmanaged devices. Workload policies scale horizontally as you onboard more applications.

Layer three — user risk. These respond to signals from Entra ID Protection: block sign-in when user risk is high, require password change on medium user risk, require MFA on any non-zero risk. User risk layer is your adaptive response.

Layer four — sign-in risk. Similar to layer three but for the session itself: high sign-in risk blocks, medium requires MFA, low is allowed. Keep these separate from user risk even though they feel similar — they respond to different signals and you'll tune them differently.

Layer five — device state. Compliant device required for sensitive apps, domain-joined or Entra-joined required for admin portals, platform-specific policies for iOS and Android.

Five layers. That's your mental model. Every new policy goes into exactly one layer. If you can't decide, the policy is probably wrong.

Now, exclusions. Every Conditional Access deployment collects exclusions like dust. A contractor can't MFA. A service principal is exempt. A shared mailbox account doesn't support device compliance. Before you know it, your clean policy has forty-seven excluded users and you've lost track of why. Treat exclusions as a risk register. Every exclusion needs three things: a named human owner, a written reason, and an expiry date. Review them quarterly. Anything without an owner gets removed.

Now the guardrail. Every tenant should have one policy you never touch: a break-glass policy that blocks the most dangerous configurations. For example, 'block any sign-in from anonymous or Tor exit nodes, no exclusions, no overrides, everywhere, all the time.' This is your tripwire. If someone else in the tenant accidentally opens a hole, this catches it. Put it in a naming category like 'GUARD' so it never gets confused with normal policies.

Finally, report-only mode. Every single policy you create starts in report-only. You run it for at least seven days, usually fourteen, and you check the sign-in logs to see what would have been blocked, who would have been inconvenienced, and what you missed. Only then do you switch to 'on.' I have seen more outages caused by skipping this step than by any other Conditional Access mistake. Report-only is not optional.

To recap. Name your policies with a schema. Layer them into baseline, workload, user risk, sign-in risk, and device state. Treat exclusions as a risk register with owners and expiry dates. Run a break-glass guardrail that never changes. And always, always use report-only first.

Do these five things and your Conditional Access deployment will scale with your tenant instead of against it. Skip them and you'll rebuild the whole thing in eighteen months. I've seen both.

Subscribe for more. See you in the next episode.

References