Report-only rollout & troubleshooting - the disciplined path from Report-only to Enabled

IdentityMicrosoft 365Cloud SecurityMicrosoft Entra IDSecurityIdentity GovernanceSecurity & ComplianceAzure & Entra ID
Written By Tiago Carvalho

Entra ID  ·  Conditional Access  ·  Report-only  ·  Troubleshooting  ·  2026

Conditional Access Baseline Series  ·  Part 4 of 4
Series progress
Part 1
Baseline overview
Part 2
Foundations: break-glass & logging
Part 3
The 8 policies — deep implementation guide
Part 4  · You are here
Report-only rollout & troubleshooting

Part 1 set the baseline. Part 2 put the break-glass, exclusions, and logging in place. Part 3 walked every one of the eight policies end to end. Part 4 is the closing chapter — the disciplined, slightly boring rollout cadence that separates a defensible Conditional Access deployment from a Friday-evening incident call. Report-only is not a toggle; it is a workflow. This article is the playbook: pre-flight, Day 0 deployment, the seven-day review ritual, the enforcement wave, and the steady state — plus a compact KQL triage set, a worked What If scenario, the communication templates that keep users on your side, and the failure patterns that only show up once you move from Report-only to Enabled.

🚦
Report-only is a workflow, not a toggle. A full week of real sign-in data, reviewed daily, is a sensible minimum in most SMB tenants before any policy moves to Enabled. Tenants that skip the review step turn their baseline into their next incident
⚡
Enforcement-only failures are real. Some behaviours — stale token refreshes, Continuous Access Evaluation revocations, session control friction — do not appear in Report-only the same way. Expect a small second wave of triage after each policy flips to Enabled
🎯
Policy ordering matters on enforcement day. Legacy auth block first, identity controls next, device-dependent policies only after Intune compliance is clean, session controls last. Do not flip all eight at once
📣
Communication is part of the rollout, not a side effect. Two user notices, one help-desk heads-up, one post-incident pattern. Users who feel informed open fewer tickets and stay cooperative when something does bite
🛟
Every phase has a documented rollback. If you cannot describe the rollback path for the phase you are in — in one sentence — you are not ready to take the next step

Why Report-only is a workflow, not a toggle

When a Conditional Access policy is set to Report-only, Entra ID evaluates the policy on every relevant sign-in and records whether it would have granted or blocked access — but does not change what actually happens. The sign-in proceeds as if the policy were off. That makes Report-only extraordinarily valuable for validation, because you can stage eight policies at once and watch the real-world impact against real users, real devices, and real apps for a full week before anything bites.

The failure mode is treating Report-only as just a setting. Admins click the toggle, declare the baseline "done", and move on. A week later, enforcement is flipped without ever reading the sign-in log data the Report-only run produced. That is how a policy that looked clean in Report-only turns into a Monday-morning outage — the data was there; nobody looked at it.

The discipline this article describes is simple: Report-only is only useful if you review the output daily for a meaningful window — a full week is a sensible minimum in most SMB tenants — and act on what you find. That turns the eight policies from a clicked-through baseline into a defensible, auditable deployment.

Phase 1 — Pre-flight (Day −7 to Day 0)

Before any policy goes into Report-only, the foundations from Part 2 must be in place. This is not optional. Every rollout that fails hard fails because someone skipped the pre-flight.

