Every Conditional Access policy you turn on changes how real people sign in. Conditional Access report-only mode lets you see exactly what a policy would do to those sign-ins before it does it. Used properly, it is the difference between a quiet rollout and a morning of helpdesk calls from people who can’t open Outlook.
This guide covers what report-only mode actually evaluates, where to read the results, the limitations that catch people out, and a simple process for moving a policy from report-only to on.
What report-only mode does and doesn’t do
When a policy is set to Report-only, Microsoft Entra ID evaluates it on every sign-in in scope and writes the result to the sign-in log. It doesn’t enforce the grant or session controls. Users aren’t prompted for MFA, aren’t blocked and aren’t asked to accept terms of use because of a report-only policy.
That means you can build a policy exactly as you intend to enforce it, including Block controls, and watch the outcome for a week or two with no user impact. It requires the same license as Conditional Access itself, Microsoft Entra ID P1, which comes with Microsoft 365 Business Premium, E3 and E5.
Each sign-in gets one of four report-only results for each policy:
Result
What it means
What to do
Report-only: Success
Conditions matched and the sign-in already met the controls (for example, MFA was already in the token)
Nothing. This user would not notice the policy.
Report-only: Failure
Conditions matched but the sign-in would fail, such as a Block or a non-compliant device
Investigate every one before enforcing.
Report-only: User action required
The user would have been prompted, for example for MFA
Confirm the user has a method registered.
Report-only: Not applied
Conditions didn’t match, for example the user is excluded
Check that exclusions are intentional.
Where to read the results
You have three places to look, and each answers a different question.
Policy impact view
Open the policy in Entra ID > Conditional Access > Policies and look at the policy impact view. It shows a summary of how the policy would have affected interactive sign-ins over the past 24 hours, 7 days or month, with a sample of events. It needs at least the Security Reader role and no extra infrastructure, so it is the quickest first check.
Individual sign-in logs
In Entra ID > Monitoring and health > Sign-in logs, open any sign-in and go to the Report-only tab. You’ll see every report-only policy and its result for that specific sign-in. This is where you go when a specific person or app shows up as a failure and you need to understand why.
Insights and reporting workbook
For aggregate views across many users and apps, use Entra ID > Conditional Access > Insights and reporting. You can choose several report-only policies together to see their combined effect, narrow it to one user or app, and look back up to 90 days. It requires your sign-in logs to be sent to a Log Analytics workspace, which has an Azure cost. In smaller tenants I set that up anyway, because the same logs are useful for alerting on emergency access accounts.
Limitations that catch people out
User actions aren’t supported. Policies scoped to user actions, such as Register security information, can’t be evaluated in report-only mode. Test those with a pilot group instead.
Device compliance prompts on mobile and Mac. A report-only policy that requires a compliant device can still cause macOS, iOS and Android users to see a certificate prompt during evaluation. Microsoft recommends excluding those platforms from report-only device compliance policies.
GPS-based locations still prompt. A report-only policy using GPS named locations asks users to share location from Microsoft Authenticator.
Report-only isn’t the final answer. A sign-in that shows Success for your new policy can still be blocked by a different enforced policy. Look at the whole Conditional Access tab, not just the one policy.
Quiet users don’t show up. If someone hasn’t signed in during the test window (on leave, part time, a seasonal account), you have no data for them. Check those accounts by hand.
A repeatable process from report-only to on
Define the outcome. Write one sentence saying what the policy should do and to whom. If you can’t, the policy isn’t ready.
Exclude emergency access accounts and create a dedicated exclusion group for the policy.
Create the policy in report-only mode. Build it exactly as you plan to enforce it.
Wait a full business cycle. One week minimum; two weeks for anything involving device compliance or locations. Make sure month-end or payroll processes are inside the window if they use unusual apps.
Review every Failure and User action required result. Group them by app and by user. Typical findings: an old scanner using basic authentication, a shared mailbox someone logs into directly, an unenrolled laptop.
Fix causes, not symptoms. Enroll the laptop, move the scanner to a modern relay, register MFA for the user. Use the exclusion group only for things you genuinely can’t fix yet, with an end date.
Tell users what will change. Even a policy that should be invisible deserves a heads-up for the helpdesk.
Switch to On during business hours, early in the week, with someone watching sign-in logs for the first few hours.
Keep a report-only copy for changes. Before you modify an enforced policy later, create a report-only copy with the new settings and compare the two before you update the live one.
This is the same process we use in our Microsoft 365 managed service. If you are rolling out MFA for the first time, our MFA enablement engagement runs the report-only phase and user registration together.
Using report-only for risk-based policies
Risk-based policies (sign-in risk and user risk) need Microsoft Entra ID P2. They can be tested in report-only like any other policy, but it can take weeks before enough risky sign-ins happen to give you useful data. Microsoft provides an Impact analysis of risk-based access policies workbook, found under ID Protection > Dashboard, that estimates impact from existing sign-in logs without waiting. It needs sign-in logs in Log Analytics.
Also note that legacy risk policies configured inside ID Protection retired on October 1, 2026. If you are rebuilding them in Conditional Access, report-only mode is the right first step.
In a well-run tenant, the Conditional Access policy list has a small number of enforced policies, maybe one or two in report-only at any time (the next change being tested), and nothing that has sat in report-only for six months. A policy that has been report-only for that long is either not needed or someone is afraid to turn it on. Either way, make a decision.
Not sure what is sitting in your tenant? The free tenant checker gives you a quick external view, and a Microsoft 365 security assessment reviews every policy, its state and its exclusions.
Frequently asked questions
Do users see anything when a policy is in report-only mode?
Generally no. The exceptions are device compliance checks on macOS, iOS and Android, which can trigger a certificate prompt, and GPS-based location policies, which ask users to share their location. Exclude those platforms or test with a pilot group.
How long should a policy stay in report-only?
At least one full week, ideally two. Long enough to capture travel, part-time staff and periodic processes, but not so long it becomes permanent. Put a decision date on the change ticket.
Do I need Log Analytics to use report-only mode?
No. Report-only results appear in the sign-in logs and the policy impact view without it. Log Analytics is needed only for the Insights and reporting workbook and for longer retention and alerting.
Want help testing Conditional Access changes safely? Book a free Microsoft 365 security assessment and we’ll review your report-only results, find the sign-ins that would break and give you a clear enforcement plan.
Every Conditional Access policy you turn on changes how real people sign in. Conditional Access report-only mode lets you see exactly what a policy would do to those sign-ins before it does it. Used properly, it is the difference between a quiet rollout and a morning of helpdesk calls from people who can’t open Outlook.
This guide covers what report-only mode actually evaluates, where to read the results, the limitations that catch people out, and a simple process for moving a policy from report-only to on.
What report-only mode does and doesn’t do
When a policy is set to Report-only, Microsoft Entra ID evaluates it on every sign-in in scope and writes the result to the sign-in log. It doesn’t enforce the grant or session controls. Users aren’t prompted for MFA, aren’t blocked and aren’t asked to accept terms of use because of a report-only policy.
That means you can build a policy exactly as you intend to enforce it, including Block controls, and watch the outcome for a week or two with no user impact. It requires the same license as Conditional Access itself, Microsoft Entra ID P1, which comes with Microsoft 365 Business Premium, E3 and E5.
Each sign-in gets one of four report-only results for each policy:
Where to read the results
You have three places to look, and each answers a different question.
Policy impact view
Open the policy in
Entra ID > Conditional Access > Policiesand look at the policy impact view. It shows a summary of how the policy would have affected interactive sign-ins over the past 24 hours, 7 days or month, with a sample of events. It needs at least the Security Reader role and no extra infrastructure, so it is the quickest first check.Individual sign-in logs
In
Entra ID > Monitoring and health > Sign-in logs, open any sign-in and go to the Report-only tab. You’ll see every report-only policy and its result for that specific sign-in. This is where you go when a specific person or app shows up as a failure and you need to understand why.Insights and reporting workbook
For aggregate views across many users and apps, use
Entra ID > Conditional Access > Insights and reporting. You can choose several report-only policies together to see their combined effect, narrow it to one user or app, and look back up to 90 days. It requires your sign-in logs to be sent to a Log Analytics workspace, which has an Azure cost. In smaller tenants I set that up anyway, because the same logs are useful for alerting on emergency access accounts.Limitations that catch people out
A repeatable process from report-only to on
This is the same process we use in our Microsoft 365 managed service. If you are rolling out MFA for the first time, our MFA enablement engagement runs the report-only phase and user registration together.
Using report-only for risk-based policies
Risk-based policies (sign-in risk and user risk) need Microsoft Entra ID P2. They can be tested in report-only like any other policy, but it can take weeks before enough risky sign-ins happen to give you useful data. Microsoft provides an Impact analysis of risk-based access policies workbook, found under
ID Protection > Dashboard, that estimates impact from existing sign-in logs without waiting. It needs sign-in logs in Log Analytics.Also note that legacy risk policies configured inside ID Protection retired on October 1, 2026. If you are rebuilding them in Conditional Access, report-only mode is the right first step.
For the full reference on result types and tools, see Microsoft’s article on analyzing Conditional Access policy impact.
What good looks like after rollout
In a well-run tenant, the Conditional Access policy list has a small number of enforced policies, maybe one or two in report-only at any time (the next change being tested), and nothing that has sat in report-only for six months. A policy that has been report-only for that long is either not needed or someone is afraid to turn it on. Either way, make a decision.
Not sure what is sitting in your tenant? The free tenant checker gives you a quick external view, and a Microsoft 365 security assessment reviews every policy, its state and its exclusions.
Frequently asked questions
Do users see anything when a policy is in report-only mode?
Generally no. The exceptions are device compliance checks on macOS, iOS and Android, which can trigger a certificate prompt, and GPS-based location policies, which ask users to share their location. Exclude those platforms or test with a pilot group.
How long should a policy stay in report-only?
At least one full week, ideally two. Long enough to capture travel, part-time staff and periodic processes, but not so long it becomes permanent. Put a decision date on the change ticket.
Do I need Log Analytics to use report-only mode?
No. Report-only results appear in the sign-in logs and the policy impact view without it. Log Analytics is needed only for the Insights and reporting workbook and for longer retention and alerting.
Want help testing Conditional Access changes safely? Book a free Microsoft 365 security assessment and we’ll review your report-only results, find the sign-ins that would break and give you a clear enforcement plan.