Conditional Access in 2026: how to design a baseline that actually holds

A practical policy set, the design logic behind it, and three things that changed this year

Most Conditional Access content you find online is a list of toggles. Turn this on, set that to require MFA, here is where the setting lives. That is the easy part. The skill is knowing which policies belong in a baseline, what order you enforce them in, and which mistakes lock you out of your own tenant. A 2026 baseline is also not a 2024 baseline, because a few things changed underneath it this year.

Conditional Access is a design task, not a configuration task

The fastest way to understand Conditional Access is to lock yourself out with it. One broad policy flipped to On without exclusions or a staging pass, and every account in the tenant is gated behind a control nobody can satisfy yet, admins included. The first principle of a baseline is anti-lockout design. Feature coverage comes after. If your design conversation starts with “which controls do we want” instead of “how do we avoid locking ourselves out while we get there,” the order is already wrong.

Break-glass first, everything else second

Before a single policy goes live, you need two cloud-only emergency access accounts on the .onmicrosoft.com domain. Not tied to any individual. Global Administrator assigned permanently, not PIM-eligible, because PIM activation can itself depend on the controls you are about to enforce. Both accounts go into a dedicated security group, and that group is excluded from every Conditional Access policy you build.

There is a catch that surprises people who set this up expecting CA exclusions to be the whole story. Microsoft’s mandatory MFA enforcement applies to break-glass accounts regardless of your CA exclusions, because it fires at the client application level when the account hits the Azure portal, Entra admin center, or Intune admin center. It is not evaluated through Conditional Access at all, so excluding the account from CA does nothing to it. A long password alone no longer gets these accounts in. You need FIDO2 or certificate-based authentication registered on them. This has been the case since the enforcement rolled out, and it is the part of break-glass design most likely to be stale in an older runbook.

Monitoring closes the loop: alert if either account ever signs in. A break-glass sign-in is either a real emergency or an incident. Both are worth a page.

The baseline policy set

Here is the set I run, CA002 through CA012. The numbering leaves CA001 open deliberately, and the names lead with persona and control so the list reads top to bottom without needing a legend.

Microsoft Entra Conditional Access policy list showing the CA002 through CA012 baseline with each policy’s state, mix of On and Report-only

Table of the eleven-policy Conditional Access baseline, CA002 through CA012, showing each policy’s target, condition, grant or session control, and starting state

A few of these carry design decisions that are not obvious from the row.

CA002 uses Require authentication strength set to Phishing-resistant MFA, which means FIDO2 or Windows Hello for Business. Standard MFA is not sufficient for privileged accounts in 2026. There is a portal constraint worth knowing before you build it: Require authentication strength cannot be combined with Require multifactor authentication in the same grant. The portal blocks it and tells you why.

CA002 grant controls showing Phishing-resistant MFA selected and the authentication-strength constraint

This one starts in Report-only and stays there until the hardware is actually in your admins’ hands. Enforcing phishing-resistant MFA before the FIDO2 keys arrive is a self-inflicted lockout of exactly the accounts you most need.

CA003 is a separate policy from CA002 on purpose. Sign-in frequency and MFA enforcement are two different concerns, and binding them into one policy makes both harder to reason about and to change later. Two concerns, two policies.

CA004 is the broadest policy in the set, all users and MFA. The break-glass exclusion here is non-negotiable. If you only remember to exclude break-glass from one policy, it is this one.

CA005 targets only Exchange ActiveSync and Other clients in the client apps condition. Leave the browser and modern auth client checkboxes unselected. Tick all of them and you have written a policy that blocks everything, including the modern clients you intend to allow.

CA006 requires compliant or hybrid joined, one of the two, not both. Report-only first, and this is one where the report-only logs earn their keep. Before you enforce, read the logs for unmanaged and home devices, including your own admin workstation if it is not enrolled. The policy will happily block the machine you administer from, which is a memorable way to learn the lesson.

CA007 is the one that changed this year. Use Require app protection policy, not Require approved client app. The approved-client-app grant moves to a read-only state on June 30, 2026, after which it is no longer enforced, and any policy still leaning on it silently grants access without the control you thought you had. Scope this to iOS and Android only. It also needs a corresponding Intune App Protection policy to exist, or the grant evaluates against nothing and gives you a false sense of coverage.

CA008 is named by control, “Block-HighRiskCountries,” not by the country list itself. The list will change. The policy name should not have to.

CA009 blocks the device code authentication flow through the Authentication flows condition, which is relatively new as conditions go. Microsoft’s own guidance is to get as close as possible to a tenant-wide block, allowing device code flow only in documented cases like legacy tooling that cannot be updated. Report-only first so you can see what legitimately uses it in your tenant before you cut it off.

CA010 targets a user action, register or join a device, not a resource. It pairs with a setting in Entra device settings, where Require Multifactor Authentication to register or join devices should be set to No. CA010 enforces the MFA requirement; the legacy toggle does the same thing through an older mechanism, and leaving both on creates a conflict. Microsoft’s own UI banner now points you to Conditional Access over the legacy toggle. One caveat if you run external authentication methods: those are currently incompatible with authentication strength, so this policy uses the Require multifactor authentication grant rather than an authentication-strength grant.

