Report-only mode: test Conditional Access safely

The biggest fear around Conditional Access is entirely legitimate: a rule that is too broad can lock the whole company out in a single second. An administrator turns a policy on one Friday evening, and by Monday morning dozens of employees can no longer reach their email, or the administrator themselves ends up locked out of the tenant. This nightmare scenario is also the number one reason many SMBs never dare to enable Conditional Access, depriving themselves of essential protection.

Yet Microsoft built the exact safety net that answers this fear: report-only mode. It evaluates your policies exactly as in production, with the same conditions and the same grant controls, but never blocks or enforces anything. In other words, it lets you know precisely what would happen if the rule were active, without a single user feeling the slightest change.

That is the whole difference between deploying blind and deploying informed. Within a few days of observation, you know exactly who would be affected, which legitimate flows would be hit, and which adjustments are needed, before the first user is ever concerned. In this guide, you will see how report-only mode works, how to read its results, what its limits are, and how to make it a lasting habit.

How report-only mode works

A report-only policy is fully active in the Entra ID evaluation engine, but its verdict is never applied. At every relevant sign-in, Entra computes what would have happened, decides what it would have granted or blocked, then records that theoretical result in the sign-in logs. The user, meanwhile, keeps working normally, with no extra MFA and no blocking.

• A Conditional Access policy has three states: on, off, and report-only.
• In report-only, grant controls such as MFA or the compliant-device requirement are never actually enforced.
• The theoretical result — 'would have granted', 'would have blocked', 'would have required MFA' — is logged for each evaluated sign-in.
• The user sees absolutely no difference: their sign-in experience stays unchanged.
• You can place several policies in report-only at once to test a whole set of rules before activation.

Why it is an irreplaceable safety net

No theoretical modeling replaces observing real traffic. Report-only mode confronts you with the diversity of situations your users actually encounter: old mail clients, sign-ins from abroad, forgotten service accounts, poorly configured third-party apps. It is that consequence-free confrontation with reality that turns a hypothesis into a certainty and lets you enable the rule with no nasty surprise.

Configuring a policy in report-only

Putting a new rule into report-only takes only a few minutes in the Entra admin center. What matters is not the operation, which is simple, but the discipline: never create a policy directly in the enabled state.

1. 1In the Microsoft Entra admin center, open Protection then Conditional Access, and create a new policy.
2. 2Define the assignments: the targeted users or groups, and the cloud apps in scope.
3. 3Immediately exclude your break-glass emergency account, so you never risk locking yourself out.
4. 4Configure the conditions and grant controls exactly as you want them in production, for example requiring MFA.
5. 5Set the policy's enable toggle to 'Report-only' rather than 'On', then save.
6. 6Let the policy observe sign-ins for a representative period, ideally one to two weeks covering a full work cycle.

Reading the results and deciding

After a few days of observation, the Entra ID sign-in logs reveal the rule's real impact. That is the moment to analyze before switching to enforcement, focusing on the cases that would have been blocked, because those are the ones that would cause an interruption if you enabled the rule as is.

• Open the sign-in logs and use the 'Conditional Access' tab, then filter on the 'Report-only' results.
• Spot the sign-ins marked 'would have blocked' and identify, among them, the perfectly legitimate cases to preserve.
• Adjust exclusions, targeted groups or conditions to spare those legitimate flows before actually turning the rule on.
• Distinguish intended blocks, such as legacy authentication, from accidental blocks, such as an executive traveling abroad.
• Leave the policy under observation long enough to cover a full cycle, including monthly processing and remote work.

Report-only mode turns an anxious question — 'who am I going to block?' — into a factual answer, read calmly in the logs.

A concrete example

An industrial SMB wants to block legacy authentication, the old protocol that bypasses MFA. The administrator creates the policy in report-only, excludes the break-glass account, and watches the logs for two weeks. They discover that most legacy-authentication sign-ins do come from automated attacks to be blocked, but that two of them correspond to a legitimate production management application still configured on an old protocol. Rather than cut that application off on activation day and paralyze the workshop, they schedule its update, confirm the logs are then clean, and switch the policy to 'On'. The intended block is in place, and no business flow was broken.

The limits to keep in mind

Report-only mode is powerful, but it is not magic. A few nuances prevent over-reading the observed results and wrongly believing a rule is perfectly safe to enable.

• Some older clients or certain legacy authentications do not evaluate report-only entirely reliably.
• A real user action, such as completing an MFA prompt, is not actually simulated: the log only shows what would have been requested.
• Observe over a representative period, including activity peaks, month-end processing and remote-work periods.
• A low sign-in volume during the test window can hide rare but critical cases: do not conclude too quickly.

The safe method, every time

Report-only mode should be the systematic first step for every new Conditional Access rule. But it is not enough on its own: it must always be paired with a second essential precaution. Systematically exclude a break-glass emergency account from all your policies before moving to enforcement. This protected, exempt admin account guarantees you will never end up locked out of your own tenant, even if a rule goes wrong. Only enable the policy after confirming the report-only logs reveal no unwanted blocking.

Make report-only a habit

Report-only mode is not just for the first deployment. It is a light discipline to apply throughout the life of your policies. Use it every time you change an existing rule, before every tightening of requirements, and during any organizational change likely to affect sign-ins. This habit avoids costly lockouts and reassures management that your access is under control.

• Switch a policy back to report-only before hardening it, for example before adding a compliant-device requirement.
• Test the impact in report-only before adding a new cloud app to a rule's scope.
• Keep the logged results as a documented record of your security decisions for your audits.
• Periodically re-evaluate your older policies in report-only after headcount growth or the arrival of new tools.

How AuPoint applies this method by default

Remembering to create each rule in report-only, to exclude the break-glass account, to read the right logs and to wait the right observation period takes rigor and experience. AuPoint is the SaaS that makes Microsoft Intune and Conditional Access security and compliance easy, and it applies this method by default. Every policy is offered with an impact preview, deployed in report-only, and reversible in one click. The break-glass account exclusion is handled automatically. You test Conditional Access with full confidence, with no PowerShell and no fear of blocking your teams, while documenting your ISO 27001 and NIS2 compliance.

FAQ

How long should I leave a rule in report-only?

Ideally one to two weeks, to cover a full work cycle including month-end processing, remote-work periods and any activity peaks. The goal is not a precise duration, but the certainty that you have observed every legitimate situation your users actually encounter before enabling the rule.

Where do I actually see what a rule would have done?

In the Entra admin center, open the sign-in logs, select a sign-in, then look at the Conditional Access tab. Report-only policies appear there with their theoretical verdict: granted, blocked or requirement not satisfied. You can also filter the sign-in list directly on the report-only results.

Does report-only mode replace the break-glass account?

No, the two are complementary and both essential. Report-only stops you from enabling a blocking rule by mistake. The break-glass account protects you if, despite everything, an active policy ends up locking you out. Best practice is to always combine both: test in report-only, and keep an emergency exit excluded from every rule.

Report-only mode is what finally makes Conditional Access approachable, even without a dedicated expert: you no longer guess a rule's impact, you measure it. With AuPoint, this method is applied automatically, every policy is previewed, deployed in report-only and reversible in one click. Discover AuPoint and test your Conditional Access rules with complete peace of mind, without ever blocking your teams.