Conditional Access policy design: the failure modes the documentation leaves out

A Conditional Access policy is an if-then statement that Microsoft Entra ID evaluates on every sign-in, and every guide on page one will tell you that much. What they leave out is that policies now arrive in your tenant on their own and switch themselves on thirty days later, and that they sit underneath an MFA mandate whose exclusions Microsoft has stopped honouring. This guide treats Conditional Access policy design as an operations problem: what evaluates in what order, which exclusion you build before anything else, and where a correct looking policy set fails anyway.

How Entra evaluates a sign-in

Three rules from Building a Conditional Access policy on Microsoft Learn, last updated 24 March 2026, govern everything downstream. Get these wrong and the rest of the design is decoration, including whatever identity-centric Zero Trust design sits on top of it.

Assignments combine with AND. Microsoft states it plainly: “All assignments are logically combined using AND.” A policy scoped to the Finance group, on iOS, for Exchange Online fires only when all three are true. Most policies that “do not work” are policies whose conditions never all line up at once. A policy scoped to a dynamic group also inherits that group’s lag, which is how an Entra dynamic group that has stopped updating turns into a policy that quietly applies to the wrong people.

Policies also combine with AND. “Multiple Conditional Access policies can apply to an individual user at any time. In this case, all applicable policies must be satisfied.” Requirements accumulate rather than compete. One policy requiring multifactor authentication and another requiring a compliant device means the user needs both, and neither policy knows the other exists.

Block outranks everything. “If there’s a policy that is configured with the block grant control, enforcement stops here and the user is blocked.” There is no grant control anywhere in the tenant that overrides a block. This single line is why exclusions matter more than inclusions, and why the emergency access section below comes before the policy set rather than after it.

Microsoft also documents that “All policies are enforced in two phases”, which is worth knowing when a sign-in log entry and your mental model disagree.

The controls you can actually reach, as documented today:

The portal path, checked on 16 August 2026: Microsoft Entra admin center, then Entra ID, then Conditional Access. A Security Reader can view policies without being able to change them, which is the right role for anyone doing an audit.

Filter for devices is the condition that most often behaves differently from the way it was drawn, because it evaluates the device object rather than the sign-in, and an unregistered device has no object to evaluate. The mode and operator combinations that survive that, and the ones that quietly let devices past, are set out in why your Conditional Access device filter matches nothing.

The licence line, and the part of it that bites late

From the Microsoft Entra Conditional Access overview, last updated 27 April 2026: “Using this feature requires Microsoft Entra ID P1 licenses.” Microsoft 365 Business Premium customers can use Conditional Access as well. Risk-based policies are the exception, because they depend on Microsoft Entra ID Protection, which is a P2 capability. If you are still deciding where that boundary sits for your tenant, the Entra ID P1 vs P2 licence maths covers which population Microsoft obliges you to license, which is the part the feature tables leave out.

The clause worth pinning to the wall is what happens when those licences lapse:

“When the licenses required for Conditional Access expire, policies aren’t automatically disabled or deleted. This graceful state lets customers migrate away from Conditional Access policies without a sudden change in their security posture. You can view and delete remaining policies, but you can’t update them.”

Read that as an operations warning rather than a reassurance. Enforcement carries on, so nothing breaks and nobody notices. The lapse surfaces during an incident, when an administrator opens a policy to add an exclusion and finds that Save is unavailable. The failure mode is not loss of protection. It is loss of the ability to change protection at the exact moment you need to.

Emergency access accounts: the exclusion you build first

Nothing else in this guide is safe to deploy until this exists. Microsoft’s guidance in Manage emergency access accounts, last updated 5 June 2026, is specific enough to implement verbatim:

