That description is ambitious, but the change is real. Policy plans don't make Conditional Access a different security engine. They do change how admins build, review and update their access rules, which deserves a close look before anyone clicks "Migrate."
What a policy plan actually is
A policy plan groups related Conditional Access settings around one security objective. Microsoft's examples are requiring compliant devices and securing AI agent activity. Each plan has three layers:
| Layer | What it holds | Why it matters |
|---|---|---|
| Plan details | Name, description, optional tags, individual or group owners | Shows who is accountable. Owners don't get edit rights, and this layer has no effect on enforcement |
| Shared conditions | Optional targeting inherited by every rule: identities, resources, user actions, authentication context, risk levels, device platforms, network locations, client app types | You define scope and exclusions once instead of repeating them in each policy |
| Rules | Assignments, conditions, grant controls and optional session controls for one scenario | Each requirement stays granular. Every plan needs at least one rule |
Microsoft's main example is a team that wants identity administrators to use phishing-resistant MFA, sign in from compliant devices and fix risk when an account is flagged. Until now that took three policies with the same scope. With a plan, the admin group and emergency-access exclusions go in once at plan level, and each requirement becomes its own rule.
Admin365.Blog sums up the trade-off well: "Plans change how you organize controls, not how Conditional Access enforces them." Office 365 for IT Pros reached the same conclusion, describing plans as changing how administrators organize and manage Conditional Access configuration rather than fundamentally changing how Conditional Access works.
Section summary: A plan is a container for related rules. Shared conditions apply to every rule in it. Plan details are for accountability only.
The inheritance rules you need to know
Inheritance is where plans save effort, and also where mistakes can spread fastest. Microsoft Learn sets out these behaviours:
- Scope is additive and can't be narrowed. If the plan targets Group A, every rule inherits that. A rule can add its own exclusions but can't shrink the plan's scope.
- "All users" is only available in rules. Because rules can't narrow plan scope, you can't pick All users in shared conditions. "All resources" also has to be selected at rule level.
- Shared conditions need one identity type. A plan that targets users at plan level can't also target agents or workload identities there. To cover several identity types in one plan, leave identity assignment to the individual rules.
- Exclusions add up and can't be removed by a rule. If the plan excludes emergency groups A and B and a rule excludes group C, the effective exclusion list is A, B and C. Microsoft presents this as protection against accidental lockouts.
The practical consequence: a change to shared conditions applies to every rule in the plan. Microsoft's advice is to put only conditions that genuinely apply to every scenario at plan level. Treat the shared-conditions blade the way you treat a Group Policy Object linked at the domain root. Edit it carefully and preferably after coffee.
How plans coexist with your existing policies
Plans run side by side with your current Conditional Access policies. They don't replace them. During sign-in evaluation, the Conditional Access engine evaluates both existing policies and policy plan rules. Every applicable policy and every applicable rule must be satisfied for access to be granted. Neither one takes precedence over the other.
At sign-in, Entra merges each rule with its plan's shared conditions and evaluates the result as a separate enforcement decision, just like a standalone policy. So:
- Turning on a plan does not switch off an equivalent legacy policy. Leave both on and users have to satisfy both.
- Each rule shows up as its own entry in the Conditional Access tab of sign-in log details. Helpdesk and incident responders can see exactly which rule applied, then open its plan to see the shared conditions and related rules.
Section summary: Plans are an additional layer, not a merge. Everything that applies must pass, and every rule is logged separately.
AI agents and Global Secure Access
Microsoft is presenting plans partly as a way to bring AI agents under the same Zero Trust model as people. Microsoft Learn notes that agent identities can act with their own permissions or on behalf of a user using that user's permissions. In Microsoft's example, a plan sets "high agent risk" once as a shared condition, then uses separate rules for agent users and autonomous agents.
This is also a practical case for the identity-type restriction. Agents and users can't be mixed in shared conditions, so the agent-type targeting goes into the rules.
Templates can create the plan, its shared conditions and its rules in one flow. Microsoft says plans can combine several templates, whereas standard policies use one template each.
The other scaling case is Global Secure Access. Microsoft Learn says those deployments often need hundreds of network-scoped rules aimed at the same users and apps. Defining that population once and keeping each rule to a single network scope makes the sprawl much easier to manage.
Step-by-step: creating a plan
You need the Conditional Access Administrator role to create, modify or delete plans. Microsoft's announcement says customers with Microsoft Entra ID P1 or P2 can start using the preview now. The Learn pages point to the general Conditional Access licensing requirements, so check scenario-specific licensing yourself, especially for risk-based and agent rules.
From a template:
- Sign in to the Microsoft Entra admin center and go to Entra ID > Conditional Access > Policy plans (Preview).
- Select Create policy from template, choose Use template for one or more templates, then Create plan.
- Review the prepopulated shared conditions and select Create policy plan. Every rule generated from a template starts Off.
- Select Edit plan, then Add Users > Exclude to add your emergency access accounts and any service accounts that every rule should skip.
- Review each rule, change its State from Off to Report-only, check the effect, then set it to On.
From scratch:
- In Policy plans (Preview), select Create policy, then enter a name, optional description, tags and owners. Your account is added as an owner automatically.
- Configure shared conditions if you need them: identities to include or exclude, resources or authentication contexts, and conditions such as risk, platform, location or client app type.
- Select Continue, name your first rule, set its State to Report-only, and add rule-specific assignments, conditions and grant or session controls.
- Select Create. Repeat for each additional scenario.
- Check impact with the built-in policy impact metrics or the sign-in logs before switching rules to On.
A reminder from Microsoft's setup guidance: calls made by service principals aren't blocked by Conditional Access policies scoped to users. Workload identities need their own Conditional Access targeting.
Step-by-step: migrating existing policies safely
The migration tool is the part long-established tenants will care about most. Microsoft suggests grouping candidate policies by protected resource, by persona or by a shared condition, and starting with a small group you understand well.
- Go to Entra ID > Conditional Access > Policies, find the Migrate to Conditional Access Policy plans (Preview) banner and select Get started.
- Select the related policies, then Merge policies into a plan.
- Review the preview. Settings the selected policies have in common become shared conditions. Each policy becomes a rule that keeps its own identities, resources, locations, grant controls and session controls.
- Select Create policy plan, then Edit plan to add the name, description, tags and owners.
- Move each rule to Report-only when you're ready.
Migration does not change your original policies. They keep whatever state they had (On, Off or Report-only) and keep enforcing. The new rules start Off.
To validate, go to Entra ID > Monitoring & health > Sign-in logs and confirm each rule matches the expected users, apps and conditions, and behaves the same as the original policy. Only then turn the rules On. After that, turn the old policies Off and check that sign-in behaviour hasn't changed. Delete the old policies only after the validation period, and only if your change-management and retention rules allow it.
Check the exclusions after migrating. LazyAdmin's walkthrough warns that for most baseline policies, this means you have to move your break-glass exclusions yourself into the plan. Don't assume the tool put your emergency-access exclusions at plan level. Open the shared conditions and confirm it.
The preview caveats to check before you deploy
Location-based controls. This is the biggest warning. During preview, policy plans that target users with Location as a condition will be issued one-hour access tokens without instant IP enforcement check. LazyAdmin describes this as losing the instant IP check that Continuous Access Evaluation normally provides. If your security posture depends on near-instant revocation when a user leaves a trusted network, keep those controls in standalone policies for now.
Backups and automation. Admin365.Blog reports that policy plans are not included in your current Conditional Access backups. Rules do not appear in the Microsoft Graph PowerShell cmdlet for Conditional Access policies, including the beta version. Your config-as-code pipeline, drift detection and documentation tools could miss the plans entirely. LazyAdmin says plans can be read from the beta/identity/conditionalAccess/plans endpoint with the Policy.Read.All permission, and the response includes each plan's rules. Expect a beta endpoint to change.
Government clouds. Shareplicity notes that Microsoft's policy plans documentation does not identify GCC High or DoD as supported environments. Sovereign-cloud tenants should check whether the blade actually appears before planning around it.
Timing. The rollout started before the announcement. The Learn documentation was last updated on October 26, and LazyAdmin observed that it's still in preview, but it's already showing up in production tenants before the official November 4 blog post. If a colleague has already been experimenting, check your tenant for existing plans.
Analysis: worth it, but take it slowly
Policy sprawl is a real problem. Exclusion lists that drift out of sync are a classic cause of lockouts and coverage gaps, and plan-level exclusions that rules can't override address that directly. The ownership metadata should also make auditors happier than a policy called "CA-017-FINAL-v3."
Microsoft's announcement does play down two points. First, plans organize enforcement decisions but don't reduce them: every rule is still evaluated independently. Second, a single shared-conditions edit now affects many rules at once, so its impact is larger in both directions. Office 365 for IT Pros expects adoption to be slow: it's probably going to take some time for tenants to inventory their current CA policies, understand points of commonality.
For most organizations, a sensible path looks like this:
- Start in a test tenant or with a low-risk, well-understood group of policies.
- Keep location-dependent controls out of plans until the token caveat is fixed.
- Sort out backups first. If your tooling can't see plans, you can't restore them.
- Use Report-only for every rule before enforcement, without exception.
Policy plans could make Conditional Access much easier to govern, especially as AI agents add another identity type to the estate. For now it's a preview: test it, document it, and keep your break-glass accounts excluded at plan level.