Conditional Access Baseline Policies Every Microsoft 365 Tenant Needs in 2026

Every Microsoft 365 tenant should run a baseline of roughly eight to ten Conditional Access policies — block legacy authentication, require MFA for all users, require phishing-resistant MFA for admins, require compliant or managed devices, block device code flow, sign-in-risk and user-risk policies, session controls, guest MFA, and a break-glass exclusion group — deployed in report-only mode first, piloted with a ring group, then enforced. This guide gives you that named set, the safe rollout order, the licensing reality, the two enforcement changes that landed in June and July 2026, and the production gotchas.

What is a Conditional Access baseline policy set?

Conditional Access (CA) is the policy engine in Microsoft Entra ID that evaluates signals — user, device, location, application, risk — after first-factor authentication and decides whether to allow, block, or grant with conditions such as MFA or a compliant device. Microsoft Learn is explicit that CA is enforced after first-factor authentication and is not intended as a frontline defence against denial-of-service attacks.

A "baseline" is the minimum opinionated set of policies every enterprise tenant should run. Microsoft's own deployment guidance is to keep policies as broad as possible to avoid coverage gaps, to design an "audience matrix" of personas, and to build anti-lockout protection before enforcing anything. This article gives you a concrete named baseline, the licensing reality, the safe rollout order, the 2026 changes most vendor blogs under-serve, and the "what breaks in production" detail. It is the enforcement-side companion to our Conditional Access gaps guide.

Do I need a licence for Conditional Access? (P1 vs P2)

Conditional Access requires Microsoft Entra ID P1 at minimum. Microsoft 365 Business Premium, E3 and E5 all include P1. Risk-based policies (the sign-in-risk and user-risk conditions) require Microsoft Entra ID P2, because they depend on Microsoft Entra ID Protection. Microsoft Learn states plainly that risk-based Conditional Access policies require Microsoft Entra ID Protection, which is a P2 feature.

Tenants with no premium licences cannot use custom CA; they fall back to Security Defaults, a free, binary on/off baseline that enforces MFA registration for all users, requires MFA for privileged roles, and blocks legacy authentication — but cannot be customised, scoped, or excluded. For a mid-sized enterprise, Security Defaults is a stop-gap, not a destination. (See which Microsoft 365 plan includes P1 if you are still choosing a SKU.)

Note the licensing churn through 2026: Microsoft repackaged identity licensing (including new SKUs for AI-agent identities and an Entra Suite / M365 E7 bundle) and raised commercial Entra pricing on 1 July 2026. Conditional Access for workload identities (single-tenant service principals) requires a separate Microsoft Entra Workload ID Premium licence — Microsoft Learn confirms it is a standalone product not included in other premium plans. One licence in the tenant unlocks the feature for eligible workload identities; managed identities and multi-tenant/third-party SaaS apps are out of scope.

The baseline policy set (named, numbered)

Below is a concrete baseline for a Microsoft-heavy enterprise tenant. Use a consistent naming convention so policies self-document in the portal and in exports — a workable scheme is CANNN - [Persona] - [Control] - [Target] - [State], for example CA001 - Global - Block Legacy Auth - All Apps - ON.

Notes on the set:

• CA002 vs CA003. You cannot use the "Require multifactor authentication" grant and the "Require authentication strength" grant together in the same policy — Microsoft Learn notes the built-in MFA authentication strength is equivalent to the Require MFA grant control. Keep them in separate policies.
• CA003 phishing-resistant strength accepts Windows Hello for Business, FIDO2 security keys, and Microsoft Entra certificate-based authentication (multifactor). Pre-register admins for a phishing-resistant method before you enforce, or you will lock them out. Microsoft now publishes a template, "Require phishing-resistant MFA for admin roles," making this a defensible baseline expectation.
• CA005/CA006. "Require approved client app" retired on 30 June 2026 (see below); the replacement device-context grant for mobile is Require app protection policy, backed by an Intune app protection (MAM) policy.
• CA007/CA008 require P2. Microsoft Learn recommends keeping sign-in risk and user risk in separate policies — do not combine sign-in-risk and user-risk conditions in the same Conditional Access policy.
• Add a workload identity CA policy (location/risk restrictions on service principals) only if you have licensed Workload ID Premium.

