The phased rollout

Microsoft's three-phase deployment, its gate conditions, and the testing step most people skip.
Published by Urbannerd Consulting · Reviewed 2026-07-29

Microsoft's phased Conditional Access rollout

Source: Plan your Microsoft Entra Conditional Access deployment

· doc date 2026-06-01 · retrieved 2026-07-28

Microsoft publishes a three-phase, roughly four-week rollout. This is the schedule the

agent should offer when a user asks for a rollout plan, adjusted for their size and change

capability — Microsoft explicitly says timelines can be adjusted.

Gate conditions — before deploying any policy

Microsoft's own "Important" callout:

1. Verify emergency access accounts are excluded from all policies
2. Test policies with a pilot group before organisation-wide rollout
3. Ensure users have registered required authentication methods
4. Communicate changes to affected users with supporting documentation

Point 3 is the one that causes the most damage when skipped: enforcing MFA on users who

have never registered a method blocks them rather than challenging them.

Phase 1 — Foundation (weeks 1–2)

Establish baseline controls and prepare for MFA enforcement. **Prerequisite: ensure users

can register for MFA before enabling enforcement policies.**

Note the ordering: phishing-resistant MFA for admins is Phase 1, not a late-stage

hardening step. Microsoft puts it before all-user MFA.

Phase 2 — Core authentication (weeks 2–3)

Enforce MFA for all users and guests; protect mobile with app protection policies.

**Key impact: users will be required to use MFA for all sign-ins and use approved apps with

app protection on mobile.** Communication plan must already be executed and support ready.

Phase 3 — Advanced protection (weeks 3–4)

Microsoft's note on PAW: it requires significant infrastructure planning and should only be

implemented after a PAW deployment strategy exists and secure devices are provisioned. The

agent should not casually recommend PAW policies.

Report-only guidance

Enable each policy in report-only mode for at least one week before enforcement.

Review sign-in logs and communicate changes to users before moving to the next phase.

Policies created from Conditional Access policy templates default to report-only.

Evaluating impact

• Use policy impact or report-only mode to confirm settings before and after changes.
• Microsoft's caveat: *a simulated run gives a good idea of how a policy affects sign-in,

but it doesn't replace an actual test run in a properly configured development

environment.* The agent should repeat this rather than overselling What If.

Testing — the step almost everyone skips

Ensure you test the exclusion criteria of a policy.

Microsoft's reasoning: you might exclude a user or group from a policy requiring MFA, but

the combination of other policies can still require MFA for those users. So test that

excluded users actually experience the exclusion. An exclusion in one policy is not an

exemption from the estate.

This directly applies to break-glass validation: excluding the account from Policy A proves

nothing if Policy B still catches it.

Rollback options

Microsoft lists three, in order:

1. Disable the policy. It stops applying at sign-in; re-enable when ready.
2. Exclude a user or group. With an explicit caution: *use exclusions sparingly, only

where the user is trusted. Add users back to the policy or group as soon as possible.*

1. Delete it if disabled and no longer needed.

Soft delete — a genuinely useful recovery fact

If a Conditional Access policy or named location is deleted, it can be restored

within a 30-day soft-delete period.

Restoring requires the Conditional Access Administrator role. The agent should offer

this whenever someone reports an accidentally deleted policy — most administrators do not

know it exists.

Troubleshooting information to collect

Microsoft's list for a user reporting a CA problem:

• User principal name
• User display name
• Operating system name
• Time stamp (approximate is fine)
• Target application
• Client application type (browser or client)
• Correlation ID (unique to the sign-in)

If the user sees a More details link on the error page, they can collect most of this

themselves. Including request ID, time and date is what lets Microsoft support locate the

event if a case is opened.