30-second answer

PowerShell
Get-MgIdentityConditionalAccessPolicy |
  Select-Object DisplayName, State

Nothing. A policy whose state is enabledForReportingButNotEnforced is evaluated at every sign-in and enforces neither grant controls nor session controls. Microsoft states it in one sentence: Report-only mode evaluates policies but doesn't enforce grant controls or session controls. Users aren't prompted for multifactor authentication or blocked by report-only policies.

The policy appears in the portal's list beside the enforcing ones. Listed is not enforcing, and the list is where most people stop reading.

What this proves

That the policy is being measured. Report-only is a real and recommended instrument: it is how an administrator learns what a policy would do before anybody is locked out by it, and results land in the Conditional Access and Report-only tabs of each sign-in's log detail.

The state has three values and each says something different:

stateWhat happens at a sign-in
enabledThe policy is evaluated and its controls are enforced
disabledThe policy is not evaluated
enabledForReportingButNotEnforcedThe policy is evaluated and nothing is enforced

A report-only evaluation produces its own outcomes, and Report-only: Success is the one worth being careful with. It means the conditions and controls were satisfied. An MFA requirement, for example, met by a claim already present in the token. It does not mean anyone was challenged. When a challenge would have been needed, the result is Report-only: User action required, and Microsoft is explicit about what happened instead: With report-only mode, the user isn't prompted to satisfy the required controls.

What it does not prove

  • That a policy which is not report-only is enforcing something. enabled means the policy is evaluated and its controls apply. A policy scoped to no user, or excluding the users it names, or carrying no control, is enabled and protects exactly as much as a report-only one. This is why the rule below publishes what its pass does not establish rather than leaving a reader to find out.
  • That report-only covers the whole policy. It does not cover one scope. Administrators can evaluate policies in report-only mode except for items included in the "User Actions" scope, so a policy targeting a user action is not being measured either.
  • That report-only is free of user impact. It is not, and this is the paragraph that is easy to miss. Microsoft warns that report-only policies requiring a compliant device can prompt users on macOS, iOS, and Android devices to select a device certificate during policy evaluation, even though device compliance isn't enforced, and that these prompts can repeat until the device is compliant. The recommended mitigation is to exclude those three device platforms from report-only policies that perform compliance checks. A policy enforcing nothing can still be visibly bothering people every day.

PowerShell

PowerShell
# Every policy and its state, which is the list worth having.
Get-MgIdentityConditionalAccessPolicy |
  Select-Object DisplayName, State |
  Sort-Object State, DisplayName

# The ones that are on the screen and enforcing nothing.
Get-MgIdentityConditionalAccessPolicy |
  Where-Object { $_.State -eq 'enabledForReportingButNotEnforced' } |
  Select-Object DisplayName, ModifiedDateTime

Example output

Text
DisplayName                              State
-----------                              -----
Require MFA for administrators           enabledForReportingButNotEnforced
Block legacy authentication              enabled
Require compliant device for Exchange    disabled

Read the first line as this is being measured, not as administrators are required to use multifactor authentication.

Explanation

The confusion is structural rather than careless. The portal's toggle is labelled Enable policy and offers On, Off and Report-only, so report-only reads as a variety of on. In the API the same setting is one property with three values, and the third one names what it does: enabledForReportingButNotEnforced, enabled, for reporting, but not enforced.

The gap this creates is a governance gap and not a technical one. Report-only is the correct place for a new policy to start; Microsoft's own guidance is to create it alongside the enforced policies, watch the sign-in logs, and only then move the Enable policy toggle from Report-only to On. The failure is never the mode. It is the policy that was left in it and then counted.

Production considerations

A policy can change what it enforces without anybody editing it. Message centre post MC1223829, Upcoming Conditional Access change: Improved enforcement for policies with resource exclusions, published 29 January 2026 and last updated 31 July 2026, changed how policies targeting All resources with exclusions behave for sign-ins requesting only OpenID Connect scopes (openid, email, profile and offline_access) or a limited set of directory scopes. Before the change those sign-ins were not subject to the policy. Microsoft's stated effect: users may now receive Conditional Access challenges (such as MFA or device compliance) where previously they were allowed access without enforcement. Enforcement began 15 June 2026, moved from a previously announced 13 May, and rolled out progressively over several weeks.

Microsoft's own preparation advice is that in most cases, no action is required, and the exception is a custom application that requests only those scopes and cannot handle a challenge.

The reason it belongs on this page is what it does to an inventory. The policy object did not change; the sentence a report could truthfully write about it did. Anything that read this tenant before 15 June 2026 and concluded this policy covers everything recorded a fact with an expiry date on it, and nothing in the policy's own fields says so.

What this article does not cover. Whether any given policy grants or blocks anything for a given person is a question about scope, conditions and controls together, and it cannot be answered from the state alone. That needs the sign-in evidence, and the sign-in evidence is a separate read with a separate permission.

CA-STATE-001 reads the state and reports the report-only case. It asserts nothing about which policies an organisation should have: Microsoft publishes no normative conclusion there, and a threshold invented by a tool would make a pass mean nothing. What the rule reports is what Microsoft says the state does.

References

Found something wrong? Suggest a correction. The article source is not public; the engine it cites is.