Architecture
Conditional Access policies that survive year two
Every tenant starts with a clean policy set. What turns it into an unauditable pile of exclusions, and the structure that prevents it.
Microsoft
The failure mode is not technical
Conditional Access rarely fails because a policy was written badly. It fails because eleven policies were written well, over three years, by four people, and nobody can now say what the combined effect is.
The symptom is recognisable. Somebody asks whether contractors can reach SharePoint from an unmanaged device, and answering it requires reading every policy in the tenant. At that point the policy set has stopped being a control and become documentation of past decisions.
The structure that holds up
Name policies so the set reads as a sentence
A convention that encodes persona, target and control, applied without exception. CA001-Global-AllApps-RequireMFA tells you what it does. NewPolicy2 does not, and there is one in almost every tenant.
Build around personas, not around requests
Internal, external, admin, service account, guest. Policies target a persona group. A new requirement modifies a persona, it does not add a twelfth policy.
Exclusions live in one named group per policy
Never an individual user on the policy itself. A named group is reviewable, an inline exclusion is invisible until someone reads the JSON.
Report-only before enforcement, every time
No exceptions, including for policies that are obviously safe. The one you were sure about is the one that locks out the mailbox migration service account.
Two break-glass accounts, excluded and monitored
Excluded from all Conditional Access, credentials stored offline, and alerted on every sign-in. Untested break-glass is not break-glass, so sign in with them on a schedule.
What a policy set degrades into
The shape of the drift, not measured data. It matches what these tenants look like when reviewed.
- Accumulated exclusions40
- Overlapping policies25
- Orphaned policies20
- Legacy auth allowances15
An argument about how these sets decay, offered as such.
The review that catches all four
Once a quarter, export the policy set and answer three questions in writing. Which policies have exclusion groups larger than they were last quarter. Which policies have not matched a sign-in in ninety days. Which policies would still be written the same way today. It takes an afternoon and it is the only thing that reliably stops the drift.
What to do with a set that has already drifted
Do not rebuild it in place. Build the new persona-based set alongside the old one in report-only mode, compare the outcomes against real sign-in data, then cut over and disable the old policies rather than deleting them. Keeping them disabled for a month makes rollback a toggle rather than an incident.
The temptation is to fix the worst three policies and stop. That leaves you with a hybrid of two structures, which is harder to reason about than either.
The verdict
Personas, named exclusion groups, and a quarterly review
The structure is what makes the set auditable. Any individual policy can be good and the whole still be unmanageable without it.
Do not start by tightening controls on a drifted set. Understand what the current set actually does first, in report-only, or you will lock out something you did not know depended on an exclusion.
Disclosure. Some links on this site are affiliate links. Scoring weights are published before any programme is joined, and commission is never a ranking input. Full policy, and the method behind this guide.