Microsoft's design principles

Deny-by-exception, the 240-policy limit, and why a group-scoped policy restricts nobody.
Published by Urbannerd Consulting · Reviewed 2026-07-29

Microsoft's Conditional Access design principles

Source: Plan your Microsoft Entra Conditional Access deployment

· doc date 2026-06-01 · retrieved 2026-07-28

These are Microsoft's own stated recommendations. Where they differ from benchmark guidance, see

benchmark guidance-vs-microsoft-reconciliation.md.

The single most important concept: Conditional Access is deny-by-exception

**Access tokens are issued by default if a Conditional Access policy condition doesn't

trigger an access control.**

Microsoft's worked example, which the agent should reuse because it corrects a near-

universal misconception:

• Policy: Users = FINANCE GROUP · App = PAYROLL APP · Control = Require MFA
• User A (in Finance) → must do MFA. As intended.
• User B (not in Finance) → **gets an access token and reaches the Payroll app with no

MFA at all.**

A policy scoped to a group protects that group. It does not restrict anyone else. To

actually restrict access you need a second, explicit Block policy:

• Users = All users, exclude FINANCE GROUP · App = PAYROLL APP · Control = Block

Agent rule: whenever a user describes a policy scoped to a group or a set of users and

believes it restricts an application, ask what blocks everyone else. This is one of the

highest-value corrections available and it is Microsoft's own guidance, not opinion.

Apply a policy to every app

Ensure that every app has at least one Conditional Access policy applied.

Microsoft prefers policies targeting All resources so newly onboarded applications are

covered automatically without editing policies.

Their own caveat, verbatim in substance: be careful combining Block with *All

resources* in a single policy — it can lock out admins, and **exclusions can't be

configured for important endpoints such as Microsoft Graph**.

Minimise the number of policies — there is a hard limit

• 240 policies per tenant, counting every state: On, Off and Report-only.
• Scaling means consolidating, not adding.
• A single policy is a JSON document with a size limit. Long GUID lists can hit it.

Remedies: use groups/roles instead of individual users; use filter for applications

instead of naming apps individually.

Agent rule: report-only policies count against the 240 limit. Organisations that leave

old report-only experiments lying around are consuming budget. Worth raising in policy

review as a hygiene finding.

Filter for applications

Recommended over listing apps individually. Benefits Microsoft states: scales to any number

of apps, groups apps with similar requirements, reduces policy count, reduces editing

errors, and works around policy size constraints.

Exclusions Microsoft explicitly recommends

1. Emergency access / break-glass accounts — to prevent lockout from policy

misconfiguration.

1. Service accounts and service principals, such as the Entra Connect Sync account.

Critical technical detail on the second one:

**Calls made by service principals aren't blocked by Conditional Access policies scoped

to users.**

So a user-scoped policy never applied to service principals in the first place. Service

principals need Conditional Access for workload identities. And where service accounts

appear in scripts or code, Microsoft's recommendation is to **replace them with managed

identities** rather than to exclude them permanently.

Agent rule: when a user asks to exclude a service account, first establish whether it

is a user account or a service principal. If it is a service principal, the exclusion is

pointless — the policy was never applying. That is a genuinely useful diagnosis.

Governance at scale

Microsoft's stated practices:

• Naming and ownership conventions. CA policies have no built-in owner attribute, so

encode ownership in the policy name (e.g. a team prefix) and keep an out-of-band registry

mapping policy → responsible admin or team.

• Audit and consolidate regularly — remove redundant and conflicting rules.
• Conditional Access Optimization Agent (Microsoft Security Copilot) can analyse

existing policies, find coverage gaps and suggest consolidation. Requires Security Copilot

with provisioned SCUs plus Entra ID P1 — not available in every tenant.

• Conditional Access Insights and Reporting workbook for tenant-wide impact. Requires

Entra ID P1 and a Log Analytics workspace receiving sign-in logs.

• What If tool to simulate a sign-in and see which policies apply.
• Protected actions — require fresh MFA or another grant control before anyone can

create, modify or delete a Conditional Access policy. This is the control that protects

the policies themselves.

• Policy-as-code — manage via the Graph conditionalAccessPolicy API and Microsoft

Graph PowerShell, with source control and CI so changes are reviewable, testable and

reversible.

Agent opportunity: protected actions and the policy registry are rarely implemented and

directly address the "policies with unclear ownership" finding.

Naming standard

Microsoft says a policy name should convey, without opening it:

1. A sequence number
2. The cloud apps it applies to
3. The response (the control)
4. Who it applies to
5. When it applies (the conditions)

The sequence number exists so admins can refer to "policy CA01" in conversation.

Contingency policy naming

For disabled/report-only policies held in reserve for an outage:

EMnnn - ENABLE IN EMERGENCY: [Disruption][i/n] - [Apps] - [Controls] [Conditions]

Microsoft's own example:

EM01 - ENABLE IN EMERGENCY: MFA Disruption [1/4] - Exchange SharePoint: Require Microsoft Entra hybrid join For VIP users.

ENABLE IN EMERGENCY goes at the start so the policy stands out in the list, and the

[i/n] sequence tells the admin what order to enable them in during an incident.

Guest configuration

For external organisations you have a relationship with, you can **trust MFA, device

compliance and hybrid device claims from the guest's home tenant** via cross-tenant access

settings for B2B collaboration. This is the proper answer to "guests can't satisfy our

device policy", rather than blanket exclusion.

Caveat Microsoft flags: there are specific considerations for how B2B users interact with

Entra ID Protection.

Geographic blocking — Microsoft's preferred shape

Rather than enumerating blocked countries, Microsoft recommends: build a named location

listing the countries you do expect sign-ins from, then create a **block policy that

excludes that allowed list**. Less overhead, especially for organisations in a small number

of countries.

Be sure to exclude your emergency access accounts from this policy.

Prerequisites and roles

• Entra ID P1 or P2 (or trial). P2 required for ID Protection risk in CA.
• Security Reader — least privilege to read CA policies and configuration.
• Conditional Access Administrator — to create, modify or restore soft-deleted policies.
• Microsoft recommends activating these via PIM just-in-time.
• A non-admin test user and a group containing them, for validation before real rollout.

Security defaults interaction

Security defaults and Conditional Access are not meant to be combined. Creating CA

policies prevents enabling security defaults. CA gives the same protection as security

defaults but with granularity.