Conditional Access policy plans reorganise how Conditional Access is managed in Microsoft Entra ID without changing its evaluation engine. As of 1 November 2026, this feature is still in preview: it should be tested as a new governance layer, not treated as a simple interface redesign.
What policy plans change in Microsoft Entra ID
In Microsoft Entra ID, formerly Azure Active Directory, teams often organise their policies by prefix, persona or application. This approach becomes hard to maintain when several policies repeat the same users, exclusions and resources.
Plans group these elements around a common objective. It can be a profile, such as administrators or headquarters staff, or a security objective, such as requiring a compliant device.
The Microsoft Learn documentation on Conditional Access policy plans states that the menu is called Policy plans (Preview). It is located under Entra ID > Conditional Access.
| Aspect | Standalone policy | Rule in a plan | Operational consequence |
|---|---|---|---|
| Organisation | One independent policy | A rule attached to a common objective | The plan reduces duplicated targeting |
| Shared conditions | No | Yes | One change can cover several rules |
| Evaluation | Independent | Independent | All applicable policies and rules must be satisfied |
| Logs | One entry per policy | A separate entry per rule | Troubleshooting remains possible rule by rule |
| Availability | Existing model | Preview | A pilot is required before wider rollout |
Plans therefore complement standalone policies. They do not replace them and do not create any order of priority between controls.
Inheritance means you must design targeting before rules
A plan has three parts: its details, its shared conditions and its rules. The details include the name, description, tags and owners. At least one rule must be added.
Shared conditions define the common scope. A rule inherits this scope and adds its own conditions, grant controls or session controls.
This inheritance follows several constraints:
- a rule cannot narrow the targeting defined by the plan;
- it cannot remove an inherited exclusion;
- it can add its own exclusions;
All usersis not available in shared conditions, but can still be used in rules;- shared conditions cannot mix several identity types, such as users and agents.
When several identity types must be covered, the identity choice should remain at rule level. This architecture avoids creating a plan whose common scope would be incompatible with certain controls.
At runtime, each rule in the plan and each standalone policy are evaluated separately. There is no priority between them. Access is granted only if all applicable controls are satisfied.
Prerequisites and licences to check before the pilot
The minimum documented role for creating a plan is Conditional Access Administrator. The principle of least privilege leads to using this role rather than a broader administration role.
Prepare the tenant before creating a plan
- Inventory existing policies, their owners and their dependencies
- Identify emergency access accounts and service accounts
- Prepare a limited group for the pilot phase
- Check exclusions at plan level and for each rule
- Define the sign-in logs to monitor before activation
- Confirm support for the backup, restore and automation tooling used by the organisation
- Check the specific licences if the plan targets AI agents
For agents, the documentation cited by Daily Entra News indicates that Conditional Access requires a Microsoft Agent 365 licence. Two licensing routes are mentioned.
| Option | Stated composition | Use case |
|---|---|---|
| Microsoft 365 E7 | Microsoft 365 E7 | Conditional Access for agents |
| Agent 365 with Entra | Agent 365 combined with at least Entra P1 | Conditional Access for agents |
| Agent 365 with Microsoft 365 | Agent 365 combined with at least Microsoft 365 E3 | Conditional Access for agents |
An earlier statement from May 2026 mentioned only Entra P1 or Microsoft 365 E3. It is no longer up to date for this agent scenario. The licence must be validated before building a plan intended for agentic identities.
Create a pilot plan without disrupting production
The portal lets you start from scratch or use a template. Rules created from a template are initially set to Off, according to the Microsoft Learn procedure for creating a plan.
A typical configuration can target headquarters staff. The plan holds the relevant group and the common exclusions. Two rules then enforce different controls without repeating that targeting.
Define the objective and ownership
Create the plan under Entra ID > Conditional Access > Policy plans (Preview). Enter a clear name, a description, tags and at least one owner.
Configure the shared scope
Add the headquarters staff group. Exclude emergency access accounts and service accounts in the shared conditions, in line with Microsoft's recommendation.
Require phishing-resistant authentication
Add a first rule that uses the appropriate authentication strength. Switch it from Off to Report-only to observe its effect without blocking sign-ins.
Require a compliant device
Add a second rule that requires a device marked as compliant. It reuses the plan's targeting and exclusions.
Review the sign-in logs
Check the result of each rule separately. The logs must confirm the expected targeting, the exclusions and the controls that would have been applied.
This validation must cover ordinary sign-ins, excluded accounts and recovery scenarios. The IAMinerva framework for testing Conditional Access policies provides a method to avoid lockouts during this phase.
Migrate existing policies without a break in control
The migration tool lets you filter existing policies, for example by name prefix, then merge them into a plan. The preview shows the resources converted into shared conditions and the mapping between each policy and its future rule.
Select a coherent set
Start with policies that genuinely share a persona, a resource or an objective. A common naming convention does not guarantee that their exclusions are compatible.
Review the merge preview
Check the identities, resources, locations, grant controls and session controls. Above all, verify what is lifted up to the shared conditions level.
Test the generated rules
Keep the new rules in Report-only during validation. Compare their results with those of the standalone policies that are still active.
Perform the cutover
Enable the plan only after validating its functional equivalence. Then disable the original policies to avoid unintentionally keeping duplicate controls.
Keep a way back
Prefer disabling the legacy policies first rather than deleting them. Deletion should only happen after the stabilisation period defined by the organisation.
Existing policies remain applied until the cutover. This continuity reduces the risk of creating a window without controls, but it requires monitoring the period during which old policies and new rules coexist.
Preview limitations change the deployment strategy
The Location condition has a specific restriction. For users targeted by a plan that uses it, Microsoft issues one-hour access tokens, without instant IP enforcement.
The Location condition requires dedicated testing
An IP address change does not trigger an immediate new check for the lifetime of the token. Do not reorganise a production configuration based on locations without reproducing its mobility, VPN and Internet egress scenarios.
In his analysis of Conditional Access policy plans, Tony Redmond recommends checking support for Microsoft Graph, PowerShell, backup and restore before managing at scale. He also stresses that inventorying existing policies can account for a significant part of the project.
No migration script is therefore offered here. Until the organisation has validated the preview's automation interfaces in its tenant, the portal remains the most controllable approach for a pilot.
Strengths
- Targeting shared across several rules
- Owners and tags defined at plan level
- Preview before policies are merged
- Separate diagnostics for each rule
Limitations
- Feature still in preview
- Specific restriction with the Location condition
- Backup tool compatibility to be verified
- Prior inventory potentially lengthy
Frequently asked questions
Do policy plans replace existing Conditional Access policies?
No. Plans are added to the existing model. Standalone policies and plan rules are evaluated independently, with no order of priority.
Can you use All users in shared conditions?
No. All users is available in rules, but not in the plan's shared conditions. Targeting must be designed accordingly.
Can a rule narrow the scope defined by the plan?
No. A rule can neither restrict the plan's targeting nor remove its exclusions. It can, however, add its own exclusions.
Are plans ready for a full production migration?
As of 1 November 2026, they are in preview. A limited pilot, validation in Report-only and a rollback procedure are required before any broad reorganisation.
Three decisions to make before deployment
The first choice concerns scope. An organisation with many duplicated policies can start with a simple, well-documented persona. An organisation that depends on network conditions must first assess the limitation tied to Location.
Recommended action plan
- Choose a single coherent set of policies for the pilot
- Name a business owner and a technical owner
- Place emergency access and service accounts in the shared exclusions
- Create the rules in
Report-onlystate - Compare each rule with the existing policies in the logs
- Test network location changes and recovery scenarios
- Disable legacy policies before considering their deletion
- Document the rollback method and automation dependencies
If the tenant already uses Microsoft Graph or PowerShell automation to back up Conditional Access, its compatibility with plans must become a decision criterion. Without this validation, deployment should remain limited to the pilot.
Going further
- What are Conditional Access policy plans? — how it works, inheritance and preview limitations.
- Create a Conditional Access policy plan — the Microsoft procedure and recommended exclusions.
- Microsoft-managed Conditional Access policies — Microsoft-managed policies to align with plans.
- Testing framework for Conditional Access policies — a validation method before production activation.
- What's new in Teams, Entra ID, Copilot and SharePoint — a broader view of Microsoft 365 administration changes.