Microsoft-managed Conditional Access policies (do these count?)

Microsoft auto-creates a set of Microsoft-managed Conditional Access policies in eligible tenants, deployed in report-only state. As of mid-2026, the current set includes multifactor authentication for admins accessing Microsoft admin portals (covering 14 highly privileged roles), MFA for all users, MFA for per-user-MFA users (tenants with fewer than 500 such users), MFA and reauthentication for risky sign-ins (P2, guests excluded), block access for high-risk users (P2), block legacy authentication, block device code flow, and — in preview — block all high-risk agent identities from accessing resources.

Key operational facts from Microsoft Learn:

• Microsoft enables these policies no less than 45 days after they are introduced in your tenant if they are left in report-only, and notifies customers by email and Message Center 28 days before enabling. (Older community posts citing a 90-day window are out of date.)
• You can exclude identities (do exclude your break-glass accounts) and change the state (report-only / on / off). You cannot rename or delete them — for deeper changes, duplicate the policy and edit the copy.
• Managed policy display names are prefixed with "Microsoft-managed:".

Treat these as a safety net, not a substitute for your own baseline. Overlapping enabled MFA policies are fine — when multiple policies apply, all must be satisfied — but decide deliberately whether to leave each managed policy on, off, or duplicated to avoid untracked drift.

The 2026 Conditional Access changes vendors under-serve

Two enforcement changes landed in mid-2026 that materially change behaviour. Both are verified against Microsoft Learn, the Microsoft Entra blog, and the M365 Message Center archive.

1. Baseline scopes / "All resources" exclusion enforcement — 15 June 2026

Historically, when a CA policy targeting All resources (formerly All cloud apps) had one or more resource exclusions, sign-ins from client apps requesting only OIDC or a limited set of directory scopes (openid, profile, email, offline_access, User.Read) bypassed enforcement entirely. Microsoft closed this loophole. Per Message Center MC1223829, enforcement began on 15 June 2026 — a date that slipped from an earlier 27 March 2026 timeline and a briefly-listed 13 May 2026. Rollout is progressive over several weeks, with full deployment in place worldwide by mid-August 2026.

You control this via the Baseline scopes settings (aka.ms/BaselineScopesSettingsUX): enable enforcement, disable enforcement, or customize behavior per policy. If you have not changed the baseline scopes settings, enforcement is enabled automatically over approximately several weeks. The practical risk: Azure CLI and similar clients that requested only User.Read and were silently skipping MFA will now be challenged — and non-interactive scripts may fail with no clear error.

2. "Require approved client app" grant retirement — 30 June 2026

The Require approved client app grant control retired on 30 June 2026 (slipped from an earlier March 2026 date, per MC1220751). After retirement the control moves to a read-only state: admins can no longer create new policies or edit existing ones that use it, though they can still disable or delete existing policies. Critically, after that date the grant is ignored during evaluation — a policy relying only on it grants access without applying the intended restriction, with no automatic fallback.

Migrate to Require app protection policy: add both grants with "Require one of the selected controls" during transition, validate in report-only, then drop the retired grant. App protection policies deliver the same data-loss protection but verify a live Intune app protection policy rather than checking against Microsoft's fixed approved-app list.

3. Related 2026 movements to know

• Mandatory MFA, Phase 2. MFA enforcement for Azure resource management via Azure CLI, Azure PowerShell, the Azure mobile app, IaC tools, REST APIs and the Azure SDK began rolling out 1 October 2025 (Phase 1 for the Azure/Entra/Intune portals completed March 2025; the Microsoft 365 admin center reached hard enforcement 9 February 2026). Read operations remain exempt; workload identities (managed identities, service principals) are not in scope, but user-based service accounts running automation are and will break unless migrated to workload identities. The postponement window for Phase 2 closed 1 July 2026 — Microsoft has stated no further postponements are granted after that date. Rollout is still gradual per tenant; verify status under Entra ID → Overview / Properties.
• Device code flow in Security Defaults. From 1 July 2026, all new Entra tenants block device code flow as part of Security Defaults.
• SMTP AUTH Basic Auth. Behaviour is unchanged through December 2026; at the end of December 2026, SMTP AUTH Basic Authentication is disabled by default for existing tenants (admins can re-enable) and unavailable by default for new tenants. Microsoft will announce a final removal date in the second half of 2027.

