Conditional Access report-only mode: how to go from report-only to enforce safely
TL;DR
- Most Conditional Access (CA) lockouts come from the rollout, not from the policy. The usual pattern is All users, set straight to On, with no pilot and no break-glass account.
- Safe order: name the policy, scope it to a pilot group, turn it on in report-only, check it with What If, read Insights and reporting for several business days, then enforce for the pilot and expand in waves.
- Exclude at least two break-glass accounts before anything is enforced.
- Free step-by-step checklist: Conditional Access Rollout Checklist (Report-only → Enforce).
Most CA disasters aren't "bad policies." They're enforce-first policies: All users + Require MFA or Require compliant device, switched On overnight with no pilot and no break-glass account.
Here's a safer pattern that still gets you to Enforce.
What is Conditional Access report-only mode?
Report-only is a policy state (Enable policy = Report-only). Entra ID evaluates the policy on every sign-in and records what it would have done (success, failure, user action required), but it doesn't enforce the grant or block. You get real sign-in data with zero user impact for nearly all policy types.
Use it for every net-new control and every scope or grant change, not just the "scary" ones.
How should you name Conditional Access policies?
Use a boring, searchable name that reads like a change ticket:
CA - Require MFA - Cloud apps - Pilot - ReportOnly
Include who, what, scope, and phase (ReportOnly / Enforce). Future you (and 3am you) will thank you.
Who should be in a Conditional Access pilot group?
Create an Entra security group like CA-Pilot-Wave0 with IT plus a few volunteers. Include that group in the policy. Exclude your break-glass accounts from day one.
Don't start with All users on a Block or hard Require compliant device policy.
How do you move a policy from report-only to enforce?
For any net-new control:
- Set Enable policy = Report-only.
- Run What If for a pilot user and a break-glass user. The policy should apply to the first and not to the second.
- Watch Insights and reporting (and the Report-only tab on individual sign-ins) for several business days. Make sure that includes a Monday.
- Fix false failures: MFA registration gaps, compliance flapping, legacy clients.
- Only then set Enable policy = On for the pilot.
If Insights shows a pile of "would block" results for normal, expected workflows, you're not ready.
Why do you need break-glass accounts before you enforce?
Keep at least two cloud-only break-glass (emergency access) accounts. Exclude them from CA, alert on their sign-ins, and store their credentials through a sealed process. If you enforce without them, your rollback plan is "pray the other Global Admin is online."
How do you roll Conditional Access out to everyone?
Expand in waves: pilot → IT → one department → everyone else → guests last. Add wave groups to the include list, and prefer nested groups over editing All users every week. If a wave goes badly, remove that wave's group instead of turning off the whole policy.
Common Conditional Access failures after enforce
| Symptom | Likely cause | First check |
|---|---|---|
| MFA prompt loops | Registration incomplete / Authenticator issues | Sign-in logs + MFA registration |
| "Device not compliant" | Intune compliance not green yet | Device compliance + sync (BitLocker still encrypting?) |
| Outlook / IMAP fails | Legacy auth blocked | Modern auth client or a time-boxed exclusion |
| Admin locked out | No CA exclusion for break-glass | Break-glass + emergency access plan |
FAQ
Does report-only mode affect users?
For nearly all policies, no. It logs the result without enforcing it. One caveat from Microsoft's documentation: report-only policies that require a compliant device can still prompt some macOS, iOS, Android, and Linux users to pick a device certificate. Pilot those first.
How long should a policy stay in report-only?
There's no official number. A practical minimum is 3–5 business days, including a Monday (and month-end if finance apps are in scope). Write your exit bar down before you start.
What license does Conditional Access need?
Entra ID P1, which is included in Microsoft 365 Business Premium, E3, and E5. Risk-based conditions need P2.
Why is the Insights and reporting workbook empty?
It reads from Log Analytics. If your sign-in logs aren't sent to a Log Analytics workspace, the workbook has nothing to show. Check individual sign-ins → Report-only tab in the meantime.
Is the What If tool enough on its own?
No. What If checks your assignments for one simulated sign-in. Report-only shows how real sign-ins behave. Use both.
Related reading
- BitLocker still encrypting? Why Intune marks devices noncompliant (and how grace periods help): fix compliance before you put a require compliant device policy in front of it.
- Weekly read-only Intune device + compliance CSV snapshots with Graph: evidence for the go/no-go call.
- Conditional Access baseline for Entra ID: naming, pilot groups, report-only, Insights, break-glass: the longer baseline this rollout sits on.
- Company Portal can't connect / device not syncing: a 10-minute triage order
Free checklist: report-only → enforce
Every step above is in a free, copy-into-your-ticket checklist: policy record, What If checks, report-only exit bar, go/no-go, wave table, and rollback triggers. It's free, and you don't need to buy anything to use it.
👉 Get the free Conditional Access Rollout Checklist
If you'd rather start from written-out playbooks, the Entra ID Conditional Access Starter Pack expands it into five modules (foundation and naming, report-only → enforce, a starter policy library, break-glass and exclusions, and a troubleshooting runbook). It also includes three read-only Graph PowerShell exports. The scripts only read and export; they never create or change policies: Entra ID Conditional Access Starter Pack.
Admin Pack Studio. Not affiliated with Microsoft. Operational guidance for admins authorized to manage their tenant. Test in a pilot first.
Top comments (0)