Conditional Access rollout: lessons learned, and what breaks on day one

How I'd roll out Microsoft Entra Conditional Access today, from my own hands-on experience and lab, checked against Microsoft Learn (October 2026).

Conditional Access is the only feature I know where one wrong click can lock out the person who made the click. Scope a "block" policy to All users and All resources, forget one exclusion, press On, and you have changed the locks with the keys still inside. Happily, most day-one disasters can be avoided with a boring, repeatable process.

All names below (Contoso, CA-Pilot-Users, CA-EmergencyAccess) are lab examples. The policy list is an HTML mock, not a screenshot.

TL;DR

• Before the first policy: two tested emergency access accounts, excluded from every policy that blocks or restricts.
• Every policy takes the same road: report-only (at least a week), What If plus a real test sign-in, On for a pilot group, then wider.
• Most day-one breakage comes from things you didn't look at: legacy auth in non-interactive sign-ins, service accounts, user actions that report-only can't evaluate, and the helpdesk not ready for MFA resets.

The case at a glance

Table of contents

• 1. Before you create a single policy
• 2. Start with a small baseline
• 3. Name and scope like someone will call you at 2 a.m.
• 4. Report-only: the dress rehearsal
• 5. What If, then a real sign-in
• 6. The rollout order I'd use
• 7. Plan the rollback before you need it
• Gotchas: what breaks on day one
• Rollout checklist
• Sources

1. Before you create a single policy

Four things, in this order.

Licenses and roles. Conditional Access needs Microsoft Entra ID P1 (risk-based conditions need P2). To create and edit policies, use Conditional Access Administrator, not Global Administrator. Security Reader can read them.

Security defaults: swap, don't switch off. If the tenant runs security defaults today, that is your MFA safety net. Microsoft says you must disable them when Conditional Access replaces them, and then immediately enable your policies. My lesson: never disable security defaults "for a while, just to test". Build and test the replacements in report-only first, so the gap is minutes, not weeks.

Emergency access (break-glass) accounts. Microsoft's guidance:

• At least two, cloud-only, on the *.onmicrosoft.com domain, not synced or federated.
• Global Administrator assigned active permanent, not eligible in PIM.
• Strong passwordless sign-in, passkey (FIDO2) recommended, or certificate-based authentication if you already have PKI. Don't reuse the methods your normal admins use.
• An alert on every sign-in of these accounts, and a test at least every 90 days.
• Put them in one group (mine is CA-EmergencyAccess) and exclude that group from every policy that blocks or restricts sign-in.

Groups. Create them first: CA-Pilot-Users (real users who agreed to go first), CA-Pilot-Admins, CA-Test-Users (accounts you can break freely) and CA-Exclude-Temp (short-term exceptions with an end date). Keep test accounts and pilot users apart, or you can't tell "the policy works" from "my test account is weird".

Sources: Plan a Conditional Access deployment · Security defaults · Manage emergency access accounts

2. Start with a small baseline

A security baseline is not every policy you can think of. It is the smallest set that blocks the common identity attacks. Microsoft's Secure foundation templates are a good shopping list, and five of them make a solid first round:

Device compliance and risk-based policies wait for round two.

Templates or custom? Templates are the fastest start and are created in report-only by default. But they exclude only the account that created them, so open each one and add your break-glass group and pilot scope.

For admins, Microsoft lists 14 built-in roles to cover at a minimum, from Global Administrator to Helpdesk Administrator, and suggests phishing-resistant MFA through authentication strength when you are ready.

Sources: Conditional Access templates · Require MFA for administrators

3. Name and scope like someone will call you at 2 a.m.

Conditional Access has no "owner" or "description you'll actually read" field, so the name does all the work. Microsoft suggests a name that shows a sequence number, the apps, the response, who and when. In my lab: CA03 - All resources: Require MFA - Pilot. On the phone, "open CA03 and set it to Report-only" takes ten seconds. "Open the MFA one, no, the other MFA one" takes ten minutes.

Scoping rules I follow:

• Users: pilot group first, never All users on day one, even when the template says so.
• Resources: prefer All resources over a list of apps, so new apps are covered automatically. One policy per app does not scale (the tenant limit is 240 policies, report-only and off included).
• Exclusions: break-glass group everywhere it blocks or restricts. Anything else goes in CA-Exclude-Temp with an end date. An exclusion without an end date is a permanent hole with a nice name.
• Contingency policies start with ENABLE IN EMERGENCY and stay Off until an outage, like EM01 in the mock.

Source: Plan a Conditional Access deployment

4. Report-only: the dress rehearsal

In report-only mode, the policy is evaluated at every sign-in but not enforced. Nobody gets prompted or blocked; you get a log line of what would have happened. Microsoft's advice: keep each policy in report-only for at least one week before enforcing it.

Where to read the results:

• Sign-in logs > open a sign-in > Report-only tab (and the Conditional Access tab for enforced policies).
• Policy impact (preview) in the policy itself, with at least Security Reader.
• The Conditional Access insights and reporting workbook, which needs a Log Analytics workspace that receives sign-in logs.