• “Create two or more emergency access accounts.” Two, so that a single locked, expired or compromised account is not the whole plan.
• They “should be cloud-only accounts that use the *.onmicrosoft.com domain and that aren’t federated or synchronized from an on-premises environment”. A break glass account that depends on your identity provider fails in the outage where you need it.
• “Exclude emergency access accounts from Conditional Access policies that block or restrict sign-in. Report-only policies don’t block access and don’t need to exclude emergency accounts.”
• Do it with a group. Microsoft suggests a dedicated security group named EmergencyAccess, excluded from every restrictive policy. Excluding individual accounts policy by policy is how one gets missed.
• “Use phishing-resistant authentication methods (FIDO2 security keys or certificate-based authentication) that are different from your normal admin accounts.” Passkey (FIDO2) is the recommended option.
• “In Microsoft Entra Privileged Identity Management, make the Global Administrator role assignment active permanent rather than eligible for your emergency access accounts.” Eligible means the account has to activate through PIM, and PIM activation is exactly the sort of thing that is unavailable during the incident.
• Monitor them. “Monitor sign-in and audit log activity from the emergency accounts and trigger notifications to other administrators.” An unmonitored break glass account is a backdoor with a nice name.
• Validate “at least every 90 days”, and “[r]egularly test (for example, every quarter) that emergency access accounts can sign in successfully with your current Conditional Access configuration”.

The last point is the one that gets skipped, and it is the one that decides whether the account works. An emergency access account is not a credential. It is a credential plus a policy exclusion plus an authentication method that still satisfies whatever Microsoft is enforcing this quarter. All three drift. Only the test catches it.

Which brings us to the change that broke a lot of documented break glass designs.

Mandatory MFA has already moved the baseline under you

Microsoft is enforcing multifactor authentication on its own administrative surfaces, independently of your Conditional Access policies. From Planning for mandatory multifactor authentication on Microsoft Learn, last updated 3 April 2026:

Three details decide how much work this creates for you.

Phase 2 applies to write operations only: “MFA enforcement will gradually begin for accounts that sign in to Azure CLI, Azure PowerShell, Azure mobile app, IaC tools, and REST API endpoints to perform any Create, Update, or Delete operation. Read operations won’t require MFA.” A reporting script that only reads is unaffected. A deployment pipeline running as a user account is not.

Workload identities are out of scope: “Workload identities, such as managed identities and service principals, aren’t impacted by either phase of this MFA enforcement.” The correct fix for a pipeline is to stop it running as a person, which is what you should have been doing anyway.

And the one that matters most here, quoted in full because people still design around the opposite assumption:

“Break glass or emergency access accounts are also required to sign in with MFA once enforcement begins. We recommend that you update these accounts to use passkey (FIDO2) or configure certificate-based authentication for MFA. Both methods satisfy the MFA requirement.”

Excluding your break glass account from every Conditional Access policy in the tenant no longer means it can sign in without MFA. Microsoft also states, of Conditional Access exclusions generally in this context, that “[i]f you configured exceptions or exclusions in the policy, they no longer apply”. There is no opt-out: “There’s no way to opt out. This security motion is critical to the safety and security of the Azure platform and is being repeated across cloud vendors.” The Phase 2 postponement route closed on 1 July 2026, which has now passed.

If your emergency access accounts still hold a long password in a safe and nothing else, they are decorative. Register a FIDO2 key on each one, store the keys separately, and test a sign-in this quarter.

The Microsoft managed policies that switch themselves on

This is the change that most third-party Conditional Access guides have not caught up with, and it changes what “my policy set” means. Microsoft now creates Conditional Access policies directly in customer tenants. From Microsoft-managed policies in Microsoft Entra Conditional Access, last updated 8 August 2026, the current set is:

• Block all high risk agents from accessing all resources (Preview)
• Block legacy authentication
• Block device code flow
• Multifactor authentication for admins accessing Microsoft Admin portals
• Multifactor authentication for all users
• Multifactor authentication for per-user multifactor authentication users
• Multifactor authentication and reauthentication for risky sign-ins
• Block access for high-risk users
• Require remediation for high-risk users
• Require phishing resistant authentication for admins, which is managed from the Microsoft 365 admin center rather than Entra

Not every tenant receives every policy. The risk-based ones target tenants with P2, and the per-user MFA one targets organisations with fewer than 500 per-user MFA users. What applies to everyone is the lifecycle:

“The policy is automatically created in your tenant in a Report-only state.” … “Microsoft enables these policies no less than 30 days after they’re introduced in your tenant if they’re left in the Report-only state.”

