Conditional Access has become one of the most important security controls within Microsoft Entra ID. It allows organizations to control access to applications and resources based on identity, device compliance, location, risk, and other conditions. However, as environments grow, so does the number of policies required to secure them.
For organizations managing hundreds or thousands of users, multiple device platforms, different access requirements, and increasingly complex security configurations, Conditional Access can quickly become difficult to manage. What starts as a few policies requiring multi-factor authentication and compliant devices often develops into a much larger collection of policies, with overlapping assignments, repeated exclusions, and different configurations.
Microsoft has introduced Conditional Access Policy Plans, currently in preview, to help address some of these challenges. Rather than managing every Conditional Access policy independently, administrators can organize related policies into plans that share common conditions, assignments, and exclusions while retaining individual enforcement rules.
This is more than simply grouping policies together for organizational purposes. It introduces a different approach to designing and managing Conditional Access, particularly for organizations dealing with policy sprawl, complex access scenarios, and the growing need to secure both traditional users and agent identities.
The Problem with Traditional Conditional Access Management
One of the challenges with Conditional Access has always been maintaining consistency across policies. Each policy operates independently, with its own assignments, conditions, exclusions, and controls.
Consider an organization that requires compliant devices for Microsoft 365 access but needs different requirements for Windows, macOS, iOS, and Android. Administrators might create separate policies for each platform, all targeting the same users and applications, while excluding the same emergency access accounts.
This approach works, but it introduces duplication. Every time an assignment or exclusion changes, administrators must identify and update each affected policy. Missing one policy could result in inconsistent security enforcement or, in more serious situations, unintended access restrictions.
The problem becomes more significant when additional policies are introduced for administrators, external users, specific applications, network locations, and different risk levels. Over time, organizations can end up with dozens or hundreds of policies where the individual configurations are technically correct, but understanding how they collectively affect access becomes increasingly difficult.
This is where Conditional Access Policy Plans provide an interesting alternative.
Understanding Conditional Access Policy Plans
A Conditional Access Policy Plan is essentially a collection of related enforcement rules that operate under a common set of assignments and conditions.
Instead of defining the same users, applications, locations, and exclusions across multiple standalone policies, administrators can define common settings at the plan level. Individual rules within that plan then inherit those settings and introduce the additional requirements needed for their specific scenarios. Microsoft has structured policy plans around three main components.
Plan Details
Define the name, description, ownership, and optional tags associated with a policy plan. These provide organizational context and accountability, although they do not directly influence enforcement or grant management permissions.
Shared Conditions
Establish common identity assignments, application targeting, exclusions, risk levels, device platforms, network locations, and other supported conditions that apply across the plan's rules.
Individual Rules
Define the specific scenarios, additional conditions, grant controls, and session controls required to enforce access. Each rule is independently evaluated, even though it inherits the plan's shared configuration.
The important distinction is that policy plans do not replace Conditional Access enforcement with a single combined decision. Each rule continues to operate independently, using the shared conditions inherited from the plan alongside its individual settings.
A Practical Example
Consider an organization that wants to enforce device compliance across its corporate environment.
Traditionally, it might create separate policies for Windows, macOS, iOS, and Android devices. Each policy could target the same employee group, protect the same Microsoft 365 resources, and exclude the same emergency access accounts.
With policy plans, administrators can organize these requirements under a single security objective:
The benefit becomes clearer when something changes. If the organization needs to update a shared exclusion, it can make that change at the plan level rather than updating four separate policies.
However, there is an important consideration. Rules inherit shared targeting, and administrators cannot use an individual rule to narrow the plan's inherited inclusion scope. Rules can introduce additional exclusions, but shared exclusions cannot be overridden.
This means that designing the shared conditions correctly is particularly important. Administrators should only place settings at the plan level when those settings genuinely apply to every rule.
How Conditional Access Evaluation Changes
One question that immediately comes to mind is whether introducing policy plans changes how Conditional Access evaluates access. The answer is that the fundamental enforcement model remains the same.
When a user attempts to access a protected resource, Microsoft Entra ID evaluates the applicable Conditional Access policies and policy plan rules. For each rule within a plan, Microsoft combines its inherited shared conditions with its individual conditions to determine whether that rule applies. If it applies, the associated controls must be satisfied.
Existing standalone policies continue to operate alongside policy plan rules. There is no special precedence between them, and an applicable plan rule does not override a standalone policy.
Every applicable policy and rule must be satisfied for access to be granted. Individual rules also appear separately within sign-in logs, allowing administrators to investigate their effects.
Policy plans simplify how related rules are configured and maintained. They do not replace the Conditional Access engine or combine every rule into one enforcement decision.
This is important because policy plans should not be considered a way to reduce the actual number of security decisions being evaluated. Instead, they provide a more manageable structure for configuring and maintaining those decisions.
It also means that administrators need to pay attention to overlapping requirements. A newly enabled policy plan rule can introduce additional controls alongside existing policies, even if the administrator intended it to replace an earlier configuration.
Managing Exclusions More Consistently
One of the more valuable capabilities of policy plans is the ability to manage exclusions centrally. Exclusions have always required particular attention when working with Conditional Access. Organizations commonly exclude emergency access accounts from policies to maintain a recovery path when access controls are misconfigured. When those exclusions are repeated across many policies, there is always a possibility that one will be missed.
Policy plans allow administrators to define exclusions within the shared conditions. Those exclusions are then inherited by every rule within the plan and cannot be removed by an individual rule.
For example, suppose a plan excludes two emergency access accounts, while one specific rule also excludes a testing group. The effective exclusions for that rule include both emergency accounts and the additional testing group.
This improves consistency, but it also introduces a larger scope of impact. An incorrect exclusion at the plan level affects every rule within that plan. Administrators therefore need to treat shared-condition changes as potentially significant security changes rather than routine policy maintenance.
It is also worth remembering that Conditional Access for users does not automatically control service principal sign-ins. Workload identity scenarios require their own appropriate targeting and controls.
Building Policy Plans Around Security Objectives
A useful aspect of this new model is the opportunity to organize Conditional Access around security objectives instead of individual technical settings. Many organizations have historically created policies based on immediate requirements. A new application needs protection, a particular group requires stronger authentication, or a new device platform needs additional controls. Although this approach addresses individual requirements, it can result in a policy collection that does not clearly represent the organization's overall security strategy.
With policy plans, administrators can start by defining what they want to protect and then create the individual rules required to achieve that objective. For example, an organization could consider plans for corporate device access, privileged user protection, external access, or agent identity security. Each plan would contain only the related scenarios that genuinely share the appropriate targeting or conditions.
This distinction matters. Creating one enormous plan containing every Conditional Access rule would simply move the existing complexity into a different structure.
The value comes from creating logical boundaries around common security objectives, with clear descriptions, documented ownership, and consistent assignments.
Supporting Agents and More Complex Access Scenarios
Another interesting part of Microsoft's introduction of policy plans is its focus on agent identities.As organizations adopt AI agents and other autonomous systems, identity security requirements are expanding beyond traditional users and applications. An agent might operate using its own identity or interact with resources on behalf of a user. These scenarios can require different Conditional Access controls, even when they relate to the same risk or security objective.
Policy plans can support this by sharing compatible conditions across rules that target different identity types.
For example, a plan could establish a common agent risk condition while using separate rules for agent users and autonomous agents.
There is, however, a restriction. Shared conditions cannot mix identity types. If a plan needs rules covering users and agents, identity targeting must be configured at the rule level rather than attempting to combine those identities within the plan's shared assignment.
This is an important design consideration, particularly as Microsoft continues to expand identity governance and access controls for non-human identities.
Policy plans also have potential value for Global Secure Access, where large numbers of network-scoped rules may share common user and application assignments. Reusing that configuration can reduce the administrative work involved in maintaining complex access environments.
Migrating Existing Conditional Access Policies
Microsoft has also introduced a migration experience to help organizations convert existing policies into policy plans. Rather than requiring administrators to recreate every policy manually, the migration functionality can analyze selected policies, identify common conditions, and propose a plan structure.
Settings shared across the selected policies become candidates for shared conditions, while the individual configurations remain associated with their respective rules.
There are several important points to understand before using this functionality.
First, the original policies remain unchanged during migration. They continue operating in their existing states, which allows administrators to validate the newly created plan before changing enforcement.
Second, the newly created rules are initially disabled. Administrators can move them into Report-only mode to examine their effects without immediately enforcing the new configuration.
Finally, migrating to a policy plan does not automatically mean that the original policies should immediately be removed. Existing policies and new rules are evaluated independently, so transitioning between them needs to be carefully controlled.
A Sensible Migration Approach
I would approach migration in stages, starting with a small collection of related policies rather than attempting to reorganize the entire Conditional Access configuration.
This process is particularly important for organizations with mature Conditional Access deployments. A migration might produce a configuration that appears cleaner from an administrative perspective, but the real requirement is to ensure that the resulting enforcement decisions remain consistent with the original security objectives.
Any changes to shared conditions should be reviewed carefully, especially where those changes could alter the effective targeting of multiple rules.
Creating a New Conditional Access Policy Plan
For administrators interested in testing the preview, policy plans are available through the Microsoft Entra admin center in supported environments.
- Navigate to Entra ID > Conditional Access > Policy plans (Preview).
- From there, administrators can create a custom plan or start with a template. Templates can include predefined shared conditions and multiple rules designed around a common security scenario.
A custom plan allows administrators to define the plan's name, description, ownership, shared conditions, and individual rules. Each plan must contain at least one rule, and individual rules can include the grant and session controls required for their specific scenarios.
The Conditional Access Administrator role is required to create, modify, or delete policy plans. The relevant Conditional Access licensing requirements also apply.
For initial testing, I would recommend creating a plan with a limited scope, using Report-only mode, and reviewing sign-in logs before enabling enforcement.
There is also an important preview limitation to consider. Microsoft currently documents that policy plans targeting users with a Location condition receive one-hour access tokens without instant IP enforcement checks.
Organizations relying on near-real-time location enforcement should evaluate this limitation before adopting the feature for those scenarios.
Does This Actually Simplify Conditional Access?
I think the most interesting aspect of Conditional Access Policy Plans is not necessarily the individual capabilities, but the change in how administrators can approach policy design.
Conditional Access has always been powerful, but its flexibility also makes it easy to create configurations that become increasingly difficult to understand and maintain.
Policy plans introduce a way to define common requirements once and reuse them across related security scenarios. This can reduce duplication, improve consistency, and provide a clearer structure for managing access requirements.
However, they do not eliminate the need for proper planning, testing, and ongoing monitoring.
A badly designed policy plan can introduce the same problems as badly designed standalone policies, potentially affecting more rules at once because of shared targeting and exclusions.
There is also the question of how organizations will incorporate policy plans into existing governance processes, automation, configuration reviews, and change management. These areas will become particularly important as the feature progresses beyond preview.
Are Conditional Access Policy Plans Available in GCC High?
One question that will be particularly important for organizations operating in Microsoft 365 Government environments is whether Conditional Access Policy Plans are available in GCC High.
As of October 29, 2026, I could not verify an explicit Microsoft confirmation that Conditional Access Policy Plans are available in GCC High tenants. The feature remains in preview, and Microsoft's policy plans documentation does not identify GCC High or DoD as supported environments.
This distinction is important because Microsoft Entra ID features are not always introduced simultaneously across commercial and government cloud environments.
GCC High and DoD tenants operate within Azure Government, which uses separate infrastructure and service endpoints from the commercial Azure environment. Although the underlying Conditional Access functionality is supported, newer capabilities and preview features may follow different deployment schedules.
Microsoft's Entra feature availability documentation for Azure Government lists Conditional Access as available. However, it does not separately identify Conditional Access Policy Plans as an available capability. That general entry should not be interpreted as confirmation that every newer Conditional Access preview feature is supported.
For administrators working in GCC High, the absence of an explicit availability statement means that policy plans should not yet be considered a confirmed supported capability without further verification.
Administrators can sign in to the Microsoft Entra admin center and navigate to Entra ID > Conditional Access, checking whether the Policy plans (Preview) option appears. They can also review Microsoft government cloud documentation or contact Microsoft support for confirmation.
However, the appearance of a feature in the portal does not necessarily establish that it is fully supported within a government environment.
Until Microsoft confirms GCC High availability, organizations should continue designing and maintaining their Conditional Access configurations using existing standalone policies.
This does not prevent administrators from preparing for policy plans. In fact, reviewing existing policies, identifying duplicated conditions, documenting exclusions, and grouping policies by security objective would provide a useful foundation for adopting the feature when it becomes available.
For organizations with particularly complex Conditional Access configurations, this preparation could make the eventual migration considerably easier.
Commercial preview availability should not be assumed to extend to GCC High or DoD environments. I could not verify a publicly confirmed GCC High release date or deployment timeline.
Final Thoughts
Conditional Access Policy Plans represent a useful evolution in how Microsoft Entra ID handles complex access requirements.
For smaller organizations with only a handful of policies, the immediate benefit might be limited. However, for larger environments where Conditional Access has expanded into dozens or hundreds of policies, the ability to share common assignments and exclusions could make a significant difference.
The feature also reflects the changing nature of identity security. Administrators are no longer securing only interactive users accessing Microsoft 365 applications. They increasingly need to account for privileged identities, external access, workload identities, AI agents, and complex network access scenarios. Managing those requirements through a growing collection of disconnected policies is not always sustainable.
What I particularly like about this approach is that it encourages administrators to think about the security objective first and the individual enforcement rules second.
That is a sensible direction for Conditional Access, provided organizations resist the temptation to simply consolidate everything without understanding the dependencies.
For organizations operating within GCC High, there is the additional consideration of feature availability. While it might not be possible to adopt policy plans immediately, there is still value in reviewing existing configurations and preparing for a more structured approach.
The real benefit is not having fewer policies to look at. It is having a more consistent, understandable, and maintainable approach to enforcing access.
As with any preview security functionality, I would test this in a controlled environment before considering it for wider production use.
Article updated October 29, 2026. Conditional Access Policy Plans remain in preview. GCC High support is not explicitly confirmed in the Microsoft documentation reviewed.