Do I still need to block legacy authentication in 2026?

Yes. Even though Microsoft disabled Basic Authentication for most Exchange Online protocol endpoints (EWS, EAS, IMAP, POP3, remote PowerShell) in October 2022, SMTP AUTH was not disabled at that time and remains active unless explicitly blocked — and the staged SMTP AUTH deprecation does not complete until 2027. A CA policy blocking legacy-authentication clients (Authenticated SMTP, plus the "Other clients" bucket) still blocks live attack vectors in 2026. Keep CA001. Note that certificate-based authentication carried over legacy protocols is still treated as legacy auth and will be blocked by such a policy.

Break-glass / emergency access accounts in 2026

This is the single most important anti-lockout control, and Microsoft's guidance has evolved. Per the Microsoft Learn "Manage emergency access accounts" page (updated June 2026):

• Create two or more emergency access accounts.
• They should be cloud-only (*.onmicrosoft.com), not federated or synced from on-premises.
• Assign the Global Administrator role permanently (active, not PIM-eligible).
• Use passwordless, phishing-resistant methods. Microsoft explicitly recommends Passkey (FIDO2) (marked "Recommended") or certificate-based authentication if you already have a PKI. This is the important shift: because mandatory MFA now applies even to break-glass accounts, the old "exclude from all MFA" model no longer works — the account must carry a strong registered method that satisfies MFA.
• Exclude emergency access accounts from Conditional Access policies that block or restrict sign-in. Note the current, precise wording: report-only policies do not block access and do not require an exclusion. The phishing-resistant method protects the account; the exclusion prevents a misconfigured blocking policy from locking you out during the exact emergency the account exists for.

Practically: create a security group (e.g. sg-ca-emergency-exclusion), add both accounts, and exclude that group from every blocking/restricting policy including the Microsoft-managed ones. Alert on any sign-in from these accounts (Entra ID → Monitoring). Some teams keep one account fully excluded and give the second a dedicated policy requiring phishing-resistant MFA as a "less-emergency" fallback. Pairing this with Entra PIM for just-in-time admin access is how you remove standing privilege everywhere except these two deliberate accounts.

Safe rollout order (report-only → pilot → enforce)

Do not enforce anything on day one. Follow this sequence:

• 1. Build break-glass first. Two cloud-only FIDO2 Global Admins, excluded via group, alerting configured, credentials in a physical safe (not a password manager). Nothing else happens until this exists.
• 2. Create every policy in report-only mode. Report-only evaluates policies against real sign-ins and logs the would-be result without affecting users. Microsoft recommends observing report-only for at least one week per policy before enforcement.
• 3. Analyse with the What If tool and sign-in logs. The What If tool simulates a given user/app/condition and shows which policies would apply (and flags any lingering classic policies). Capture both interactive and non-interactive sign-ins over a period that covers normal business use. Microsoft cautions a simulated run does not replace an actual test in a properly configured environment.
• 4. Pilot with a ring group. Move a small pilot group into enforcement first, expand to broader rings, then all users. Ring rollout is essential for phishing-resistant MFA (CA003), device compliance (CA005) and session controls (CA009), which carry the highest breakage potential.
• 5. Enforce, then monitor. Flip report-only to On per policy, watching sign-in logs and help-desk volume between each.
• 6. Back up your policies. Export CA policies to JSON via Microsoft Graph PowerShell using Get-MgIdentityConditionalAccessPolicy (least-privilege delegated scope Policy.Read.All; cmdlet ships in the Microsoft.Graph.Identity.SignIns module). Keep this as a config backup and for change control — see our Microsoft Graph PowerShell guide for the connect-and-export pattern. Policy-as-code backups are also exactly the timestamped evidence an ISO 27001 or SOC 2 auditor will ask for.

Portal path (verify current wording — Microsoft renames these): Microsoft Entra admin center → Entra ID → Conditional Access → Policies. Some training content still references the older Protection → Conditional Access route; both reach the same blade. Least-privilege role to create/edit is Conditional Access Administrator.

