Microsoft Entra Conditional Access policy plans

Key insights

• Policy plans can be created manually, from a template, or by migrating existing Conditional Access policies.
• During migration, each selected policy becomes its own rule and shared settings move to the plan.
• Migrated rules are created turned off to avoid disrupting access.
• The demonstrated workflow moves rules to report-only so admins can inspect impact in sign-in logs.
• A plan can hold shared identities, resources, user actions, authentication context, and conditions.

Microsoft Entra Conditional Access policy plans group related rules under one plan, with shared settings managed at the plan level and individual policies represented as rules. This preview capability is aimed at IT administrators who manage multiple Conditional Access policies and want to organize or migrate them without immediately changing enforcement. Peter Rising [MVP] demonstrates creating a plan and migrating existing policies in a YouTube video.

What's new

Conditional Access policy plans provide another way to organize access controls. Rather than treating every policy as a separate item, administrators can place related rules in a plan and define shared settings for those rules. In the demonstrated migration, the source policies retain distinct controls while becoming rules within one plan.

The example starts with policies to block legacy authentication, require a compliant device, and require multifactor authentication (MFA). The migration combines the three into one plan. Each selected policy becomes a separate rule, while conditions shared by all selected policies are moved into the plan's shared conditions.

Plans can also be created from scratch or from a template. The template selection shown includes categories such as Secure Foundation and Zero Trust. A plan created manually can include shared identities, then rules with their own names, resources, and grant controls. The demonstration shows a rule configured to require MFA.

There is an important difference between creating a plan and adding rules to one: the demonstrated interface requires the administrator to create the plan first, then return to it to add additional rules. The plan overview provides access to the plan settings and its rules.

Who it is for and what you need

The feature is relevant to administrators who maintain Conditional Access in the Microsoft Entra admin center, particularly where related policies apply to overlapping users or groups. The example uses a security group for included users and excludes a break-glass account. A break-glass account is an emergency access account, and the demo explicitly includes it as an exclusion from the plan scope.

The transcript identifies policy plans as a preview feature. It does not state which licenses, subscriptions, regions, or tenant configurations are required, nor does it establish a general rollout schedule. Administrators should treat behavior as subject to change while the feature remains in preview.

The walkthrough takes place in the Microsoft Entra admin center under Conditional Access. It uses an environment with existing policies to migrate; for a new plan, administrators can instead choose a template or start from scratch. No specific prerequisite license or role is named in the available material.

How it works

To migrate policies, open Conditional Access and select Policies. The migration entry point is labeled “Preview: Migrate to Conditional Access policy plans.” The interface displays policies it found and lets the administrator choose which policies to combine. The video reports that it found 14 of 14 policies in its demonstration environment; that is an example, not a tenant-wide guarantee.

1. Choose the policies to migrate and provide a name for the new plan.
2. Review the shared settings the interface identifies. In the example, identities include two users and exclude one user.
3. Create the plan. Each selected policy appears as a separate rule, and shared conditions are moved to the plan.
4. Open the plan and edit each rule. The demonstrated workflow changes the rules to report-only and saves them.
5. Review sign-in logs to assess the impact, then decide whether and when to enable the rules and disable the old policies.

The migration screen states that rules are created in the off state to avoid disruptions. It recommends moving them to report-only to validate impact before turning them on. Report-only lets administrators review how rules would apply without enforcing their access requirements, as described in the walkthrough.

At the plan level, the demonstrated edit options include shared identities, resources, user actions, authentication context, and shared conditions. Examples of conditions mentioned include client app types, user risk, sign-in risk, and insider risk. Changes to shared settings can affect multiple rules in the plan, so administrators should review the scope before saving.

Limitations and open questions

The feature is in preview, so the interface and behavior may change. The source material does not specify the licensing requirements, which tenants can use policy plans, or the planned timing for general availability. It also does not provide a complete account of how every Conditional Access setting maps during migration.

The migration creates the new plan and its rules in the off state; it does not make the policies immediately enforceable as part of the plan. Administrators need to check rule behavior, use report-only where appropriate, and validate the results through sign-in logs before deciding to enable rules.

The walkthrough advises disabling the separate existing policies only after review, when the administrator is ready to switch. It does not describe automatic removal or deactivation of the originals, so do not assume migration alone retires them. The example's rule settings and user scope are specific to its test environment.

For teams considering the feature, the practical next step is to inspect the preview in their own tenant and test with carefully selected policies. The demonstration supports a staged approach: create or migrate, review the plan's shared scope, validate rules in report-only, and make enforcement changes only after checking impact.

Sources

• Peter Rising [MVP] demonstration of Conditional Access policy plans

Frequently asked questions

Are Microsoft Entra Conditional Access policy plans generally available?

The demonstration identifies policy plans as a preview feature. The source material does not state a general availability date or rollout scope.

How do I migrate Conditional Access policies into a plan?

In the Microsoft Entra admin center, go to Conditional Access > Policies and use “Migrate to Conditional Access policy plans.” Select policies and create a named plan. The demonstrated migration creates the rules turned off.

Should I turn on migrated policy plan rules immediately?

The migration screen says rules are created off to avoid disruption and recommends using report-only to validate impact first. The walkthrough uses sign-in logs to review impact before making the switch.

What licenses are required for Conditional Access policy plans?

The available source material does not specify licensing requirements.