Microsoft Entra Conditional Access policy plans

Key insights

• A plan holds shared identities, resources and conditions that apply to its rules.
• Individual rules retain their own controls, such as phishing-resistant MFA or compliant-device requirements.
• All users and all resources can be scoped at the rule level, according to the demonstration.
• The migration flow creates rules in an off state; validate them before enabling.
• The feature is described in the supplied research notes as being in public preview.

Microsoft Entra Conditional Access policy plans group related access rules under shared targeting, reducing the need to repeat common assignments and exclusions. They matter to Entra administrators who maintain multiple policies for the same users, apps or security objective. Nick Ross [MVP] (T-Minus365) demonstrates creating a plan, adding rules, reviewing sign-in logs and starting a migration from existing policies.

What's new

A policy plan is an organizational container for related Conditional Access rules. Administrators can set common identities, resources and conditions at the plan level, then add individual rules for specific controls. For example, a plan for privileged access might target administrator roles and exclude emergency access accounts once, while separate rules require phishing-resistant multifactor authentication, a compliant device or a shorter sign-in frequency.

That structure separates shared scope from the enforcement requirement in each rule. It can help reduce duplicated configuration when multiple controls apply to the same group. It does not mean those controls become one combined decision: the rules still represent separate requirements, and applicable controls continue to stack on a sign-in.

Plan-level settings have consequences beyond organization. Changing shared identities, resources or conditions affects the downstream rules in that plan. Administrators should therefore treat a shared condition as a baseline for the whole group, not as a label or description. The demonstration also shows plan owners and tags as organizational details; Ross says those do not override existing role-based access controls.

Who it is for and what you need

The feature is aimed at administrators managing Conditional Access policies, particularly in tenants where many policies repeat assignments or exclusions. The supplied research notes describe policy plans as being in public preview and state that customers with a Microsoft Entra ID P1 or P2 license can use the capability. Confirm current preview terms and licensing with Microsoft because preview functionality can change.

The material does not specify a required region or a separate prerequisite beyond access to the Microsoft Entra admin center and the relevant Conditional Access permissions. Nor does it establish availability for every tenant. The video describes the feature as in preview at recording time, while the research notes also identify public preview; check the current portal and Microsoft documentation before planning a rollout.

For a production environment, the safest practical consideration in the material is to validate the rules before enabling them. The demonstration starts new rules in Report-only, and its migration section says migrated rules are created off. Report-only lets administrators assess effects without enforcing that rule, while an off rule is not active; review the resulting state rather than assuming migration enables protection.

How it works

In the Entra admin center, open Conditional Access and create a policy plan. Give it a name tied to its security outcome, then configure shared identities, resources or conditions only where multiple rules genuinely have the same scope. An emergency access exclusion is one example of a shared setting that can keep related rules aligned.

1. Create the plan and, if useful, add owners or tags for organization. These do not grant or replace tenant permissions.
2. Set shared scope and conditions that should apply to every rule. Add directory roles or exclusions as appropriate to the plan’s objective.
3. Add a rule for each distinct requirement. Configure its state, rule-specific scope, resources and grant or session controls. The demonstration uses phishing-resistant MFA, compliant-device enforcement and sign-in frequency as examples.
4. Review the plan and rules, then use Report-only where appropriate to evaluate impact before enforcement.
5. Check sign-in logs to see the plan and its individual rule, including whether a rule applied, succeeded or was in report-only mode.

Shared settings are optional. Ross demonstrates that all users and all resources can be chosen at the individual rule level, even though the shared-scope controls he tests do not offer those same all-users or all-resources choices. A rule can add its own targeting on top of the plan’s shared settings. Keep rule names meaningful because they appear in sign-in-log details.

The demonstration also shows options to edit or duplicate a rule, move it to another plan, and edit a plan’s shared settings. For migration, the Conditional Access policy section offers a “Get started” flow to convert existing policies into a plan. The available transcript cuts off during the migration walkthrough, so it does not establish every migration step or outcome.

Limitations and open questions

Plans change how administrators organize and maintain rules, not the basic effect of applicable Conditional Access requirements on sign-ins. Rules still need review, clear names and appropriate testing. A change to shared scope flows through the plan, which can broaden or narrow the targeting of several rules at once.

The demonstration reports that its plan-creation wizard allowed only one rule during initial setup; additional rules could be added afterward. It also notes that the shared targeting interface did not offer “all users” or “all resources” in the areas tested, with those choices available at rule level instead. These are observations from the demonstration, not a definitive list of current preview limits.

Existing standalone policies are not described as automatically replaced by plans. The migration flow creates rules in an off state, so administrators need to inspect the plan and decide how to validate and transition existing controls. The supplied material does not establish when the feature will reach general availability or provide a complete list of preview limitations.

Sources

• Microsoft Learn: Conditional Access policy plans
• Nick Ross [MVP] (T-Minus365): Conditional Access policy plans demonstration

Frequently asked questions

What is a Microsoft Entra Conditional Access policy plan?

It is a container for related Conditional Access rules. Shared identities, resources and conditions can be configured once for the plan, while each rule carries its own access control.

Are Conditional Access policy plans generally available?

The supplied research notes describe the feature as in public preview. The material does not establish a general availability date, so check Microsoft’s documentation for current status.

What license is needed for Conditional Access policy plans?

The research notes state that customers with Microsoft Entra ID P1 or P2 can use the capability. Verify current licensing and preview terms with Microsoft.

Can I migrate existing Conditional Access policies into a plan?

The demonstrated flow includes a migration option. The supplied material says migrated rules are created off, so review and validate them before enabling; it does not confirm every migration detail.