Foundations
Two break-glass accounts created, FIDO2 keys enrolled, documented, tested, and excluded from every draft policy via CA-Exclusions-BreakGlass. The four CA-Exclusions-* groups (BreakGlass, ServiceAccounts, Travel, TempAccess) populated and reviewed. Sign-in logs streaming into Log Analytics with at least one alert rule wired up for break-glass use. If any of these is missing, stop and go back to Part 2.
Scope groups
One in-scope group per policy that needs it (e.g. CA-InScope-AllUsers, CA-InScope-Admins, CA-InScope-MobileUsers). Using named groups instead of All users is an SMB design pattern that keeps rollback surgical and staging deliberate — you can pull a specific cohort out of scope without touching the policy object.
Stakeholder map
Identify the named individuals who need to know: one technical sponsor, one help-desk lead, one communication owner. These three people should see the pre-enforcement notice before it goes to users. In smaller tenants it can be the same person wearing three hats — but write the list down anyway.
Baseline snapshot
Before changing any CA policy, take a Graph PowerShell snapshot of the current state (Get-MgIdentityConditionalAccessPolicy piped to a JSON file, timestamped and archived). This is your "before" picture and your worst-case rollback artefact.
Communication D−7
Send the pre-enforcement notice (template in the templates section) seven days before Day 0. This is not the enforcement notice — it is the "you will see stronger sign-in prompts starting next week" heads-up. Users who know why they are being asked for a second factor cooperate; users who don't, escalate.
Rollback plan
At the pre-flight stage the rollback is trivial: "do not deploy". Write down what would make you abort — e.g. break-glass not yet validated, logging pipeline not streaming, stakeholder sign-off missing. If any of those hits on Day 0, slip the rollout rather than fight through it.

Phase 2 — Day 0 deployment (Report-only for all eight policies)

Day 0 is the smallest, most anticlimactic step in the whole rollout. You create the eight policies from Part 3, set every one of them to Report-only, and walk away. Nothing should change for any user. If anything does change, you shipped a bug — find it before you go further.

Deployment order
Create all eight policies, but do not enable them in bulk. Go one at a time: CA001 → confirm it appears in the portal → sanity-check the scope and conditions → set to Report-only → move to CA002. This is usually quick if the policy design and groups are already prepared, and the one-at-a-time discipline catches the typos that would otherwise bite on enforcement day.
Sanity checks
For each policy: the display name matches the naming convention (CA00x — description), CA-Exclusions-BreakGlass is in the exclusion list, the in-scope group is populated, the grant or session control is what Part 3 specified, and the state reads Report-only — not On, not Off.
Live validation
Sign in as a test user (not the break-glass account) and perform a normal authentication. Open Sign-in logs → Interactive sign-ins, find that sign-in, and check the Conditional Access column. You should see the eight policies listed with result Report-only: Success or Report-only: Not applied. If you see Failure on something you did not expect, you have a scope problem — find it before the next sign-in.
Log verification
Within an hour of Day 0 deployment, confirm the new policy evaluations are landing in Log Analytics. Run the Report-only failures KQL query — it can return zero rows legitimately, but the table should respond and the ConditionalAccessPolicies column should contain your new policies' names on any returned row. If the query fails, your diagnostic pipeline is broken and Report-only is blind.
Rollback
If anything unexpected happens on Day 0, switch the offending policy back to Off (not Disabled — Off) and investigate. Do not delete — deletion loses the audit trail. The rollback window at this phase is seconds, because nothing has been enforced yet.
💡
Report-only captures most but not all behaviour. Continuous Access Evaluation (CAE) events, some session control interactions, and certain app-specific flows evaluate slightly differently under enforcement. Report-only is close to reality — it is not reality. Budget for a small second wave of signal after each enforcement step.

Phase 3 — The seven-day review ritual

This is the phase that determines whether Report-only was worth the effort. Every day for seven days, spend 15 minutes on the same three questions: which policies fired, on whom, and does the match look legitimate or like a misconfiguration? The KQL working set in the next section is what powers this review.

