Once you accept that Conditional Access is the real control plane, the next question is how to organize it, and this is where most tenants go wrong. Not because they pick the wrong controls, but because they never pick a structure at all. Policies get added one at a time, each one a reasonable response to a specific need, until the tenant holds forty of them and nobody can say with confidence what happens when a given user signs in from a given device. A framework is the thing that prevents that, and choosing or building one is a design decision worth making deliberately rather than arriving at by accretion.
There is no shortage of prior art. Microsoft ships its own managed Conditional Access policies now, turning them on in tenants automatically and enforcing them after a notice period. Claus Jespersen’s Conditional Access for Zero Trust framework laid out the persona model that most serious baselines still descend from. Community baselines package that thinking into importable form. Each of these is worth understanding, because the point of this article is not to sell you one but to give you the frame for evaluating any of them, including the one I eventually built and describe later in this phase.
What a framework is actually for
A Conditional Access framework is not a pile of good policies. It is a structure that makes the policies legible, so that six months later you or the next engineer can look at the tenant and understand its posture without reverse-engineering it one policy at a time. That legibility is worth more in practice than any individual control, because the failure mode of Conditional Access is not usually a missing policy. It is a tenant so tangled that no one dares change anything, and so it ossifies while the threat landscape moves.
The mechanism that delivers legibility is the persona model, and it is the one idea nearly every good framework shares. Rather than writing policies against individual users or ad hoc groups, you define a small number of personas that describe who someone is in the tenant. Administrators. Standard employees. External guests. Non-interactive service identities. Increasingly, autonomous agents. Each persona gets a coherent family of policies, and every identity belongs to a persona, so the question stops being what does this one policy do and becomes what does the tenant require of an administrator, which is a question with an answer. The persona model is a way of decomposing an unmanageable space into a few manageable ones, and its durability across a decade of framework designs is evidence that it works.
The naming convention is the documentation
Intune has no policy hierarchy to lean on, and Conditional Access is the same. There is no folder structure, no inheritance, no order of precedence you can read off the screen. What you get instead is a flat list of policies, and the only thing standing between that list and chaos is what you name them. A good framework encodes the policy’s entire intent in its name: the persona it applies to, the category of control, the applications and platforms in scope, and the control itself. Done well, the policy list becomes self-documenting, and you can read a tenant’s posture straight off the names without opening a single policy. Done badly, or not at all, every policy is a small mystery you have to open and decode, and forty small mysteries is a tenant nobody maintains.
This is the same argument I made about Intune configuration naming earlier in the series, and it is not a coincidence that it recurs. Both systems abandoned hierarchy in favor of a flat, identity-driven evaluation model, and both of them push the burden of structure onto the names as a result. Naming is not housekeeping in these systems. It is the load-bearing documentation, and a framework that does not take it seriously is not a framework.
What every baseline leaves you to decide
Here is the thing that took me a full audit of the available baselines to see clearly. They converge on the controls, and they largely agree on the persona structure, and then they all stop at the same place and hand you the same unsolved problems. What happens when someone needs an exception, and who watches that exception over time. How a brand-new user with no authentication methods gets their first credential without opening a window an attacker can climb through. What a personal, unmanaged device is actually allowed to do, as opposed to simply blocked or simply allowed. What to do with the service accounts that cannot answer an MFA prompt. And who looks at any of it a quarter later to confirm it still means what it meant on the day it was deployed.
None of those are policy questions, which is why a folder of policies never answers them. They are operating questions, and they are precisely the questions that determine whether a deployment stays secure or quietly rots. A baseline that ships thirty well-designed policies and treats onboarding, exceptions, the unmanaged device experience, and the review cadence as exercises for the reader has done the easy two thirds of the work and left the hard third, which is also the third where tenants actually get compromised. This is not a criticism of any particular baseline. It is a description of where the category as a whole draws its boundary, and understanding that boundary is the single most useful thing you can carry into evaluating one.
Designing for the exception first
If I had to compress framework design to one principle, it would be this: design for the exception before you design for the rule. Every weakness I have found in real tenants was an exception path that nobody planned. An exclusion group that outlived its reason. A service account shoved into an MFA exemption and forgotten. A device-enrollment workaround that became permanent. The policies themselves were usually fine. The tenant was compromised through the accommodations made around them.
So the strongest thing a framework can do is treat every exception as a governed object with an owner, a lifespan, and a review, rather than as a quiet edit to a group. A policy that does not plan its exceptions has planned its bypasses instead, because the exceptions will happen regardless, and the only choice is whether they happen inside a structure that watches them or outside one that does not. This is also the cleanest way to tell a mature framework from a merely correct one. The correct one gives you good policies. The mature one gives you good policies and a defined way to handle every case where the policy cannot apply, which is the case that will actually hurt you.
That principle, that a framework is an operating model and not a set of files, is the thing I could not find fully expressed in any of the baselines I evaluated, and it is the reason I ended up building my own rather than adopting one. The next article is that framework, laid out as a design paper: the persona and resource-tier structure, the governed exceptions, the onboarding that protects day one, and the operating cadence that keeps the whole thing true after the project is over. Read this article as the lens. Read that one as what I saw through it.
Continue with the VCIO CA Framework, the design paper for the framework this lens produced.
Conditional Access
‹ Previous: [CA 1] Conditional Access: The Real Control Plane
Next: [CA 2.1] Testing Conditional Access: What-If Analysis and Safe Rollout ›
