Conditional Access: a ten-policy baseline and the order to deploy it in

A Conditional Access baseline is about ten policies, built as eleven policy objects because the sign-in-risk control needs one object per risk level. What breaks a rollout is the order they are switched on in, not the wording of any single policy.

What the engine evaluates, and when

Conditional Access runs after first-factor authentication completes, which is why Microsoft's block-legacy-authentication guidance says the engine is not intended as a first line of defence. Several policies can match one sign-in, their grant controls combine, and every required control has to be satisfied before access is granted.

Two licensing facts bound everything below. Conditional Access requires Microsoft Entra ID P1, and the two risk-based policies require P2: the ID Protection licensing table marks sign-in and user risk policies as unavailable on Free and on P1. The deployment order comes from one published number: on the block-legacy-authentication page, Microsoft attributes more than 97 percent of credential-stuffing attacks and more than 99 percent of password-spray attacks to legacy authentication protocols. That is why CA01 goes first and alone.

Prerequisites

• Microsoft Entra ID P1 for every user in scope. P2 for CA05, CA05b and CA06.
• At least two emergency-access accounts, cloud-only, on the tenant's default onmicrosoft.com domain, neither federated nor synchronised from on-premises. Microsoft's emergency-access guidance is explicit about the domain: a break-glass account on a federated custom domain inherits the dependency it exists to survive, so if the identity provider is the outage, the emergency account is inside it.
• A passkey (FIDO2) or certificate-based credential registered on each emergency account before any policy is enforced. Microsoft's mandatory MFA enforcement covers the Azure, Entra, Intune and Microsoft 365 admin centers, and since 1 October 2025 also Azure CLI, Azure PowerShell and Resource Manager write operations. It has no exception for break-glass accounts and no opt-out, and it sits outside Conditional Access, so a policy exclusion does not reach it.
• Named locations for office egress addresses and for the countries the business actually operates in.
• An Intune device-compliance policy published, with at least one device already reporting compliant, before CA07 is created. Microsoft warns the compliant-device control will not function as intended without one.
• A security group, for example EmergencyAccess, holding those accounts and excluded by name from every enforced policy. The same inventory sits under Microsoft 365 tenant hardening.

The baseline: ten policies, eleven policy objects

Naming convention: CAxx-Audience-Action, where the number is deployment order only. Conditional Access has no policy precedence. One policy cannot carry two grants keyed to two risk levels, which is why CA05 and CA05b are separate objects.

CA03: name the fourteen roles, and target all resources

Microsoft's phishing-resistant MFA template for administrators names them, so there is no reason to write "the main admin roles" into a policy an auditor will read: Global Administrator, Application Administrator, Authentication Administrator, Billing Administrator, Cloud Application Administrator, Conditional Access Administrator, Exchange Administrator, Helpdesk Administrator, Password Administrator, Privileged Authentication Administrator, Privileged Role Administrator, Security Administrator, SharePoint Administrator, User Administrator. That template recommends phishing-resistant MFA on those roles at a minimum, and it targets All resources.

Scoping CA03 to the Microsoft Admin Portals resource instead is a staging shortcut with a gap worth naming. That application covers interactive access to the admin portals only, so an administrator holding a phishable method still reaches Microsoft Graph PowerShell, Exchange Online PowerShell, Azure CLI, Azure PowerShell and Resource Manager REST under whatever CA02 grants. If you stage that way, widen the scope in the same change window.

The built-in Phishing-resistant MFA strength accepts a FIDO2 security key, Windows Hello for Business or a platform credential, and multifactor certificate-based authentication. Nothing else.

CA05 and CA06: which detection sits on which axis

Leaked credentials is a user-risk detection in Microsoft Entra ID Protection, not a sign-in-risk detection, and it belongs behind CA06. Microsoft documents it as always high risk: a detection is emitted only after the discovered credential material is validated against the tenant's current password hashes.

Build CA06 on the Require risk remediation grant. Microsoft's current user-risk policy selects Require authentication strength automatically, applies a mandatory sign-in frequency of Every time, and covers password-based and passwordless users alike. The older Require password change control still exists under two constraints stated on the grant-controls page: it cannot be combined with any other control, and the policy carrying it must be assigned to All resources.

The sign-in-risk axis that CA05 consumes carries anonymous IP address, atypical travel, malicious IP address, unfamiliar sign-in properties, password spray, anomalous token, token issuer anomaly, verified threat actor IP and suspicious MFA authentication approval.

Two documented learning windows explain why the risk policies go last. Unfamiliar sign-in properties is disabled for new users during a dynamic learning period of at least five days; atypical travel has an initial learning period of the earliest of 14 days or 10 sign-ins. Blocking on a signal whose baseline has not been built produces false positives the tenant will blame on the whole programme.

