Conditional access is a policy, not a prayer

Conditional accessdefinitionRules evaluated at each sign-in that look at conditions such as user, device or location, and then allow, block or demand more proof. policies decide, on every sign-in, who gets into everything you run. In most tenants they're still edited by hand, in production, with no history and no test. The control guarding your front door deserves at least the engineering discipline you give a config file. Put it in version control, stage the rollout and rehearse the rollback. Anything less is hoping the last admin clicked the right box.

We've argued before that zero trust is a proof obligation: every access decision is a claim you should be able to evidence. Conditional access is where that gets mechanical, since the policies are the claims. This note is about keeping them provable while you change them, which mostly comes down to three disciplines.

A tenant's CA configuration should live in version control, exported as code and deployed through review, so nobody has to reconstruct it from memory after an incident. Every change gets a diff, an author, a reviewer and a reason, and every past state can be restored. After any access incident someone asks what changed, and what the policy said at the time. A portal edit history can't answer that. A git log makes it trivial. Policy-as-codedefinitionKeeping policies in version control as files and deploying through review. That way each change is tracked and can be undone. also kills the classic driftdefinitionWhen a live configuration slowly wanders away from what you intended, often through emergency edits nobody tracked. failure, where the emergency exclusion added at 2 a.m. quietly becomes permanent because nothing tracked it. Exclusions deserve the same rigor. Each one carries a named owner, a written justification and an expiry date, and gets reviewed on a schedule, because an exclusion list that only ever grows is a policy quietly repealing itself. If a firewall change needs a peer review, the rule set that gates your identity provider needs one more.

No policy should enforce on day one. Entra’s report-only modedefinitionA setting where the policy runs against real sign-ins and logs what it would have done. Nobody actually gets blocked. evaluates a policy against real sign-in traffic and logs what it would have done. That makes it a staging environment for access decisions, fed by production load. Run new policies there for a full business cycle, not a quiet weekend: month-end batch jobs, the quarterly finance crunch and that one legacy client that can’t satisfy a device claim all need to appear in the would-be-blocked data before enforcement. Then read the results like a test report. Would-be blocks against service accounts mean you’ve found automation that authenticates like a human; would-be blocks against an executive’s unmanaged tablet mean a conversation is cheaper now than a lockout later. Enforce only when the projected impact matches the intended impact. That match is the evidence the policy is correct.

# require-compliant-device: staged enforcement
policy: require-compliant-device  // v7, in git
phase 1: report-only · all users · 30 days · review would-be blocks
phase 2: enforce · pilot ring (IT + volunteers)
phase 3: enforce · staged rings → all users
excluded: break-glass ×2 · alarmed on any use
rollback: revert to v6 · rehearsed · < 5 min
✓ lockout-rate alert armed before every phase

The worst CA failure is self-inflicted: a policy that locks out the administrators who could fix it. Engineering the blast radiusdefinitionHow many people or systems a single bad change can affect before it is caught. prevents it. Roll out in rings, starting with a pilot group that includes the people who wrote the policy and then moving through staged cohorts, so a bad interaction burns one team and the tenant stays up. Keep at least two break-glass accountsdefinitionEmergency admin accounts excluded from normal access policies. You only use them when everything else has failed, and you watch them closely. excluded from every conditional access policy. Secure them with long random credentials in a vault and alarm them so loudly that any use triggers an immediate investigation. An exclusion nobody watches is a backdoor. Then rehearse the rollback. Know which version you revert to, who is authorized at 3 a.m., and how long propagation takes, and measure that last one rather than guessing. Sign-in failure telemetry with alerting on lockout spikes closes the loop. With that in place you hear about a lockout from your alerts first, and the burning help desk just confirms it.