Entra device settings showing the MFA registration toggle set to No with Microsoft's recommendation to use Conditional Access

CA011 is risk-based sign-in MFA, and it requires Entra ID P2 with Identity Protection. Keep it in Report-only for two to four weeks minimum and watch the sign-in risk report in Identity Protection before you enforce. False positives on legitimate travel and new devices are common, and enforcing early teaches your users that the security team blocks them for taking a trip. Worth noting that most mid-market clients are on P1, so this policy is tier-dependent. If you are on P1, it is not an option, and that is a property of the license tier, not a gap in the design.

CA012 is token protection, generally available on Windows and in preview on Apple platforms. Target Exchange, SharePoint, and Teams specifically, not All resources, and note it covers desktop and native clients only, not browser sessions. It requires P1 and a Windows 10 or newer device that is Entra joined, hybrid joined, or registered, since those are the devices that can issue the device-bound Primary Refresh Token the control checks for. The honest limitation: browser-based token theft through stolen cookies is not covered by this. Token protection is one layer in a defense-in-depth posture, not a complete answer to token theft. Useful, bounded, worth deploying with the boundary understood.

Three things that changed in 2026

The approved client app grant retires June 30, 2026. Any baseline built before that and still using Require approved client app is broken as of that date. The grant moves to read-only and stops being enforced, so the policy keeps evaluating but the control is treated as if it were never selected. Replace it with Require app protection policy, as in CA007 above.

The resource-exclusion enforcement change has a longer runway than most people realize. Microsoft began rolling it out on March 27, 2026, with automatic enforcement scheduled to begin June 15, 2026 and progress over several weeks after that. The gap it closes works like this. Until now, a sign-in through a client application that requests only OIDC scopes, like openid, profile, or email, or a limited set of directory scopes like User.Read, was not subject to a Conditional Access policy targeting All resources if that policy had any resource exclusions. The policy was skipped entirely for those sign-ins. After the change, those policies enforce even when resource exclusions are present, so a flow that used to pass straight through now has to satisfy MFA, device compliance, or whatever else the policy requires.

This only matters if you have an All-resources policy with one or more resource exclusions. If none of your policies are configured that way, the change does not affect you, and Microsoft will tell you which case you are in through a Message Center notification if your tenant is impacted.

You also have a control here, which is the part worth knowing as the person designing the baseline. The behavior is governed by a Baseline scopes setting in Entra. You can enforce the new model immediately, disable enforcement to revert while you remediate, or customize it by assigning a tenant-owned application as the target resource for baseline scopes and excluding that application from your All-resources policies instead. The practical reason this matters: tools like the Azure CLI authenticate with exactly the low-privilege scopes this change targets, so if you have a fragile custom app or an automation flow that cannot handle a Conditional Access challenge, the Baseline scopes setting is your lever to stage the change rather than have it land on you unannounced.

Mandatory MFA enforcement is still catching people out. This one did not start in 2026, but it keeps surfacing in baseline reviews, so it belongs here. Microsoft’s tenant-level MFA enforcement for the admin portals applies even to break-glass accounts, and it runs at the client application level rather than through Conditional Access. CA exclusions still matter for everything you build, but they do not exempt an account from this. FIDO2 or certificate-based authentication is required. If your runbook still assumes a long password gets a break-glass account into the Azure portal, it is out of date.

Staging enforcement without breaking sign-ins

Report-only is not a draft state. It is an active evaluation state. Every policy in Report-only is being evaluated against real sign-ins right now, and the result is recorded without being applied. That is the whole point of it.

Two tools tell you what a policy would do before it does it. The What If tool lets you model a hypothetical sign-in and see which policies would apply. The Conditional Access tab in the sign-in logs shows you what each policy actually evaluated to against real sign-ins that already happened, Report-only results included. Read those before you enforce anything broad.

The process is the same every time. Report-only, review the logs for two weeks, pilot group, then enforce tenant-wide. Never flip a broad policy from Report-only straight to On without that cycle. The discipline of staging is the difference between a baseline that holds and one that takes the tenant down on a Monday morning.

The naming convention

The names in the table follow a pattern: a CA### prefix, the persona the policy applies to, and the control it enforces. Microsoft requires a consistent naming convention but does not prescribe a format, so the numbered-persona pattern is a community standard rather than an official one. The practical reason the discipline matters is the 240-policy-per-tenant limit. A tenant with sprawling, inconsistently named policies hits that ceiling with duplication nobody can untangle, and consolidation after the fact is far harder than naming well from the start.

A baseline is not a fixed artifact you build once. It is a set of decisions you can defend, staged in an order that does not lock you out, named so the next person can read it. The toggles are the last ten percent. Questions about which path fits your environment are welcome. Feel free to reach out.