A Conditional Access baseline policy set

A sequenced set of policies to deploy, in the order that keeps prerequisites ahead of impact.
Published by Urbannerd Consulting · Reviewed 2026-07-29

Baseline policy set — the design the agent proposes

Every recommendation traces to a benchmark guidance control in

. Where this file goes beyond benchmark guidance, it

says so.

Step zero: check for Microsoft-managed policies

Before designing anything, ask whether the tenant already has Microsoft-managed policies.

Microsoft creates these automatically in eligible tenants, in report-only, and **enables them

no less than 45 days later** unless the admin sets them to Off (28 days' notice by email and

Message center). See .

Consequences for baseline design:

• Half of the proposed baseline may already exist. Duplicating it is a Medium finding.
• A customer who "hasn't started yet" may be weeks from enforced MFA on Microsoft's schedule.

Leaving a managed policy in report-only is not deferral — Off is deferral.

• Managed policies need break-glass exclusions too, and are not covered by whatever process

the customer applies to their own policies.

Conditional Access is deny-by-exception

A policy scoped to a group protects that group. It does not restrict anyone else — an access

token is issued by default when no policy condition triggers a control. To actually restrict

an application you need a second, explicit Block policy for everyone outside the intended

group. Microsoft states this directly; see .

Structural principles (apply before any specific policy)

1. Mind the tenant limit. 240 policies per tenant, counting On, Off and Report-only.

A benchmark guidance-aligned baseline is 10–14, so this only matters when reviewing a large existing

estate — but stale report-only experiments do consume the budget.

1. One security outcome per policy. Never bundle. Separate policies combine as AND,

which is what you want; controls inside one policy combine as AND or OR, which is

where designs go wrong.

1. The AND/OR trap. Within a policy you choose Require all or Require one of. MFA

and device compliance in one policy with "require one of" means a compliant device

satisfies it without MFA. Correct construction is two policies:

(Require MFA) AND (compliant OR hybrid joined). This is benchmark guidance's central point

and the most valuable single correction the agent makes.

1. Break-glass excluded from everything, always.
2. Report-only first, minimum one week, review sign-in logs, then enforce.
3. All resources, not selected apps, for the MFA policies — scoping to selected apps

leaves the admin portals and Azure Service Management API reachable for reconnaissance.

1. Never all-administrators-excluded. Excluding the admin population from CA to "avoid

lockout" inverts the security model.

1. Trusted locations are never the sole control.

Baseline — E3 / P1 (Business Premium, E3)

Deploy in this order. Order is not arbitrary: prerequisites first, lowest blast radius

first, highest user impact last.

Policy 8 requires a Temporary Access Pass policy alongside it. Without TAP, new hires

and users with replaced devices cannot register and cannot be onboarded. Never propose 8

alone.

Policies 7 and 8 require Intune compliance policies to exist first, plus benchmark guidance

(unassigned devices marked not compliant). Setting 4.1 and enforcing 7 in the same change

window can lock out every device with no assigned compliance policy.

Additions at E5 / P2

Both require an MFA registration path first — a user with no registered method is blocked,

not challenged, and needs admin recovery.

Mixed licensing: if only part of the population holds P2, scope 11 and 12 to a group

containing exactly the licensed users. A risk policy scoped to All users in a partly

licensed tenant is a design error.

Level 2 hardening — only after Level 1 is enforced

Present these as a later phase, never in the initial baseline. Gate on: L1 enforced,

break-glass tested, usability impact accepted.

Beyond benchmark guidance — Microsoft-recommended, cite Microsoft not benchmark guidance

From and

:

Also available, not benchmark guidance-backed:

• Application-enforced restrictions for unmanaged browser access (limited web session)
• Conditional Access App Control session policies (requires Defender for Cloud Apps)
• Terms of use as a grant control for external users
• Authentication context for step-up on sensitive actions
• Filter for devices and filter for applications (Microsoft prefers the latter over

naming apps individually — it scales and avoids policy size limits)

• Workload identity Conditional Access for service principals (separate licensing)
• Continuous access evaluation review
• Protected actions — require fresh MFA before anyone can create, modify or delete a CA

policy. This protects the policies themselves and is rarely implemented.

• Contingency policies held in report-only for outage scenarios — see

05-rollout-and-rollback.md. Nothing in benchmark guidance covers this and almost nobody does it.

Prerequisites Microsoft names that are easy to miss

• Cross-tenant access settings can trust MFA, device compliance and hybrid claims from a

partner's home tenant. This is the correct answer to "guests can't satisfy our device

policy" — better than blanket exclusion.

• **Application Proxy apps set to Passthrough preauthentication cannot be governed by

Conditional Access at all.** Change to Microsoft Entra ID preauthentication first.

• Custom controls do not satisfy the MFA claim requirement. A tenant relying on one

believes it has MFA coverage and does not. Migrate to external authentication methods.

• ADAL bypasses Conditional Access, CAE and token protection. Support ended 30 June 2023.

If a policy appears not to apply to an application, ADAL is a prime suspect.

Sizing the baseline to the organisation

Standard exclusion set — and how to talk about it

Exclusions the agent may propose, each with the risk stated:

Never propose: excluding all administrators; excluding a group that ordinary Group

Administrators can modify (benchmark guidance warning); permanent exclusions with no owner or

review date; excluding "All users" from anything.

Naming

Policies must be named so their purpose is readable without opening them. See

.