Table of Contents
Conditional Access Policy Plans Aim to Reduce Policy Sprawl
Entra ID Conditional Access (CA) policies are one of the most important security features available to Microsoft 365 tenants. The basic concept is straightforward: policies evaluate inbound connections against signals such as user identity, device state, location, application, and risk, and then decide whether to allow access or impose controls such as multifactor authentication. As the term implies, access to the tenant is conditional on passing the tests defined in policies.
The problem is that the number of CA policies deployed within tenants tends to grow over time. A tenant might start with a handful of policies and end up with many more as administrators seek to protect different applications, user populations, locations, and authentication scenarios. Many of the resulting policies contain the same assignments, conditions, and exclusions.
It’s also true that Microsoft has improved the functionality of CA policies over the years, like the introduction of support for authentication strength for the method used in multifactor authentication. Changes within an organization, together with Microsoft’s continuing development of Conditional Access, mean that CA policies tend to evolve over time. Given their importance to tenant security, administrators are understandably reluctant to make unnecessary changes. Few tenants take the time to rationalize CA policies. If the existing policies do the job, why risk introducing a gap that attackers might exploit?
Microsoft is previewing Conditional Access policy plans as a potential solution to make complex Conditional Access configurations easier to organize and manage.
The Parts of a Conditional Access Policy Plan
A Conditional Access policy plan is essentially a container for a set of related CA rules. A plan consists of plan details, shared conditions, and individual rules. Figure 1 shows some of the UX for creating a Conditional Access policy plan in the Entra admin center.
Shared conditions are the interesting part. Instead of repeating the same configuration in multiple CA policies, administrators can define common conditions at the plan level and allow the rules in the plan to inherit them.
Consider a tenant that excludes two breakglass (emergency access) accounts from all its Conditional Access policies. It makes sense for all CA policies to incorporate these exclusions so that the break glass accounts can access the tenant if problems occur. If ten related policies contain the same exclusions, administrators must ensure that the exclusions remain synchronized whenever a change occurs.
Device platforms provide another example. An organization might maintain separate policies for Windows, macOS, iOS, and Android while applying the same user targeting and emergency-access exclusions to each. Policy plans allow administrators to define that common configuration once and have the plan’s rules inherit it.
With a policy plan, common exclusions can be defined at the plan level and inherited by the plan’s rules. The same principle applies to other common conditions, including identities, resources, risk, device platforms, locations, and client application types.
The potential advantage is obvious. Reducing duplicated configuration should make CA deployments easier to understand and lessen the possibility of configuration drift between related policies.
Not a New Enforcement Mechanism
CA policy plans are not a new enforcement mechanism. Microsoft positions policy plans as an addition to the existing model rather than a replacement for standalone CA policies. Rules within a plan continue to represent individual Conditional Access decisions. Existing standalone policies can coexist with plans. During sign-in evaluation, applicable standalone policies and plan rules accumulate independently, with no precedence between them. Every applicable policy and rule must be satisfied for access to be granted.
In other words, policy plans change how administrators organize and manage Conditional Access configuration rather than fundamentally changing how Conditional Access works.
Migrating Existing Conditional Access Policies
Microsoft also recognizes that most organizations interested in policy plans already have Conditional Access deployments. Entra can analyze selected existing policies to identify common conditions and propose how the policies could be migrated into a plan containing shared conditions and individual rules.
Importantly, the analysis doesn’t alter the existing policies. Administrators can therefore examine the proposed plan before deciding whether its structure makes sense. This might turn out to be one of the most useful aspects of the feature. It’s relatively easy to design an elegant Conditional Access structure for a new tenant. Reorganizing years of accumulated policies without inadvertently changing access controls is a very different proposition.
Given the potential consequences of getting things wrong in a production environment, administrators are likely to think long and hard before starting a migration. Documenting real-life experiences of successful and unsuccessful migrations will be important to this process as time goes by.
It’s a Preview
CA policy plans are currently a preview feature, so administrators should approach them with caution. Several preview-specific restrictions apply: plan-level targeting cannot be narrowed by individual rules, inherited exclusions cannot be removed by rules, shared conditions cannot mix identity types, and the All resources assignment is available only at the rule level.
More significantly, Microsoft warns that during the preview, users targeted by policy plans that use Location as a condition receive one-hour access tokens without an instant IP enforcement check.
Organizations considering plans should test their behavior carefully before using them to reorganize production configurations. Administrators should also consider how CA policy plans fit into the operational tooling surrounding Conditional Access. Microsoft says that each rule appears separately in sign-in logs, which should help with troubleshooting. Microsoft Graph and PowerShell support, together with configuration backup and recovery, are also important considerations when managing Conditional Access at scale.
Moving common assignments, conditions, and exclusions into a shared configuration should make related Conditional Access rules easier to understand and maintain. The concept makes sense. The real test will be whether policy plans can simplify mature deployments without introducing additional complexity. Experience with production-scale deployments will answer that question.
So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across the Microsoft 365 ecosystem. Subscribe to the Microsoft 365 for IT Pros eBook to receive insights updated monthly into what happens within Microsoft 365, why it happens, and what new features and capabilities mean for your tenant.