Conditional Access Policy Plans - A First Look: Dub or Flop?
Over the years, Conditional Access has been constantly expanding, though most changes have come in the form of new user actions, conditions, controls, etc. Today, however, we'll be looking at something a little different: the next transformation of Conditional Access.
This preview feature might change more than simply requiring us to create another policy or modify a few existing ones. I'll be going over what the feature is, what it does, what it solves, and as a specialty, I'll even treat you to my thoughts on the whole thing.
By the end of this post, I'm hoping to answer one simple question: Is this feature a dub or a flop?
Conditional Access Policy Plans is currently in preview and therefore subject to change.
Without any further ado, let's jump in!
Table of Content
What are Conditional Access Policy Plans?
In its most basic form, Policy Plans allow us to group related Conditional Access rules together with reusable settings and conditions.
Let's think about it like a house with a bunch of different rooms. If we think about a Conditional Access policy as the lock on a door, with each lock requiring different keys, Policy Plans can be thought of as the house the rooms live in, where the same code-based lock is used across each door, together with the specific lock on every room's door.
In practice, this means that a Policy Plan can contain shared assignments, conditions, and exclusions, which are inherited by the individual rules within the plan. Each rule can then have its own specific conditions and controls, depending on what we're trying to achieve.
Policy Plans exist as an addition to the original/existing policies, meaning they aren't replacing our current Conditional Access policies. Instead, the rules within a plan are evaluated alongside our existing policies, each independently.
It's also possible to migrate from "legacy" policies to plans through a new migration wizard. Pretty neat, though the success rate has been a bit hit-or-miss for me so far.
What does policy plans solve?
As organizations become more complex, introducing application identities, agent identities, devices, locations, etc., combined with more and more features in Conditional Access and an evolving threat landscape, it's become clear that policy sprawl and technical debt are becoming a management headache.
Some organizations have tens, or even hundreds, of Conditional Access policies built up over time, often with overlapping assignments, duplicated exclusions, and similar conditions across multiple policies.
As Conditional Access has evolved, so has the way we go about utilizing the product, with condensing and combining policies getting higher and higher on the priority list.
Policy Plans directly help with this by grouping policies with the same intent together, reusing conditions and exclusions, and decreasing the administrative overhead through inherited settings.
Rather than having to update the same exclusion across 20 different policies, we can make the change once at the plan level and have it automatically apply to every rule within that plan.
All of this doesn't necessarily mean fewer individual enforcement rules, but it does mean fewer places where we need to maintain the same configuration, decreasing the overall headache of maintaining our policies.
Policy Plans: Beneath the Surface
While shared conditions and inheritance sound great, there's something important to understand about how they work.
Settings defined at the plan level aren't something individual rules can override.
For example, if we exclude our emergency access accounts at the plan level, those exclusions will automatically apply to every rule within that plan. Individual rules can add their own exclusions, but they cannot remove the exclusions inherited from the plan.
So, if we exclude group A at the plan level, then exclude user 1 and user 2 at the policy level, then the actual exclusion for the policy would be user 1, user 2 AND group A.
That's great for consistency, but it also means we need to be careful about what we configure at the plan level.
A single change to shared targeting or exclusions could affect every rule within the plan. In other words, we're reducing the number of places we need to make changes, but potentially increasing the impact of getting one wrong.
It's also worth remembering that Policy Plans don't fundamentally change how Conditional Access evaluates access. Every rule is still evaluated independently, just like our existing policies, and all applicable requirements must still be satisfied.
In the scenarios where you've got both policies, and policy plans, both will be evaluated equally by the same motor before granting access.
As for migration, Microsoft has made the process fairly safe by leaving the original policies untouched and creating the migrated rules in a disabled state. From that state, we can validate the new rules using Report-only mode and sign-in logs before doing the cross-over.
There are also some preview-specific limitations to consider, especially around location-based conditions, which Microsoft covers in the official documentation.
So while the idea is fairly straightforward, I believe we'll need to give some thought to how we actually structure our plans, rather than just throwing every policy we have into one singular policy plan.
The Toughtful Corner
While this is still in preview, and we've seen other features stay in preview limbo for years without moving forward (time-based controls), or get deleted from existence (memberOf), all of this might change.
Though with that said, and with all of the above in mind, I believe Policy Plans are a huge step in the right direction. Not necessarily for a stronger Conditional Access setup, but for the administration, automation, hygiene, and future of Conditional Access.
I'm particularly interested in what this could mean for the way we design Conditional Access strategies going forward. Rather than thinking exclusively in terms of individual policies, we might start designing around security objectives instead of personas, with related rules and shared conditions grouped together right from the get go.
I'm looking forward to seeing how this changes the way we work with Conditional Access, it's a new era for sure!
Conclusion
So, is Conditional Access Policy Plans a dub or a flop?
For me, it seems to be a dub.
Not because it introduces some revolutionary new security control, but because it addresses a problem that has been growing for years: managing the increasingly complex Conditional Access configurations we've built.
I don't believe Policy Plans will magically solve policy sprawl or poor Conditional Access design. If anything, they'll make it even more important to think about how we structure our policies and shared conditions.
But the potential is definitely there, and I believe this is a step in the right direction.
As always, the mandatory bad joke - this time inspired by the spooky season!
Why don't skeletons fight each other?
Because they don't have the guts for it! 😎
For now, it's a cautious dub from me. The real test will be how well Policy Plans hold up when we start moving our messy, real-world Conditional Access configurations into them.
Time will tell!
Comments