Daily cadence
15 minutes per morning. Run the two primary queries (Report-only failures by policy, top users by failure count). Skim the output. Three questions: Is any policy generating unexpected volume? Is any single user hitting the same policy repeatedly? Is the failure reason what I expected when I designed the policy?
Day 3 gate
First major checkpoint. By Day 3 you should have enough data to decide whether to keep on track or adjust scope. Policies with huge false-positive rates (e.g. Policy 7 generating hundreds of hits on legitimate iPhone users still on native Mail) point to a communication gap, not a policy gap. Fix the communication, do not weaken the policy.
Day 7 gate
Enforcement readiness decision. For each policy: is the Report-only signal clean enough to enforce? "Clean enough" means you understand every recurring failure, you have triaged or migrated the top ten offenders, and there are no unexplained spikes. If all eight policies pass this gate, the enforcement wave begins on Day 8. Policies that fail the gate stay in Report-only for another cycle.
What to document
Keep a short running log: one line per policy per day with volume, top failure reason, and any action taken. Seven lines × eight policies = 56 rows in a simple spreadsheet. This becomes the audit trail for the rollout and the "why did we decide this?" record for future-you.
Rollback
During the review ritual, rollback is trivial — nothing is enforced. But the discipline is to act on what you find: adjust the scope group, update CA-Exclusions-Travel for the exec going to Dubai, migrate the five iPhone users off native Mail. Do not carry unresolved failure signal into the enforcement wave.

Phase 4 — Enforcement wave (Day 7 to Day 21)

The enforcement wave is where the baseline actually starts working. The discipline is to flip one policy per day, in a sensible order, with a deliberate pause between each one. Do not batch-flip. Do not flip on a Friday. Do not flip before a holiday. The rollout order below is deliberate — it moves the lowest-friction, highest-value policies first and the highest-friction, most Intune-dependent policies last.

Day 8 — CA001
Block legacy authentication. Lowest friction, highest value. Legacy auth is almost never legitimate in a modern tenant. If the Report-only data shows any genuine legacy auth usage, that is a pre-existing problem (stale app config, old printer, abandoned service account) that needs fixing before enforcement — not a reason to delay the policy.
Day 9 — CA002
MFA for all users. Users who have been seeing the pre-enforcement notice for two weeks are now asked for their second factor. Expect a small help-desk bump on Day 9 and Day 10 — most of it is users who never registered an MFA method. Direct them to the registration portal; do not carve exclusions.
Day 10 — CA003
Phishing-resistant MFA for admins. Only fires on the small admin cohort. Break-glass is excluded. Admins should have FIDO2 keys provisioned during pre-flight — this is the policy that validates that.
Day 11 — CA005
MFA for guests. Lower-volume, lower-risk flip. Guests hit a fresh MFA prompt on their next sign-in; most cooperate because your tenant is not their home tenant and they are used to extra friction.
Day 12 — CA006
Block sign-ins from unexpected countries. Named locations must be correct and CA-Exclusions-Travel populated. Review travel exclusions one more time before flipping — this is the policy most likely to lock out a legitimate user mid-flight.
Day 14 — CA004
Compliant device for admin portals. Deliberately later because it depends on Intune compliance. Do not enforce this until admin workstations are fully enrolled and compliant in the Intune blade. Verify compliance coverage before flipping.
Day 17 — CA007
App protection on mobile. Highest user-visible friction. Users on native Mail clients will need to migrate to Outlook. Only flip when the Report-only signal shows the migration is complete (sub-5% hits on native clients is a reasonable threshold).
Day 21 — CA008
Session controls on unmanaged browsers. Last, because it is a friction policy rather than an access policy and its impact is harder to predict. Some users will complain about re-auth frequency on day 22; that is expected. Tune sign-in frequency rather than turn the policy off.
Rollback
If a flip causes a genuine outage, the rollback is to switch that single policy back to Report-only (not Off) — that preserves the signal while removing the enforcement. Resist per-user exclusions unless the business case is overwhelming. The moment you start carving exclusions under pressure, the baseline starts fracturing.
⚠️
No flips on Fridays, pre-holiday afternoons, or within 48 hours of a change freeze. Enforcement-only failures peak 24–48 hours after the flip, and you need staff available to triage. Early-week flips give you a buffer before the weekend.

Phase 5 — Steady state (Day 30+)