Customers are notified by email and Message center post two weeks before enablement, and “[i]n some cases, policies might be enabled faster than 30 days”. You can change the state and you can exclude identities, including your emergency access accounts, and Microsoft explicitly tells you to. You cannot rename or delete them. If you need more control than an exclusion list, the documented route is to duplicate the policy and manage your own copy.

Report only mode, and the four results people misread

Report-only is the correct way to introduce a policy, and Microsoft’s deployment guidance is to “[e]nable each policy in report-only mode for at least one week before enforcement”. From Conditional Access report-only mode, last updated 1 June 2026, the results you will see in the sign-in log are these:

The distinction that trips people up is Failure against User action required. A wall of Failure entries usually means a control the user cannot satisfy without help, such as a compliant device on an unmanaged machine. User action required usually means a prompt they would simply have answered. Treating the second as a blocker delays rollouts that were always going to be fine.

Two documented limits. Report-only “doesn’t enforce grant controls or session controls”, and policies scoped to User Actions cannot be evaluated in report-only at all, so that class of policy goes live untested unless you pilot it against a test group instead. And this warning, which produces support tickets from a mode that is supposed to be invisible:

“Policies in report-only mode that require a compliant device can prompt users on macOS, iOS, and Android devices to select a device certificate during policy evaluation, even though device compliance isn’t enforced. These prompts can repeat until the device is compliant.”

The documented mitigation is to exclude the Mac, iOS and Android device platforms from report-only policies that check device compliance, then add them back when you enforce.

A starting Conditional Access policy set

Microsoft’s deployment guidance, last updated 1 June 2026, is explicit that more policies is not better: “Minimize the number of Conditional Access policies” and “Creating a policy for each app isn’t efficient and makes managing policies difficult.” Group applications with the same requirements for the same users into one policy. The recommended naming convention encodes a sequence number, the resources, the response, who it applies to and when, giving names in the shape of CA01 - Dynamics CRP - Require MFA - Marketing - External networks.

The phased approach Microsoft publishes runs foundation first, then core authentication, then risk:

The foundation row hides a decision. Requiring phishing-resistant methods is done with the authentication strength grant control, which names the methods it will accept and blocks anyone who cannot produce one, and the population it blocks first is usually your guests. Conditional Access authentication strength sets out what each built-in strength accepts and the point at which it becomes unsatisfiable.

Two exclusions belong in the foundation phase rather than being retrofitted. Emergency access accounts, covered above. And service accounts, which Microsoft describes as “noninteractive accounts that aren’t tied to any specific user”. Note the asymmetry the docs record: “Calls made by service principals aren’t blocked by Conditional Access policies scoped to users.” A service principal is not covered by your user-scoped policies at all, whereas a user account being used as a service account is fully covered and will break. Those are opposite problems and they need opposite fixes.

On authentication strength, the three built-in strengths are Multifactor authentication, Passwordless MFA, and Phishing-resistant MFA, and custom strengths are supported. FIDO2 security key, Windows Hello for Business and multifactor certificate-based authentication satisfy all three. Microsoft Authenticator phone sign-in satisfies passwordless but not phishing-resistant. Temporary Access Pass satisfies plain MFA only, which is worth remembering before you require phishing-resistant strength on the same population you onboard with a TAP.

To see what a tenant actually has, including anything Microsoft added, read the policies rather than the portal:

# Lists every Conditional Access policy with its state and its user exclusions.
# Cmdlet and scope verified against Microsoft Graph PowerShell docs, 16 Aug 2026.
Connect-MgGraph -Scopes 'Policy.Read.All'

