Conditional Access without the spreadsheet of regret.

Why most CA deployments rot

Conditional Access is one of the highest-leverage controls in a Microsoft tenant. It is also one of the easiest to leave in a state where nobody on the team can tell you, at a glance, why a policy exists, what it excludes, or whether it is still doing what it was named for.

We have inherited tenants with forty-two policies, eighteen of which had names like BLOCK_RISKY_SIGNINS_v3_FINAL_USE_THIS_ONE. The pattern that follows is what we put in place when we own the rebuild.

A naming convention that survives

Every policy name follows a four-part pattern, separated by hyphens. Read left to right, the name should answer: who is this for, what state are they in, what do we require, and what does this enforce?

// <Persona> - <Condition> - <Requirement> - <Action>
CA001 - All Users - Any Location - Require MFA - Grant
CA014 - Admins - Untrusted Network - Require Compliant Device - Grant
CA022 - Guests - SharePoint Access - Require Terms of Use - Grant
CA047 - All Users - Legacy Auth Protocols - N/A - Block

The numeric prefix is non-negotiable. It gives you a stable handle that survives renames, lets you reference policies in change tickets, and makes the audit log readable without a translation layer.

The break-glass exclusion group

Every block-action policy gets the same exclusion group: a single, named, monitored group called CA-BreakGlass-Excluded. Two cloud-only accounts live there. They have FIDO2 keys in a sealed envelope in the office safe and a separate notification rule that pages the on-call when they sign in.

This is the part most teams skip, and it is the part that determines whether you can ever roll out a tight policy. If you cannot get back in, you cannot tighten anything. The exclusion group is the door.

What we audit weekly

• Membership of the break-glass group has not changed.
• The break-glass accounts have not signed in (unless we triggered a drill).
• Every block policy targets CA-BreakGlass-Excluded as an exclusion. Every one.

The exclusion group is not a workaround. It is the floor that lets you raise the ceiling.

Make every policy carry its evidence

The Microsoft portal does not let you attach a description longer than 280 characters to a policy, which is by design and exactly the wrong design. We solve this with a parallel artifact: a single Markdown file in the tenant's ops repo, one section per policy, named ca-policies.md.

Each section has a fixed shape:

• Why — the business or compliance reason this exists, in two sentences.
• Owner — the named human (not "IT") who can answer questions about it.
• Last reviewed — a date. We rotate the entire file on a 90-day cadence.
• Linked artifacts — the change ticket, the policy export JSON, the test plan.

This file is the source of truth. The portal is a deployment target. When the two diverge, the file wins, and the next deployment reconciles.

The Friday-afternoon test

The whole pattern is built around one question: could a brand-new analyst, on a Friday afternoon, with no context, walk into your tenant and figure out why CA037 is the way it is?

If the answer is yes, you have a CA deployment that will outlive you. If the answer is no, you have a spreadsheet of regret, and the next outage is going to be expensive.

We have used some version of this pattern in roughly thirty tenants. It is not novel. It is just enforced. That is the whole trick.