If you manage Conditional Access in a larger tenant, you know the pattern: the policy list keeps growing and nobody remembers which exclusion applies where. Microsoft now offers Conditional Access policy plans in public preview to deal with that sprawl. A plan groups related policies, and you define users, resources and conditions once instead of once per policy.
A policy plan holds the shared settings while each rule keeps its own requirement
Until now every Conditional Access policy was a standalone object. If you wanted both phishing-resistant MFA and a compliant device for the same user group, you built two policies and maintained the same groups and exclusions in both. With dozens of policies, a naming prefix is often the only thing holding the list together.
A plan turns that around. At plan level you set the identities, resources, client app types, network locations or risk levels that apply. Each rule inherits them and adds only its own conditions plus its grant or session controls. A plan also carries a name, description, owner and tags, so it is obvious what it is for. The Microsoft documentation on policy plans covers the model in detail.
One point matters in practice: every rule is still evaluated on its own at sign-in. There is no precedence between rules and classic policies, and everything that applies must be satisfied. A plan is a management construct, not a new enforcement engine.
The inheritance from plan to rules is easy to follow in a diagram
The diagram below uses a plan for headquarters staff to show how settings flow downward. The break-glass exclusion sits once in the plan and therefore applies to every rule.
flowchart TD
A["Plan: Headquarters"] --> B["Shared: user group"]
A --> C["Shared: break-glass exclusion"]
B --> D["Rule 1: phishing-resistant MFA"]
B --> E["Rule 2: compliant device"]
C --> D
C --> F["Rule 3: added later"]
B --> F
The plan passes the user group and the exclusion to all rules, and each rule adds only its own requirement.
Shared exclusions are cumulative. If a rule excludes an additional group, both exclusions apply, and a rule cannot remove an exclusion inherited from its plan. That is handy for break-glass accounts, but it becomes a risk if you put policies with different exceptions into the same plan.
Existing policies can be migrated with a wizard in the Entra admin center
You do not have to start from zero. In the Microsoft Entra admin center, go to Protection > Conditional Access, filter your policy list (for example by naming prefix), select the entries and start the migration. The wizard looks for common settings, lifts them to plan level and turns each policy into a rule. The guide on migrating policies into a plan walks through it.
Your original policies stay untouched and keep being enforced. In one community test, the new rules started out switched off. The break-glass group also did not move to plan level automatically, even though it appeared in every source policy. Add that exclusion yourself and review the result.
Two preview restrictions apply right now. "All users" cannot be chosen as a shared plan-level assignment, and "All resources" has to be set on the rule. Microsoft also documents a limitation for location conditions: during the preview, affected users get one-hour access tokens without an instant IP check. For that reason I leave security-critical location rules in classic policies for now.
The safest way to switch over takes five steps in report-only mode
I never enable a plan straight away. Work through the following steps in the Entra admin center under Protection > Conditional Access > Policy plans. A typical rule for this is blocking admin portals on unverified devices, which I covered in the post on Conditional Access for admin portals. You need at least the Conditional Access Administrator role and a Microsoft Entra ID P1 license.
- Select related policies with the same security goal and start the migration, or create a new plan.
- Compare the plan-level settings against each source policy, especially groups, resources and device filters.
- Add the break-glass group as a shared exclusion if the wizard did not carry it over.
- Set the new rules to report-only and compare the results in the sign-in logs with your current policies.
- Enable the rules only after that review, then disable the old policies without deleting them right away.
The comparison in step four is supported by the report-only mode results, which show which sign-ins a rule would have blocked or challenged.
Tip: Put only those settings at plan level that should apply to every current and future rule. Anything that might diverge later belongs in the individual rule.
Agent identities can be protected with a plan of their own
Microsoft ships templates, so you do not have to build every plan from scratch. The example in the Microsoft Tech Community announcement is a plan for agent risk: the shared condition is high agent risk, and below it one rule blocks agent users while another blocks autonomous agents acting with their own permissions. Without a plan, you would need separate policies with mostly identical conditions.
For environments already managed through scripts or pipelines, I would slow down a bit. The Graph endpoints for policy plans exist only in the beta version for now and are not supported for production use. Check first whether your export, backup and drift-detection tooling understands the new objects.
Large policy sets benefit from plans while small tenants usually do not yet
The biggest gain shows up in later changes, not at setup: you edit a shared condition once instead of three times. The flip side is that a mistake there hits every rule at the same time. With two or three simple policies that rarely change, the migration hardly pays off.
My approach is therefore selective. I create new, clearly scoped scenarios as plans, and I migrate existing baselines only once export and recovery of the new objects work reliably.