CA08: guests are a cross-tenant setting before they are a policy

By default, Microsoft Entra does not trust MFA or device claims from another Entra organisation, so a guest is challenged in the resource tenant regardless of what their home tenant enforced. Trusting a home-tenant claim is an explicit inbound opt-in under cross-tenant access settings, and a per-partner decision. Requiring a compliant device from guests without that opt-in blocks every guest, because guest devices are not enrolled in your Intune. Microsoft flags one collision to pre-empt: where you trust MFA for external users, exclude them from the ID Protection MFA registration policy, or they can satisfy neither.

CA09: build on the control that still exists

The Require approved client app grant moved to a read-only state on 30 June 2026. New policies cannot use it and existing policies carrying it cannot be edited, though they keep enforcing while they remain enabled. Build CA09 on Require app protection policy, with one caveat: an app that does not support it blocks its users outright, so check the supported-client list before the enforcing wave.

Deployment order

1. Wave 0. Create all eleven in Report-only. Exclude the macOS, iOS and Android platforms from any report-only policy carrying a device-compliance check, for the reason under Side effects.
2. Wave 1. CA01 alone. Until legacy authentication is blocked, every later policy has a documented bypass route.
3. Wave 2. CA03, then CA02. Administrators first: smallest population, and the only population that can unblock itself.
4. Wave 3. CA04 and CA10.
5. Wave 4. CA07 and CA09, paced by Intune enrolment and compliance state.
6. Wave 5. CA05, CA05b and CA06, once the learning windows above have elapsed. CA08 waits on the cross-tenant trust decision.

Wave length is not a number anyone can hand you. Compute it from your own logs: for each policy in the wave, count the distinct users carrying a report-only failure result, subtract those the exclusions already cover, and divide the remainder by the remediations the team can close per working day. The largest quotient is that wave's length. If it exceeds the appetite for it, split the assignment by group.

Expected output

This audit only reads. It is safe to run against production before the first policy exists.

# Read-only Conditional Access baseline audit.
# Modules: Microsoft.Graph.Authentication, Microsoft.Graph.Identity.SignIns,
#          Microsoft.Graph.Reports
Connect-MgGraph -Scopes 'Policy.Read.All','Directory.Read.All','AuditLog.Read.All'

# Object IDs of the emergency-access accounts and of the group holding them.
$emergency = @(
  '00000000-0000-0000-0000-000000000001',   # break-glass 1
  '00000000-0000-0000-0000-000000000002',   # break-glass 2
  '00000000-0000-0000-0000-000000000003'    # EmergencyAccess group
)

$policies = Get-MgIdentityConditionalAccessPolicy -All

# 1. State, grant control and resilience posture of every policy.
$policies | Select-Object DisplayName, State,
  @{n='Grant';      e={ ($_.GrantControls.BuiltInControls) -join '+' }},
  @{n='Strength';   e={ $_.GrantControls.AuthenticationStrength.DisplayName }},
  @{n='Resilience'; e={ if ($_.SessionControls.DisableResilienceDefaults)
                        { 'DISABLED' } else { 'on' } }} |
  Sort-Object State, DisplayName | Format-Table -AutoSize

# 2. Enforced policies that do NOT exclude an emergency-access identity.
$policies |
  Where-Object { $_.State -eq 'enabled' } |
  Where-Object {
    $excluded = @($_.Conditions.Users.ExcludeUsers) +
                @($_.Conditions.Users.ExcludeGroups)
    -not ($emergency | Where-Object { $excluded -contains $_ })
  } |
  Select-Object DisplayName, State

# 3. Legacy-authentication sign-ins over the last 7 days, by user and protocol.
#    Filter server-side on time only, then bucket client-side. The Graph signIn
#    resource documents legacy clients as Exchange ActiveSync, IMAP, MAPI, SMTP,
#    POP and other clients, so 'Other clients' on its own misses most of them.
$legacy = @('Exchange ActiveSync','IMAP','IMAP4','MAPI','MAPI Over HTTP',
            'SMTP','Authenticated SMTP','POP','POP3','Other clients',
            'Exchange Web Services','Autodiscover','Offline Address Book')
$since = (Get-Date).ToUniversalTime().AddDays(-7).ToString('yyyy-MM-ddTHH:mm:ssZ')

Get-MgAuditLogSignIn -All -Filter "createdDateTime ge $since" |
  Where-Object { $_.ClientAppUsed -in $legacy } |
  Group-Object UserPrincipalName, ClientAppUsed |
  Sort-Object Count -Descending |
  Select-Object -First 25 -Property Count, Name