What breaks in production (the real gotchas)

• User-based service accounts caught by Phase 2 MFA. Any automation running Azure CLI/PowerShell/REST/IaC under a user identity breaks now that Phase 2 is live and the postponement window closed on 1 July 2026. Migrate to workload identities (managed identities / service principals), which are out of scope for the MFA mandate. The OAuth 2.0 ROPC (username/password) grant is incompatible with MFA and deprecated.
• The Entra Connect sync account. Directory sync uses a service account; Microsoft's session-control guidance explicitly lists the Microsoft Entra Connect Sync account as one to exclude from interactive-style policies.
• Hybrid Exchange and mail-flow connectors. Multifunction printers/scanners doing "scan to email" via SMTP AUTH, and line-of-business apps sending mail, will break as Basic Auth is phased out — inventory these before December 2026 and move them to OAuth. Watch for 550 5.7.30 Basic authentication is not supported for Client Submission.
• Autopilot / device-enrolment chicken-and-egg. A "require compliant device" policy can block the very enrolment that makes a device compliant. Device state cannot be evaluated during device-code OAuth flows and the compliant-device grant is not supported there — use Require MFA for those flows and scope enrolment carefully.
• Guest / B2B access. External users often lack phishing-resistant methods; scope admin-strength policies to exclude guests and give guests their own MFA policy (CA010). The managed risky-sign-in policy explicitly does not include guest users.
• Teams Rooms / shared devices and device code flow. Blocking device code flow tenant-wide can break Teams Rooms, IoT and smart-TV sign-ins. Because of protocol tracking, a session that started with device code flow can stay flagged on later refreshes and be blocked even on a different flow. Exclude resource accounts and the Device Registration Service where needed, audit exceptions, and inventory usage in sign-in logs before enforcing.
• The "All resources + exclusions" surprise (June 2026). As above, apps that quietly bypassed MFA via baseline scopes now get challenged; scripts may fail silently. Review the Baseline scopes setting and your exclusion lists.
• CAE + strict location enforcement. With Global Secure Access, non-Microsoft resources under CAE do not see the original source IP, so strict location enforcement can block users who are actually inside a trusted range. Do not enable strict location enforcement on IP-location policies targeting non-Microsoft resources unless Source IP Restoration supports the traffic.
• Approval bottlenecks. If you gate admin roles behind PIM approval with no active approvers, you can lock out tenant administration entirely — one reason break-glass accounts hold permanent Global Admin.

Where token protection, CAE and Global Secure Access fit

• Continuous Access Evaluation (CAE) is auto-enabled as part of CA for supporting services (Exchange Online, SharePoint Online, Teams) and re-evaluates sessions near-real-time on critical events (password reset, disablement, elevated risk, network-location change). Leave it on; disabling it is a session-control option but rarely necessary.
• Token protection (device-bound sign-in session tokens) is generally available on Windows but in preview on iOS/iPadOS and macOS, supports native apps only (not browsers), for Exchange Online, SharePoint Online and Teams (plus Azure Virtual Desktop and Windows 365 on Windows). Pilot on admins in report-only and flag the Apple platforms as preview in any change record.
• Global Secure Access adds the Compliant Network condition, which pairs with CAE to force instant re-authentication and counter token replay. It is powerful but licensed separately and can be cost-prohibitive for smaller tenants.

A staged rollout plan