Once all eight policies are Enabled and the second-wave triage has settled, the baseline enters steady state. The discipline does not disappear — it just becomes lighter and periodic.

Weekly (15 min)
Run the two primary KQL queries against the last seven days. Look for volume spikes, new failure reasons, or any break-glass sign-in activity (that last one should always generate an alert as well). Weekly review catches drift before it becomes a problem.
Monthly (30 min)
Review the exclusion groups. CA-Exclusions-Travel should be nearly empty; CA-Exclusions-TempAccess should have zero entries older than their intended expiry. Service accounts in CA-Exclusions-ServiceAccounts should all still be in use. Clean up stale entries.
Quarterly (2 hours)
Re-run the break-glass test (can you actually log in with the FIDO2 key?), re-validate the Graph PowerShell snapshot, and compare the current policy set against the Part 3 baseline. Microsoft evolves Conditional Access surface features — quarterly review is where you catch new capabilities and retired settings.
On incident
When something breaks, follow the post-incident pattern below. Capture, classify, fix, document. The goal is not zero incidents — the goal is zero incidents that repeat.

What If — a worked scenario

The What If tool in Entra (Protection → Conditional Access → What If) simulates a sign-in and shows you exactly which policies would apply, which would grant, and which would block. It is the most under-used tool in the Conditional Access blade. Use it whenever you are about to make a change that affects a specific user or scenario — especially named exclusions and travel approvals.

Scenario: travelling CFO

On Day 12 of the rollout (the day CA006 goes to Enabled), the CFO flies to Dubai for three days to meet an investor. Block unexpected countries does not allow UAE sign-ins. You need to predict whether the sign-in will fail, and decide whether to use CA-Exclusions-Travel.

Input
User: cfo@contoso.com. Cloud app: Office 365. IP address: a known UAE IP range (ping your travelling exec and ask, or pick a representative). Device platform: iOS. Client app: Mobile apps and desktop clients. Leave sign-in risk and user risk at None unless you have a reason to model otherwise.
Output
What If returns a list of policies that would apply and policies that would not apply. You should see CA006 — Block unexpected countries in the first list with result Block. That confirms your suspicion — the real sign-in would fail.
Decision
Add the CFO to CA-Exclusions-Travel with a three-day diary reminder to remove them. Re-run What If with the same inputs — CA006 should now appear in policies that would not apply (excluded). Document the decision: user, trip dates, approver, removal date. This is what your future auditor will look for.
Limitations
What If does not model device compliance state perfectly, and it does not simulate the exact session control behaviour of a real browser. Treat it as a high-confidence prediction tool, not a perfect simulator. When in doubt, ask the user to sign in and check the real sign-in log entry afterwards.

KQL triage set — the compact working set

Six queries cover 90% of the triage you will do across Phase 3 and steady state. All of them run against the SigninLogs table in Log Analytics (the workspace you wired up in Part 2). Tune time ranges to your cadence — daily during rollout, weekly in steady state.

1 · Report-only failures grouped by policy

The headline query during Phase 3. Shows which policies are firing and at what volume. Spikes indicate a communication gap or a misconfiguration.

Report-only failures — last 24h KQL 
SigninLogs
| where TimeGenerated > ago(24h)
| mv-expand ConditionalAccessPolicies
| extend PolicyName   = tostring(ConditionalAccessPolicies.displayName),
         PolicyResult = tostring(ConditionalAccessPolicies.result)
| where PolicyResult == "reportOnlyFailure"
| summarize Attempts = count(), Users = dcount(UserPrincipalName) by PolicyName
| order by Attempts desc

2 · Enforced failures grouped by policy and result

The headline query during Phase 4 enforcement wave and steady state. Real users are now being blocked — you need to know who, why, and how often.

Enforced failures — last 24h KQL 
SigninLogs
| where TimeGenerated > ago(24h)
| where ConditionalAccessStatus == "failure"
| mv-expand ConditionalAccessPolicies
| extend PolicyName   = tostring(ConditionalAccessPolicies.displayName),
         PolicyResult = tostring(ConditionalAccessPolicies.result)
