Microsoft's NEW Conditional Access Policy Plans Explained

Microsoft just introduced Conditional Access Policy Plans, a new feature in Microsoft Entra, now in preview, that changes how we organize and manage Conditional Access policies.

If you've managed Microsoft 365 for any length of time, you've probably experienced the challenge of maintaining dozens of Conditional Access policies. Overlapping assignments, repeated exclusions, and long policy lists can make even simple changes difficult.

Policy Plans aim to simplify this.

What Are Conditional Access Policy Plans?#

Traditionally, every Conditional Access policy is configured independently. With Policy Plans, Microsoft introduces a new organizational layer that allows you to group related security rules under a common objective.

A Policy Plan consists of three main components:

1. Plan Details: The name, description, owners, and tags that define the security objective.
2. Shared Conditions: Optional identity assignments, resources, and conditions inherited by every rule in the plan.
3. Individual Rules: The actual security requirements, such as requiring MFA, compliant devices, or limiting sessions.

For example, you could create a Privileged Access plan containing three rules:

• Require phishing-resistant MFA for administrators
• Require compliant devices for administrators
• Limit administrative sessions

Instead of repeating administrator assignments and emergency access exclusions across three separate policies, you can define those shared settings once.

Importantly, each rule continues to be evaluated independently.

Policy Plans don't replace your existing Conditional Access policies. Standalone policies and plan rules are evaluated side by side, and every one that applies has to be satisfied. If you rebuild a policy as a plan rule, both will enforce until you disable the original, so validate the rule first, then turn the old policy off. Each rule shows up separately in sign-in logs, and you'll need the Conditional Access Administrator role to create or edit plans.

How I'd Organize Conditional Access Policies#

I maintain a T-Minus365 Conditional Access security baseline with 15 core security controls.

With Policy Plans, I'd organize those controls around security objectives:

• Identity & Authentication: MFA and authentication flow protection
• Device & Application Access: Device compliance and application restrictions
• Registration & Enrollment: Secure device and authentication method registration
• Privileged Access: Protect administrative accounts
• Guest & External Access: Control external identity access
• Identity Risk Protection: Respond to risky users and sign-ins

I'd keep geographic restrictions standalone during preview where immediate IP-based enforcement matters, and keep legacy authentication blocking standalone until the Client Apps issue below is resolved. (will talk about this more below).

One important distinction: Not every plan needs shared conditions. You can still configure identities, resources, and conditions independently within individual rules.

Five Things to Watch Out for During Preview#

After testing Policy Plans in my own environment, I discovered a few things worth knowing:

These are good reasons to test carefully before migrating production policies.

Download My Free Conditional Access Policy Plans Template#

I've also created a free T-Minus365 Conditional Access Policy Plans Blueprint to help you implement this in your own environment.

The Excel workbook includes:

• My 15 baseline security controls
• Recommended Policy Plans and individual rules
• Standardized Conditional Access naming conventions
• Suggested assignments, conditions, and grant controls
• A migration and validation checklist

Join the T-Minus365 Community and Get the Free Template (opens in new tab)

Managing Conditional Access Across Every Customer Tenant#

Policy Plans clean up Conditional Access inside one tenant. If you're an MSP, you have the same problem multiplied by every customer you manage, and plans don't help you keep 50 tenants consistent.

That's the problem I built CloudCapsule to solve. Instead of rebuilding the same Conditional Access policies tenant by tenant, you keep your baseline as templates in the CloudCapsule portal, with no golden tenant to maintain. Start from 100+ out-of-the-box policies or import the policies already running in any customer tenant, then deploy them across customers at scale.

Once they're deployed, CloudCapsule keeps watching for drift, so when an exclusion changes or a policy gets switched off in a customer tenant, you find out right away instead of during an incident.

Where to Start#

Policy Plans won't automatically make your environment more secure. But they can make Conditional Access significantly easier to organize, audit, and maintain over time.

My recommendation is to start small, validate your configurations in report-only mode, and migrate deliberately.

For more technical details, check out Microsoft's official Policy Plans documentation (opens in new tab).