What the results mean:

"User action required" on CA03 is good news: the policy finds your pilot users. "Failure" on a service account under CA02 is the email you want to get before go-live, not after.

Source: Conditional Access report-only mode · Conditional Access insights and reporting

5. What If, then a real sign-in

The What If tool (Entra ID > Conditional Access > Policies > What If) simulates a sign-in and lists the policies that apply and the ones that don't, with the first condition that didn't match. It includes policies that are On and in report-only.

It's a weather forecast, not the weather:

• Fill in identity, target resource, device platform and client app. Anything you leave empty is treated as "none", so a policy with a location or risk condition may show the wrong answer.
• App groups like Office 365 or Microsoft Admin Portals don't match. Pick a specific app.
• It doesn't follow service dependencies. Testing Teams won't show the Exchange Online policy that Teams also hits.

So after What If, do a real sign-in with a CA-Test-Users account in a private browser window, then open that sign-in in the logs and read the Report-only tab. Test the exclusions too: an excluded user can still be prompted by a different policy.

Source: The Conditional Access What If tool

6. The rollout order I'd use

Each policy goes through steps 4 and 5, then On for the pilot, then wider groups, one wave at a time.

1. CA01 MFA for admins. Fewest people, highest value.
2. CA02 Block legacy auth. Close the side door before you upgrade the front lock. Microsoft's phased plan also starts here.
3. CA03 MFA for users. Only once pilot users have registered MFA and the helpdesk can reset methods and issue a Temporary Access Pass.
4. CA04 Secure security info registration. Pair it with your MFA registration push.
5. CA05 MFA for Azure management. Targets Windows Azure Service Management API: Azure portal, PowerShell and CLI.

Before each wave, tell users what changes, when, and where to get help.

Sources: Plan a Conditional Access deployment · Block legacy authentication · Securing security info registration · Require MFA for Azure management

7. Plan the rollback before you need it

Write it down before go-live, with a name next to it:

1. Set the policy back to Report-only or Off. Fastest and cleanest fix.
2. Exclude the affected user or group through CA-Exclude-Temp, with an end date. Use sparingly and add them back soon.
3. Sign in with a break-glass account only if admins are locked out. Its sign-in fires the alert, which is the point.
4. Find the cause in the sign-in logs, fix the design, and go through report-only again.

Deleted a policy by mistake? Deleted policies can be restored within the 30-day soft-delete period.

Source: Plan a Conditional Access deployment

Gotchas: what breaks on day one

• Templates exclude only you. Not the break-glass group. Add it.
• Report-only can't see User actions. CA04 targets the Register security information user action, and report-only does not evaluate the User actions scope. Test CA04 with a test account and the policy On for that account only.
• Registering security info now covers more. From July 6, 2026, policies on Register security information also apply when users register Windows Hello for Business and macOS Platform SSO credentials. Expect prompts during device setup.
• Legacy auth hides in non-interactive sign-ins. Before CA02 goes On, filter the sign-in logs by Client app for legacy protocols on both the interactive and the non-interactive tabs. Old scanners, mail clients and scripts live there.
• Service principals ignore user policies. Policies scoped to users don't block service principals. That needs Conditional Access for workload identities. Better: move scripts to managed identities.
• Admin MFA skips some roles. Role-based assignments cover built-in directory roles. Administrative-unit-scoped and custom roles are not enforced.
• Report-only compliance checks can still prompt. A report-only policy that requires a compliant device can prompt macOS, iOS and Android users for a certificate. Exclude those platforms from report-only compliance policies.
• Block + All resources = danger. Microsoft warns that this combination can lock out admins, and you can't exclude key endpoints such as Microsoft Graph.

Rollout checklist

• [ ] Entra ID P1 (P2 for risk) and a Conditional Access Administrator account ready
• [ ] Plan to swap out security defaults with no gap
• [ ] Two cloud-only emergency accounts: permanent Global Administrator, passkey or CBA, alerting, tested
• [ ] Groups created: pilot users, pilot admins, test users, temporary exclusions
• [ ] Policies named CAxx - apps: response - who, break-glass group excluded
• [ ] Every policy in report-only for at least a week, results reviewed
• [ ] What If run, plus a real test sign-in and an exclusion test
• [ ] Legacy auth checked on interactive and non-interactive sign-ins
• [ ] Helpdesk ready for MFA resets and Temporary Access Pass
• [ ] Users told what changes and when
• [ ] Rollback steps written down, with an owner
• [ ] On for the pilot, then one wave at a time

What broke on your day one? I'd like to add it to the gotchas.

Sources

• Plan a Conditional Access deployment
• Conditional Access report-only mode
• Manage emergency access accounts in Microsoft Entra ID
• The Conditional Access What If tool
• Conditional Access templates
• Block legacy authentication with Conditional Access
• Securing security info registration
• Require MFA for administrators
• Require MFA for Azure management
• Conditional Access insights and reporting
• Security defaults in Microsoft Entra ID