| where PolicyResult == "failure"
| summarize Attempts = count(), Users = dcount(UserPrincipalName)
         by PolicyName, ResultType, ResultDescription
| order by Attempts desc

3 · Top users by Report-only failure count

Surface the ten users hitting Report-only failures the most. If the same user tops the list three days running, that is a migration or scope problem you need to act on before enforcement.

Top-10 users — last 7d KQL 
SigninLogs
| where TimeGenerated > ago(7d)
| mv-expand ConditionalAccessPolicies
| extend PolicyName   = tostring(ConditionalAccessPolicies.displayName),
         PolicyResult = tostring(ConditionalAccessPolicies.result)
| where PolicyResult == "reportOnlyFailure"
| summarize Failures = count(), Policies = make_set(PolicyName)
         by UserPrincipalName
| top 10 by Failures desc

4 · Legacy auth attempts (Policy 1 signal)

Before flipping CA001 to Enabled, confirm the legacy auth pattern. Any attempts here will be blocked the moment you enforce — know what you are about to block.

Legacy auth sign-ins — last 7d KQL 
SigninLogs
| where TimeGenerated > ago(7d)
| where ClientAppUsed in ("Exchange ActiveSync", "Other clients",
                       "IMAP", "POP", "SMTP",
                       "Authenticated SMTP")
| summarize Attempts = count(), Users = dcount(UserPrincipalName)
         by ClientAppUsed, AppDisplayName
| order by Attempts desc

5 · Mobile client-app breakdown (Policy 7 signal)

Before flipping CA007, you want to know how many iPhone and Android users are still on native Mail or non-approved clients. The output drives the migration communication.

Mobile clients — last 7d KQL 
SigninLogs
| where TimeGenerated > ago(7d)
| where DeviceDetail.operatingSystem in ("iOS", "Android")
| summarize Signins = count(), Users = dcount(UserPrincipalName)
         by tostring(DeviceDetail.operatingSystem), ClientAppUsed, AppDisplayName
| order by Signins desc

6 · Conditional Access policy change audit

Who changed what, when. The post-incident and steady-state accountability query. Runs against AuditLogs, not SigninLogs.

CA policy changes — last 30d KQL 
AuditLogs
| where TimeGenerated > ago(30d)
| where Category == "Policy"
| where OperationName has "conditional access policy"
| project TimeGenerated, OperationName,
           Actor    = tostring(InitiatedBy.user.userPrincipalName),
           Target   = tostring(TargetResources[0].displayName),
           Result   = tostring(Result)
| order by TimeGenerated desc

Troubleshooting catalogue — enforcement-only failures

These are the failure patterns that Report-only typically under-represents. They surface in the 24–72 hours after a policy flips to Enabled. None of them are show-stoppers; all of them benefit from being recognised quickly rather than diagnosed from scratch.

Pattern 1 · Token cache lag
"It worked yesterday, stopped working this morning, no changes made"

Cause: a policy you enforced late yesterday has bitten only now because the user's refresh token was still valid. Tokens cache for up to an hour (access) or much longer (refresh) depending on configuration, so enforcement can take time to propagate. Fix: ask the user to sign out fully (clear browser session, sign out of mobile apps) and sign back in. If the pattern is widespread, consider revoking refresh tokens for the affected cohort via Revoke-MgUserSignInSession.

Pattern 2 · Device compliance race
Admin laptop shows compliant in Intune but CA004 says "device not known"

Cause: Entra ID has not yet picked up the Intune compliance state for that device. There is a short propagation window between Intune marking a device compliant and Entra seeing it. Fix: confirm compliance in Intune → Devices → All devices → <device> → Device compliance, then wait 15–60 minutes and retry. Persistent failures usually mean the device is joined but not hybrid-joined correctly, or the Intune compliance policy has an unmet requirement the admin cannot see.

