Conditional Access baselines that survive contact with users

Conditional Access is the enforcement point for cloud identity. It is also, in my experience, the single easiest way to cause a total outage in a Microsoft 365 tenant, because a policy applies to everyone the moment you save it and there is no staged deployment unless you build one.

Everything below is about building that staging yourself.

Requirements: what to establish before writing a policy

Know what your sign-ins actually look like. Not what you assume. Before writing anything, look at the sign-in logs for a representative period and answer: which applications are in use, which legacy authentication protocols are still being used, which sign-ins come from service accounts, and which come from locations or devices you did not expect. Every one of those is a future exclusion or a future incident.

Know your licensing position. Conditional Access requires Microsoft Entra ID P1 for the core capability. Risk-based conditions — sign-in risk and user risk — require P2. Designing a baseline around risk conditions you are not licensed for wastes the design.

Have emergency access accounts that work. Two of them, cloud-only, excluded from every policy, with credentials stored offline and monitored for use. This is not optional and it is not something to arrange afterwards. The detail is in emergency access accounts, and I would not save a first policy without them.

Decide who owns exceptions. Every baseline generates exception requests within a week. If there is no named owner and no review cycle, the exclusion groups grow until the baseline means nothing.

Design: the policies worth having

I would build a baseline from a small number of policies with clearly separated intent. Policies that do several things at once are difficult to reason about and impossible to troubleshoot.

Block legacy authentication. Protocols that cannot present a second factor are how password spray succeeds. This is the highest-value single policy in the set, and it is the one most likely to break something, because legacy protocols are usually still carrying a multifunction device, an application integration or a mail client nobody has inventoried. Report-only first, always.

Require multifactor authentication for administrators. Scoped to privileged directory roles. Small population, highest value, and the natural place to start enforcing.

Require multifactor authentication for all users. The broad policy. This is where the exclusion design does its work.

Require compliant or hybrid-joined devices for access to core data. Scoped to the applications that hold the data you care about. This is a larger programme than it looks, because it depends on device management being in good order first.

Require phishing-resistant authentication for administrators. Using the authentication strength control rather than a generic multifactor requirement. Sequence this after passkey registration is established for that population.

Block or restrict by risk, if you are licensed for it. Sign-in risk and user risk conditions, with the response proportionate to the risk level rather than blocking everything.

Design: the parts people get wrong

Exclusions are structural, not incidental

Build every policy with an exclusion group from the start, even when it is empty. Adding an exclusion during an incident is much harder than populating one you already have.

Exclude by group, not by individual user. A policy with named users in its exclusion list becomes unmaintainable, and nobody can audit it.

The exclusions you will actually need:

• Emergency access accounts, from every policy without exception.
• The service accounts and workload identities that cannot present a second factor. Each one should have a compensating control — a named location restriction, or a move to a workload identity with its own policy — and a review date.
• A small, owned, reviewed exception group for genuine business cases.

Guest and external access is a separate decision

“All users” includes guests. A policy requiring a compliant device applied to all users will block every external collaborator, because their devices are not managed by you. Decide explicitly what applies to guests and scope accordingly.

“All cloud apps” is broader than it reads

It includes the applications used to register and manage credentials. A policy requiring a compliant device for all cloud apps can prevent someone registering the credential they need to become compliant. Test the enrolment path, not just the steady state.

Report-only is the deployment mechanism

Report-only mode evaluates the policy against real sign-ins and records what would have happened, without enforcing. It is the only safe way to deploy a Conditional Access policy into an organisation you do not have perfect knowledge of — which is all of them.

Deployment: the sequence

1. Create emergency access accounts and verify they sign in. Test them, do not assume.
2. Create every baseline policy in report-only mode, with exclusion groups populated.
3. Wait through a full business cycle. A week catches the weekly processes; a month catches month-end. The long tail of surprises lives in the batch jobs and the integrations that run monthly.
4. Read the report-only results per policy, and specifically the sign-ins that would have been blocked. Every one is either a legitimate exception to design for, or exactly the thing you meant to block.
5. Enable one policy at a time, starting with the administrator multifactor policy — small population, high value, fast feedback.
6. Enable the broad policies last, and prefer a phased scope: pilot group, then department, then all users. Conditional Access has no built-in ring deployment, so the rings are group membership you manage.
7. Legacy authentication last of all, or at least last among the broad policies, because it has the widest blast radius and the least predictable dependencies.

Between each enablement, leave enough time to hear about a problem. Enabling five policies on a Friday afternoon gives you five simultaneous variables and no way to attribute a failure.

Validation

Use the What If tool for specific combinations before enabling — a named user, a named application, a device state — and confirm the result matches your intent.

Watch the sign-in logs after each enablement, filtered on failures with a Conditional Access result. This is where you see the reality, and where a mistake shows up within minutes rather than at the service desk within hours.

Verify the negative case. Confirm that a sign-in which should be blocked actually is. A baseline that blocks nothing is a baseline that is not working, and it is surprisingly common for a policy to be scoped to an empty group.

Test emergency access again after the baseline is live. The whole point of those accounts is that they work when everything else does not, and that claim needs periodic evidence.

Operations

Review exclusions on a schedule. Exclusion groups grow, and each member is an account that your baseline does not protect. A quarterly review with the owner, removing anything whose justification has lapsed, is the minimum.

Treat policy changes as changes. Export the configuration, keep it in version control if you can, and record who changed what. Conditional Access has no built-in change history that tells you why.

Re-run the report-only exercise when your environment changes materially — a new major application, a merger, a shift in how people work. The baseline was designed against a picture of sign-ins that will drift.

Rollback

Set the policy to report-only, or off. That is the rollback, and it is fast — which is precisely why emergency access accounts matter: you need an administrator who can sign in to perform it.

The failure case worth planning for is a policy that blocks the administrators who would disable it. It is entirely possible to lock every administrator out of a tenant with one policy. Emergency access accounts, excluded from everything and tested, are the answer, and there is no other one that does not involve raising a support case.

Verification and limits

Report-only behaviour, licensing requirements for risk-based conditions, the scope of “all cloud apps”, guest handling and the What If tool were checked against current Microsoft documentation on 20 September 2026. The rollout sequence and exclusion design are my own practice.

No policy was deployed to a tenant for this article. Conditional Access changes take effect immediately and tenant-wide: use report-only, enable one policy at a time, and confirm tested emergency access before saving anything. Licensing and available controls change, so confirm both against current documentation when you design.

References

• What is Conditional Access?
• Conditional Access report-only mode
• Plan a Conditional Access deployment
• Conditional Access What If tool