# 4. Same window, non-interactive sign-ins. Get-MgAuditLogSignIn reads the v1.0
#    endpoint, which returns interactive sign-ins only. Service-account IMAP and
#    authenticated SMTP traffic surfaces here and nowhere else.
$uri = 'https://graph.microsoft.com/beta/auditLogs/signIns' +
       "?`$filter=createdDateTime ge $since and " +
       "signInEventTypes/any(t: t eq 'nonInteractiveUser')"
(Invoke-MgGraphRequest -Method GET -Uri $uri).value |
  Where-Object { $_.clientAppUsed -in $legacy } |
  Group-Object userPrincipalName, clientAppUsed |
  Sort-Object Count -Descending |
  Select-Object -First 25 -Property Count, Name

On a tenant that has finished Wave 5, expect query one to list all eleven policy objects with State enabled and the Resilience column reading on for every row. Expect query two to return nothing: one row there is a lockout waiting for a bad Saturday. Expect queries three and four to trend toward zero after CA01 enforces, with any residue being Exchange ActiveSync from devices not yet migrated.

Queries three and four pull the whole seven-day window before filtering, so narrow the range first on a large tenant. Conditional Access collapses all of those client values into the two checkboxes CA01 ticks, Exchange ActiveSync clients and Other clients. Run both before Wave 1 to size the CA01 blast radius. For the settings outside this stack, the M365 Security Scorecard reads the same tenant more broadly.

Side effects

• Report-only policies requiring a compliant device prompt macOS, iOS and Android users to select a device certificate, and the prompt repeats until the device is compliant. Microsoft's remedy is to exclude those platforms from report-only device-compliance policies.
• Conditional Access supports built-in directory roles only. Administrative-unit-scoped and custom roles are not enforced, so an estate that delegated administration through custom roles keeps a gap CA03 will never close.
• Calls made by service principals are not blocked by Conditional Access policies scoped to users, so an exclusion group named "service accounts" on CA02 protects nothing that was at risk. Scope service principals with Conditional Access for workload identities, which needs Workload Identities Premium licences and offers Block as its only grant control.
• Require multifactor authentication and Require authentication strength cannot be set in the same policy. The built-in Multifactor authentication strength is the equivalent of the older control.
• Policies requiring MFA or terms of use can prevent a user from completing registration or consent. For guests, Microsoft names the two application IDs cross-tenant settings must allow: 0000000c-0000-0000-c000-000000000000 for the Microsoft App Access Panel and d52792f4-ba38-424d-8140-ada5b883f293 for Microsoft Entra Terms of Use. For internal users, seed registration with a Temporary Access Pass, which satisfies the Multifactor authentication strength but neither the passwordless nor the phishing-resistant strength.

Rollback

Per-policy rollback is one field. Set state to disabled, or back to enabledForReportingButNotEnforced to keep collecting data without enforcing. Both are reversible and both take effect on the next token request.

Rollback during a Microsoft Entra outage is a different mechanism. Resilience defaults are enabled automatically on all policies, and during an outage the Microsoft Entra Backup Authentication Service reissues access tokens for existing sessions, which Microsoft notes covers more than 90 percent of authentications to Entra ID. It serves neither new sessions nor guest users, and cannot re-evaluate group or role membership, risk, country location or authentication strengths in real time.

The emergency-access account is therefore the rollback path for a policy misconfiguration and only a partial one for a service outage. Build the second path in advance: contingency Conditional Access policies, created and left disabled, that can be enabled during an outage to restore access for critical users. Validate the emergency accounts at least every 90 days by signing in and performing an administrative task.

Limitations

This baseline is Microsoft Entra ID only. It says nothing about on-premises Active Directory, AD FS, or a third-party identity provider fronting the tenant. Microsoft's guidance is to keep on-premises emergency access separate from cloud emergency access so neither depends on the other.

It stops applying without Entra ID P1. Below that tier the alternative Microsoft names is security defaults: a single switch in place of eleven policy objects. Without P2 there is no CA05, no CA05b and no CA06, and the stack loses its only adaptive layer.

CA04 is the weakest policy in the set. Country blocking reduces the volume of noise in the logs. Residential proxies and VPN egress defeat it as a control, and it is no substitute for the risk-based policies it is cheaper than.

Access decisions here are made at token issuance. Continuous Access Evaluation extends that window and makes tokens subject to instant revocation events instead, which changes the timing assumptions of any policy whose condition can flip mid-session.

Ten enabled policies are evidence for an assessor. They are not a certification or a control description. An auditor asking about identity controls wants the exclusion register, the review cadence and the emergency-access drill record, and the policy export is the smallest part of that answer.

Last verified 2026-07-28. Every policy definition, grant control, licence tier and retirement date above was checked against the Microsoft Learn pages listed in the sources, including the Microsoft Graph signIn resource for the legacy client values in query three.