Get-MgIdentityConditionalAccessPolicy | Select-Object `
    DisplayName,
    State,
    @{n='ExcludedUsers'; e={ $_.Conditions.Users.ExcludeUsers -join ',' }},
    @{n='ExcludedGroups';e={ $_.Conditions.Users.ExcludeGroups -join ',' }}

Run that against your own tenant and compare the excluded-group column across every policy whose state is enabled. Any restrictive policy missing your EmergencyAccess group is a lockout waiting for a bad afternoon.

Named locations, and why IP is the weakest signal you own

Location is the condition people reach for first and trust too much. The documented limits, from Network assignment in Conditional Access, last updated 1 April 2026: “No more than 195 named locations” per tenant, “[n]o more than 2000 IP ranges per named location”, and “[o]nly CIDR masks greater than /8 are allowed when defining an IP range”. IPv6 is supported in CIDR notation.

Now the part that decides whether the signal is worth anything. When traffic passes through a cloud proxy or VPN, the address Entra evaluates is the proxy’s:

“The X-Forwarded-For (XFF) header, which contains the user’s public IP address, isn’t used because there’s no validation that it comes from a trusted source. This lack of validation could allow faking an IP address.”

So a trusted location is a statement about network path, not about who the user is. GPS-based country conditions are weaker still: Microsoft notes that “[u]sers can modify the GPS location as reported by iOS and Android devices”, that the Authenticator app therefore denies mismatched authentications, and that users “might receive prompts every hour”. Microsoft’s own recommendation is to reserve that control for “very sensitive apps where this behavior is acceptable”.

Two smaller traps. “Locations marked as trusted can’t be deleted without first removing the trusted designation”, which is a two-step cleanup people discover at the wrong time. And the legacy MFA trusted IPs list under multifactor authentication service settings “isn’t recommended”, accepts IPv4 only, and is a different mechanism from named locations despite looking like the same thing.

Use location to reduce friction, not to grant trust. Requiring phishing-resistant authentication everywhere and using a trusted location to relax sign-in frequency is a defensible design. Skipping MFA because the request came from an office range is not, and it has not been for years.

The limits nobody reads until they hit them

From the Microsoft Entra service limits and restrictions page, last updated 4 August 2026, two numbers matter for Conditional Access.

240 policies per tenant, across all policy states. Microsoft’s deployment guidance calls this a “hard limit of 240 policies per tenant across all policy states”, which means disabled and report-only policies count. Tenants that create a policy per application reach this, and the fix at that point is a consolidation project rather than a support ticket.

4,096 group memberships per user for policy evaluation, direct and indirect. Microsoft’s wording is that “[w]hen this limit is exceeded, policy enforcement might fail”. In a large tenant with nested dynamic groups this is reachable, and the symptom is not an error message, it is a policy that quietly does not apply to your most heavily grouped users. Those tend to be long-tenured staff with broad access, which is precisely the wrong population to miss.

One number in the other direction, which is a relief rather than a limit: a deleted policy can be “restored within the 30 day soft-delete period”. If someone deletes the wrong policy, do not rebuild it from memory.

The failure modes

The break glass account that cannot break glass. Excluded from every policy, password in a safe, never tested. Mandatory MFA now applies to it regardless of exclusions, so the password alone gets you an MFA prompt and no registered method. The account fails at the one moment it exists for. Fix: FIDO2 or certificate-based authentication on each emergency account, tested quarterly against the live policy set.

The policy you did not write, enabled on a schedule you did not set. A Microsoft-managed policy lands in report-only, the Message center post goes to a mailbox nobody reads, and thirty days later it is enforcing. Nothing about this is malicious and the policies are sensible, but “who changed the tenant” has an answer that is not in your change log. Fix: review the policy list monthly and route Message center to the identity owner.

Report-only prompting users. A compliance-checking policy in report-only makes macOS, iOS and Android users pick a device certificate, repeatedly, for a policy that is not being enforced. It reads as a fault in the sign-in experience and generates tickets against a change you told people would be invisible. Fix: exclude those platforms from report-only compliance policies, then add them back at enforcement.

The service account split. Migrating a script to a service principal to escape a Conditional Access block works, because “[c]alls made by service principals aren’t blocked by Conditional Access policies scoped to users”. That is a documented behaviour and also a gap: the workload keeps running and is no longer covered by the control you thought applied to it. Workload identity Conditional Access is a separate mechanism and needs its own policies. Escaping a block is not the same as being secure.

Silent non-enforcement at 4,096 groups. The policy is enabled, the user is in scope on paper, and enforcement “might fail”. Nothing turns red. This is the hardest failure in the list to detect, because your evidence of protection is the policy existing rather than the sign-in being evaluated.

Block by accident. Because block stops evaluation and outranks every grant, a policy scoped more broadly than intended, for instance to All users because a dynamic group was empty at creation time, locks out the tenant instantly. This is the scenario the exclusion group exists for, and the reason Microsoft’s rollback guidance is disable, then exclude, then delete, in that order.

The licence that expired quietly. Policies keep enforcing in the graceful state, so nothing alerts. You find out when you try to edit a policy during an incident and cannot save. Fix: track P1 and P2 entitlement as an availability dependency rather than only a cost line.

What I would do differently

I have not run a Conditional Access rollout across a production estate. My tenant is a lab with no enrolled devices, so everything above is documentation plus what the lab lets me reproduce, and I would rather say that than dress it up. What follows is judgement about where the documented design meets an organisation, and you should weigh it accordingly.

Build the exclusion group before the first policy, not after the first outage. The order in most guides is policies first, break glass mentioned near the end. Reverse it. Create EmergencyAccess, populate it with two cloud-only accounts holding FIDO2 keys, and make “is EmergencyAccess excluded” a checklist item on every restrictive policy you create thereafter.

Treat the Microsoft-managed policies as the baseline and design on top of them. The instinct when Microsoft creates policies in your tenant is to duplicate and disable so that you own everything. That doubles the policy count against a 240 limit and puts you on the hook for keeping pace with Microsoft’s security baseline by hand. Unless you need behaviour the exclusion list cannot express, leave them managed and spend the effort on the policies only you can write.

Be honest about what report-only proves. One week in report-only tells you about the sign-ins that happened that week. It says nothing about the quarterly auditor, the contractor who returns in November, or the service account that runs on the first of the month. Before enforcing, ask who signs in rarely, and go looking for them in the logs rather than waiting for them to find the policy.

Prefer fewer, broader policies. Microsoft says it, and the reason is the 240 ceiling plus human comprehension. A tenant with 30 policies can be reasoned about. A tenant with 180 cannot, and the second one is where contradictory exclusions accumulate until somebody adds a block that nobody can trace.

Put a date on your policy set. The whole reason this page carries a verification date is that half the Conditional Access advice online was correct when it was written. Mandatory MFA changed what an exclusion means. Managed policies changed who authors your tenant’s policies. Both landed inside eighteen months. Whatever you build, review it against the documentation twice a year, and write down when you last did.

For the wider identity design this sits inside, see Zero Trust architecture on Microsoft Entra ID. For the session control layer specifically, granular Conditional Access and session controls goes further into sign-in frequency and app enforced restrictions. If the policies you want depend on device compliance, the authorisation model underneath is covered in Entra ID centric RBAC on Azure, and if the licence question is the blocker, Microsoft 365 E3 vs E5 covers where P1 and P2 sit inside the suite SKUs.

If the device state your policies rely on comes from Microsoft Entra hybrid join, the synchronisation engine feeding it is on a clock: Entra Cloud Sync vs Connect Sync covers the 30 September 2026 service cut-off and what a cutover does to device objects.

If a policy in that set uses the network condition, the trust flag on the range carries a cost that is not visible in the policy blade: what Conditional Access named locations actually see covers the 195 ceiling, the effect on Identity Protection risk scoring, and why a country block never stops a password from being validated.

Conditional Access decides what a credential may do. It has no opinion at all on what the credential is, and that floor is set somewhere else: what Entra ID password protection does not block covers the five point scoring algorithm, the 1,000 term ceiling on the custom banned list, and the domain controller state in which every password is quietly accepted.

Every policy in that set behaves differently the moment a guest is in scope, and the configuration that decides how is not in the policy at all: cross-tenant access trust settings covers the three inbound claims your tenant refuses by default, why B2B collaboration guests are re-challenged while B2B direct connect users are blocked outright, and the AADSTS90071 error that sends the wrong administrator into the wrong tenant.

An authentication context requirement on a privileged role is a Conditional Access policy doing its job, right up to the moment the administrator who needs the role cannot satisfy it: why an Entra PIM activation delay is a token problem covers the within seconds claim Microsoft makes for the assignment itself, the 28 hour token a Continuous Access Evaluation session can hold, and the reason signing out beats waiting.

Last verified: 16 August 2026 against learn.microsoft.com.