Pattern 3 · Guest user home-tenant MFA mismatch
Guest claims they did MFA but your tenant prompts again

Cause: cross-tenant access settings determine whether your tenant accepts the guest's home-tenant MFA or forces a re-prompt. The default is re-prompt, which is secure but user-friction-heavy. Fix: review External Identities → Cross-tenant access settings. If you want to trust a specific partner tenant's MFA, configure inbound trust deliberately per partner — do not flip it on globally. Keep a record of which partners you trust and why.

Pattern 4 · Named location evaluation delay
Office IP range added to named location, travellers still blocked

Cause: changes to named locations do not always take effect on existing sessions immediately. Active sessions continue to evaluate against the old definition until they refresh. Fix: for a pressing change (e.g. adding a new office IP), expect up to an hour of propagation. For permanent network changes, update the named location ahead of the migration window — do not do it the morning of.

Pattern 5 · Service principal caught in user-scoped policy
Scheduled workflow breaks after CA002 enforcement

Cause: a workload identity (service principal) was signing in with user credentials and got caught in All users scope. Under Report-only it logged as a failure but continued; under enforcement it is now blocked. Fix: move the workflow off user credentials onto a proper service principal or managed identity. As an interim measure, add the specific account to CA-Exclusions-ServiceAccounts — but document the migration plan, do not let the exclusion become permanent.

Pattern 6 · Authentication strength mismatch
Admin with FIDO2 key gets "method not satisfied"

Cause: the authentication strength assigned to CA003 requires a specific phishing-resistant method, but the admin is attempting to authenticate with a method not in the allow-list (e.g. Authenticator push when the strength requires FIDO2). Fix: verify the authentication strength definition in Protection → Authentication methods → Authentication strengths. Confirm the admin's registered methods include at least one that matches. This is usually a gap in admin onboarding rather than a policy misconfiguration.

Pattern 7 · Session control friction on legitimate users
Users complaining about hourly re-authentication