• Stage 1 — this week (anti-lockout foundation). Confirm two cloud-only FIDO2 break-glass Global Admins exist, are excluded via a dedicated group from every blocking policy (including Microsoft-managed ones), and trigger a sign-in alert. If you are still on Security Defaults with P1/P2 available, plan the migration — but do not disable Security Defaults until your baseline is built in report-only. Threshold to proceed: both break-glass accounts validated end-to-end with a passkey.
• Stage 2 — weeks 1–3 (build and observe). Create CA001–CA010 in report-only. Check MC1223829 and MC1220751 in your Message Center, review your "All resources" policies for exclusions against the June 2026 baseline-scopes change, and migrate any "Require approved client app" policies to "Require app protection policy." Observe report-only for at least one week per policy and analyse with What If and sign-in logs. Threshold to enforce: no unexpected blocks for legitimate users/apps in report-only logs.
• Stage 3 — weeks 3–6 (pilot then enforce). Enforce block-legacy-auth (CA001) and admin phishing-resistant MFA (CA003) first, after confirming 100% admin passkey registration. Ring-roll device compliance (CA005), MAM (CA006) and session controls (CA009). Enable risk policies (CA007/CA008) only if you hold P2, keeping sign-in and user risk in separate policies.
• Stage 4 — ongoing (governance). Export policies to JSON monthly via Graph PowerShell for change control. Review exclusion lists quarterly (stale exclusions are the main way a baseline silently degrades). Re-inventory user-based service accounts and SMTP AUTH senders ahead of the December 2026 Basic Auth default-disable. Trigger to revisit: any new Message Center CA notice, any managed-policy auto-enable notice (you get 28 days), or a help-desk spike after enforcement.

A note on verification

Time-sensitive facts here were checked against Microsoft Learn, the Microsoft Entra blog, and the M365 Message Center archive as of 1 August 2026. Rollouts are gradual and per-tenant: the 15 June 2026 baseline-scopes enforcement and Phase 2 MFA deploy progressively, so your tenant's actual state may lag the published date — always confirm your own Message Center (MC1223829 for baseline scopes; MC1220751 for the approved-client-app retirement) and tenant status before making changes. Token protection on iOS/iPadOS/macOS and the "block all high-risk agents" managed policy are in preview and may change. Microsoft has repeatedly moved these dates, so re-check before quoting one externally, and validate the live managed-policy list in your own tenant (entries prefixed "Microsoft-managed:").

Frequently asked questions

How many Conditional Access policies should I have?

There is no fixed number, but a typical enterprise baseline is around 8 to 12 broad policies. Microsoft advises keeping policies as broad as possible to avoid coverage gaps rather than creating many granular ones. The named set in this guide (CA001–CA010) is a solid starting point: block legacy auth, require MFA for all users, phishing-resistant MFA for admins, device compliance, app protection for mobile, risk-based policies where you hold P2, session controls, and guest MFA.

What is the difference between Security Defaults and Conditional Access?

Security Defaults is a free, all-or-nothing baseline for tenants without premium licences: it enforces MFA registration, requires MFA for admins, and blocks legacy auth, with no customisation, scoping or exclusions. Conditional Access (Entra ID P1 and above) gives granular, scoped, conditional control including exclusions and device, location and session controls. You cannot run both at once — moving to Conditional Access means disabling Security Defaults, which is why you build the CA baseline in report-only first.

Should break-glass accounts be excluded from all Conditional Access policies?

Exclude them from policies that block or restrict sign-in, to prevent lockout. They must still have a phishing-resistant method (FIDO2/passkey) registered, because mandatory MFA now applies to them and the old "exclude from all MFA" model no longer works. Report-only policies do not block access and do not need an exclusion. Put both accounts in a dedicated security group and exclude that group from every blocking policy, including the Microsoft-managed ones.

Do I still need to block legacy authentication if Basic Auth is deprecated?

Yes. SMTP AUTH was not disabled in the 2022 Exchange Online change and is not disabled by default until the end of December 2026, with final removal announced in the second half of 2027. Third-party apps can also still request legacy scopes. Keep a block-legacy-authentication policy (CA001); certificate-based authentication carried over legacy protocols is treated as legacy auth and blocked by such a policy too.

What replaces "Require approved client app"?

Require app protection policy, backed by an Intune app protection (MAM) policy. The old grant retired on 30 June 2026 and is ignored during evaluation after that date, so a policy relying only on it silently grants access without the intended restriction. Migrate by adding both grants with "Require one of the selected controls," validating in report-only, then removing the retired grant.

Does Conditional Access require P1 or P2?

Microsoft Entra ID P1 is the minimum for custom Conditional Access and is included in Microsoft 365 Business Premium, E3 and E5. P2 is required only for risk-based policies — the sign-in-risk and user-risk conditions — because they depend on Microsoft Entra ID Protection. You can run the whole baseline except CA007 and CA008 on P1 alone.