Microsoft announced Conditional Access policy plans in public preview on November 4, 2026. Plans organize related access requirements using shared conditions and individual rules. Microsoft says customers with Entra ID P1 or P2 can begin using the preview in the Entra admin center. Microsoft announcement.
The operational opportunity is clearer ownership of a security objective. My first pilot would choose one well-understood group of policies and prove its expected access decisions before expanding the migration.
Write the Intent Before Grouping Policies
A plan contains details such as ownership, shared targeting, and scenario-specific rules. Microsoft describes migration and template experiences alongside the existing policy model. Plan structure.
I would begin with a sentence describing the intended outcome: which population should reach which application under which approved conditions. Ask the application and identity owners to agree on that sentence.
Then list the existing policies that contribute to it. A similar name is a useful search clue, but the review needs the actual assignments, exclusions, and controls. Retain the policy identifiers with the proposed mapping.
Understand Inherited Scope
Microsoft Learn explains that shared targeting is inherited, exclusions accumulate, and a rule cannot remove a plan-level exclusion. It also notes that assigning a plan owner does not itself grant editing permissions. Targeting and ownership semantics.
My proposed review would walk through the effective scope of each rule, with special attention to exceptions. Have a reviewer explain the outcome for a user who belongs to multiple relevant groups.
Treat shared-condition edits as changes affecting every inheriting rule. The change record should identify those rules and the scenarios that will be rechecked. This gives the plan's future maintainer a concrete review boundary.
Preserve Existing Enforcement During Evaluation
The migration tool leaves original policies unchanged and creates the new rules in the Off state. Microsoft recommends moving them to Report-only, comparing results, and validating before switching enforcement and retiring the originals. Existing policies and plan rules evaluate independently. Migration workflow.
I would preserve the original configuration and the proposed mapping in the same change record. Name the person who will evaluate the evidence and the person authorized to perform the eventual switch.
Avoid treating creation of a plan as proof that the migration is complete. Completion should depend on agreed access outcomes and an explicit disposition for the original policies.
Build a Decision Matrix
My acceptance matrix would include an expected successful sign-in, an expected blocked attempt, a relevant exception, and a boundary case suggested by the application's real users. Include device and network variations only where they belong to the intended controls.
For every case, record the expected result before reviewing the report-only evidence. Associate the observation with the individual rule and the original policy. Investigate differences while the existing enforcement remains available.
The test population should include people who can recognize an application failure. A sign-in record alone may not explain an interrupted business process, so give the application owner a clear way to report the corresponding experience.
Read the Preview Limitations
The current concept guide calls out a location-condition limitation during preview: user-targeting plans with Location receive one-hour access tokens without the instant IP enforcement check. Preview behavior.
I would record whether that condition affects the chosen pilot. If the workload depends on a particular enforcement behavior, make that dependency explicit and resolve it before deciding that the preview fits.
Keep a review date for the preview decision. A team's evidence should identify the documented behavior it evaluated, so later changes can trigger a focused reassessment instead of relying on an old approval indefinitely.
Practical Cloud Engineer Takeaway
Start with one agreed security objective.
Review each rule's effective targeting and exclusions.
Keep original enforcement during report-only evaluation.
Compare expected decisions with rule-level evidence.
Record preview limitations and the migration exit criteria.
Who Should Care?
Identity administrators, Azure platform security engineers, application owners, and teams managing a large Conditional Access estate.
Bottom Line
Policy plans offer a clearer structure for related access controls. A careful pilot should demonstrate the intended decisions, explain inherited scope, and leave an auditable path from the original policies to the proposed plan.
No tenant configuration, Conditional Access policy, plan, rule, account, or sign-in was changed for this article.
Sources
Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.
Chriz
Beyond Cloud with Chriz
Comments