Conditional Access at Scale: Consolidating Policy Sprawl into a Framework

At one engagement I inherited more than forty Conditional Access policies, accreted over years, several disabled, two contradictory, and none documented. We consolidated them into a compact, governance-aligned framework. The method is repeatable and it is mostly not technical.

Policy sprawl is a governance failure

Sprawl happens because policies are created per incident, per project, or per auditor comment, with no naming convention and no design authority. Each policy is individually defensible; the set is unreviewable. And an unreviewable policy set fails in the dangerous direction - gaps hide in the intersections.

Design the framework before touching a policy

• Define personas - a small, finite set: standard users, privileged users, external guests, service and workload identities, break-glass. Every human and non-human principal maps to exactly one.
• Define access contexts - managed compliant device, unmanaged device, high-risk sign-in, legacy protocol, trusted location if you still need it.
• Write the decision matrix - personas by contexts, with the required control in each cell: block, MFA, phishing-resistant MFA, session limits. This one-page matrix is the artefact executives can review and auditors can test against.
• Adopt a naming convention - every policy name encodes persona, context, and control. If a policy cannot be named within the convention, it does not belong in the framework.

Migrate with report-only as your safety net

Build the new policy set in report-only mode alongside the legacy set, and let the sign-in logs prove equivalence or surface deltas. Move personas across in waves, never disabling a legacy policy until its replacement has demonstrably matched or exceeded its coverage. Keep break-glass accounts excluded, tested, and monitored - the framework should assume its own failure mode.

Keep it small forever

The steady state should be a policy count you can hold in your head. New requirements are met by amending the matrix through design governance, not by minting policy number forty-one. When an exception is genuinely needed, it gets an expiry date and an owner - exceptions that cannot expire are requirements you have not yet designed for.

The payoff is real: administration effort drops, audit responses become table lookups, and most importantly you can finally answer the question every CISO eventually asks - “what exactly happens when a contractor signs in from an unmanaged laptop?” - in one sentence.