Cause: CA008's device filter is matching devices it shouldn't — usually because the trustType or isCompliant attribute is written in a way that does not recognise your real managed devices. Fix: run the mobile/browser signal query (KQL #5, adapted) grouped by DeviceDetail.isCompliant and DeviceDetail.trustType. Compare the values you see against the filter expression. Adjust the expression; validate with What If; re-test. Never relax sign-in frequency just because users complain — that is the wrong lever.

Communication templates

Three short templates cover the rollout comms needs. Each is deliberately practical — not marketing, not corporate — and assumes your users are adults who can handle a direct explanation of what is changing and why.

Template 1 · Pre-enforcement notice Day −7

Subject: Stronger sign-in security starting <date>

Hi team — starting <date>, you will see stronger sign-in prompts when accessing Microsoft 365. Most of the time this means a second step (your Authenticator app or a security key) when you sign in on a new device or after a period of inactivity.

What you need to do before <date>: confirm your Authenticator app is working, and check your registered methods at https://mysignins.microsoft.com/security-info. If you do not have the Authenticator set up, follow the guide at <internal link>.

Why we are doing this: the most common cause of account compromise is stolen passwords. A second factor stops that attack cold.

If anything breaks, contact the help desk on <channel>.

Template 2 · D-Day announcement Day of enforcement

Subject: Sign-in security is now active

The stronger sign-in prompts mentioned last week are now in place. You should see a multi-factor prompt on your next sign-in from any new device.

Expected today: a short help-desk spike as people re-register methods, then back to normal. If you cannot sign in, call the help desk directly — do not ask a colleague for their password. We will never ask you for your MFA code over email, chat, or phone.

Mobile users on the iOS native Mail or Android Gmail apps: you will need to switch to Outlook for work email. Guide: <internal link>.

Template 3 · Rollback / incident notice On rollback

Subject: Sign-in prompt change reverted — action not required

The sign-in change applied at <time> today has been reverted while we investigate an issue affecting <affected cohort>. No action is required from you — sign-in behaviour has returned to what you saw yesterday.

We will communicate again before the next attempt. If you experienced issues today and are still blocked, contact the help desk on <channel>.

Post-incident review pattern

When a policy bites harder than expected and causes a real incident, the goal is not punishment — it is learning. A consistent, short post-incident pattern turns one-off pain into lasting improvement.

Capture (T+0)
At incident time: the policy name, the affected users, the failure reason from the sign-in log, the time of the enforcement flip, and the rollback action taken. One paragraph. Do not wait for the incident to be "over" — write it while the facts are fresh.
Classify (T+1d)
Within 24 hours, classify the incident: was it a policy design problem (the policy was wrong), a scope problem (the user should not have been in scope), a foundations problem (something in Part 2 was not in place), or a propagation problem (enforcement-only behaviour you did not anticipate)? Classification drives the fix.
Fix (T+3d)
Apply the fix at the right layer. A scope problem is fixed in the in-scope group; a design problem is fixed in the policy; a foundations problem goes back to Part 2; a propagation problem goes into the troubleshooting catalogue. Re-enforce only after the fix is validated in Report-only for at least 48 hours.
Document (T+7d)
One-page summary added to the rollout log. What happened, what we did, what we changed, what we will do differently next time. If the pattern is new, consider whether it belongs in this article's troubleshooting catalogue — or in your internal playbook for next time.

Completion checklist — the series is done

This is the gate for the whole four-part series. If every box below is ticked, your Conditional Access baseline is deployed, validated, and defensible.

  • Part 2 foundations confirmed in place Break-glass accounts tested this quarter, all four CA-Exclusions-* groups populated and current, Log Analytics streaming with at least one break-glass alert rule.
  • All eight baseline policies Enabled CA001–CA008 in the state you intended, matching the Part 3 design. No unintended Off or Report-only remnants.
  • Seven-day review ritual executed Daily review log captured for the seven days preceding each enforcement flip. Top failures triaged; top-10 users migrated or excluded with documentation.
  • KQL queries saved and scheduled At minimum, the Report-only failures and enforced failures queries pinned in Log Analytics, with a weekly review cadence and an owner.
  • Graph PowerShell snapshot archived Pre-rollout and post-rollout JSON snapshots of the full CA policy set, stored somewhere durable. Your diff-friendly baseline-as-code.
  • Communication log complete Pre-enforcement notice, D-Day announcement, and any rollback notices sent and archived. Help-desk brief documented.
  • Incident post-mortems captured If anything broke, a one-page review exists. If nothing broke, a one-line "no incidents" note with the rollout owner's name is equally valid.
  • Quarterly review scheduled Calendar entry for 90 days from steady-state: break-glass re-test, exclusion hygiene, policy drift check. Conditional Access is not a set-and-forget control.
✅
Series complete. You have an opinionated, documented, auditable Conditional Access baseline — deployed the disciplined way, not the fast way. That is the version future-you will thank present-you for. The next natural step for most tenants is closing the privileged-access gap: Entra ID governance, PIM for admin role activation, and access reviews for the groups your new CA policies now depend on.
You finished the series  ·  What comes next
The PIM baseline for SMB Microsoft 365 tenants
Conditional Access locks down how people sign in. Privileged Identity Management locks down what they can do once they are signed in. The natural next chapter: which roles to put under PIM, activation windows, approval workflows, and the same Report-only-style rollout discipline applied to privileged access — upcoming on the blog.
More on Entra ID →
Need a hand
Want someone to run this rollout with you end to end?
Deploying the eight baseline policies is one thing; running the seven-day review ritual, the phased enforcement wave, and the post-incident reviews is another. If you want an Entra ID hardening review that covers the full playbook — including the break-glass validation and the steady-state cadence — get in touch.
Sources
References used
Tiago Carvalho
Next

The eight Conditional Access policies — a deep implementation guide