Conditional Access Baseline Policies for Microsoft 365 (2026)

Short answer: A sensible 2026 baseline is seven policies built from Microsoft’s own templates: block legacy authentication, require MFA for admins, require MFA for all users, require a compliant or hybrid-joined device for admins, block unknown device platforms, and (with Entra ID P2) sign-in risk and user risk policies. Exclude two break-glass accounts from all of them, create every policy in report-only mode first, and back the set up as JSON with Microsoft Graph PowerShell. Conditional Access needs Entra ID P1 (included in Microsoft 365 Business Premium, E3 and E5); risk-based policies need P2.

Applies to Microsoft Entra ID P1 or P2 (Microsoft 365 Business Premium, E3, E5)

Commands checked against the official documentation (linked below) on 7 October 2026; not yet run on our lab servers.

Before you start: licences, security defaults and break-glass accounts

Licensing

• Entra ID P1 is needed for Conditional Access. It is included in Microsoft 365 Business Premium, Microsoft 365 E3 and E5, and is sold standalone.
• Entra ID P2 is needed for sign-in risk and user risk conditions (ID Protection). It is included in Microsoft 365 E5 and in the Microsoft Defender Suite add-on for Business Premium.
• Business Basic and Business Standard include only Entra ID Free. Those tenants should keep security defaults on instead; see our Microsoft 365 business plans comparison.

Security defaults

Security defaults and Conditional Access do not mix. Microsoft states that organisations replacing security defaults with Conditional Access policies must turn security defaults off. Build and test your policies in report-only mode first, then switch security defaults off and the policies on in the same change window, so the tenant is never without MFA.

Break-glass (emergency access) accounts

Create these before your first policy. Microsoft’s guidance:

• At least two cloud-only accounts on the .onmicrosoft.com domain, not synced or federated.
• Permanently assigned Global Administrator (active, not PIM-eligible).
• Phishing-resistant sign-in, such as FIDO2 security keys or passkeys, different from your normal admin methods. Mandatory MFA for admin portals applies to these accounts too.
• Excluded from every Conditional Access policy that blocks or restricts access. Put them in one group, for example CA-Exclude-BreakGlass, and exclude that group.
• Alerts on every sign-in, and a test sign-in at least every 90 days.

Also exclude service accounts and the Entra Connect sync account where a policy would break them, and plan to replace them with managed identities or workload identity policies.

The baseline policy set

These map to policies Microsoft documents individually and to its “Secure foundation” templates in the Entra admin center (Entra ID > Conditional Access > Create new policy from templates). Templates exclude only the admin who creates them, so add your break-glass group to each one afterwards.

#	Policy	Users	Conditions	Grant	Licence
CA001	Block legacy authentication	All users, exclude break-glass	Client apps: Exchange ActiveSync clients, Other clients	Block access	P1
CA002	Require MFA for admins	Admin directory roles, exclude break-glass	None	Require MFA (or a phishing-resistant authentication strength)	P1
CA003	Require MFA for all users	All users, exclude break-glass and service accounts	None	Require MFA	P1
CA004	Admins on compliant or hybrid-joined devices	Admin directory roles, exclude break-glass	None	Compliant device OR Entra hybrid joined (require one)	P1 + Intune or hybrid join
CA005	Block unknown or unsupported device platforms	All users, exclude break-glass	Device platforms: Any, exclude Android, iOS, Windows, macOS	Block access	P1
CA006	Sign-in risk: MFA	All users, exclude break-glass	Sign-in risk: Medium and High	Require MFA, sign-in frequency every time	P2
CA007	User risk: remediate	All users, exclude break-glass	User risk: High	Require risk remediation	P2

All target All resources (formerly “All cloud apps”). Notes on each:

• CA001: legacy protocols (POP, IMAP, SMTP AUTH with basic auth, old Office clients) cannot do MFA, so they are the usual way into an account with a leaked password. Check the sign-in logs filtered by client app before you enforce, and move printers and line-of-business apps that send mail to a supported method first.
• CA002: Microsoft’s policy article recommends at least these roles: Global, Application, Authentication, Billing, Cloud Application, Conditional Access, Exchange, Helpdesk, Password, Privileged Authentication, Privileged Role, Security, SharePoint and User Administrator.
• CA003: also add a policy for Securing security info registration (one of the templates) so attackers cannot register their own MFA method on a compromised account from anywhere.
• CA004: needs Intune compliance policies or Entra hybrid join working first, or admins will be locked out. Test with report-only and a non-critical admin account.
• CA005: the platform condition is based on the user agent string, which can be spoofed. Microsoft says to pair it with a device compliance or app protection policy. Leave out platforms you actually use; add Linux to the exclusions if you have Linux desktops.
• CA006 and CA007: create them as two separate policies; Microsoft advises against combining user risk and sign-in risk in one policy. Users must already be registered for MFA so they can self-remediate. Microsoft set 1 October 2026 as the retirement date for the legacy risk policies configured inside ID Protection, so if you still have those, recreate them as Conditional Access policies.

Microsoft-managed policies: check what is already there

Before you build anything, open Conditional Access > Policies and look for policies created by Microsoft. Microsoft adds these managed policies to eligible tenants in report-only mode and turns them on no less than 30 days later if you leave them there (sometimes sooner), with emails and Message center posts about two weeks before. Current ones include:

• 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 and Require remediation for high-risk users
• Require phishing resistant authentication for admins

You can switch a managed policy on early, set it to Off to opt out, add exclusions, or use Duplicate to make an editable copy. You cannot rename or delete them. Add your break-glass group to their exclusions too. If a managed policy already covers one of the baseline rows, either keep it and skip your own version, or duplicate it and turn the original off, so you do not end up with two overlapping policies that are hard to troubleshoot.

Roll out in report-only mode first

1. Create each policy with Enable policy: Report-only. Templates do this by default.
2. Wait at least a week so you see month-start jobs, remote staff and service accounts sign in.
3. In Sign-in logs, open entries and check the Report-only tab: “Report-only: Failure” means the policy would have blocked or challenged that sign-in.
4. Use the What If tool for specific users, apps and platforms you are unsure about.
5. Fix what you find (exclusions, device compliance, app changes), then switch one policy at a time to On, starting with CA001 and CA002.

Use a naming convention so the list stays readable, for example CA003 - All resources: Require MFA: All users. Microsoft suggests a sequence, app, response, who and when pattern.

Export and import policies with Microsoft Graph PowerShell

Keep a JSON copy of every policy: before changes, as a record for audits, and to rebuild a tenant or copy the baseline to another one. You need the Microsoft Graph PowerShell SDK (Install-Module Microsoft.Graph -Scope CurrentUser) and these delegated scopes:

Task	Cmdlet	Scopes (least privileged first)
Read/export policies	Get-MgIdentityConditionalAccessPolicy or a GET with Invoke-MgGraphRequest	Policy.Read.All
Create/import policies	New-MgIdentityConditionalAccessPolicy	Policy.Read.All, Policy.ReadWrite.ConditionalAccess, Application.Read.All

The signed-in account also needs a suitable Entra role, such as Conditional Access Administrator. For a quick look, the documented cmdlet is enough:

Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgIdentityConditionalAccessPolicy -All | Select-Object DisplayName, State, Id

For backups, export the raw Graph JSON rather than the SDK objects; it imports cleanly later. This script only reads:

# PowerShell 7 recommended. Read-only export of every Conditional Access policy to JSON.
Connect-MgGraph -Scopes "Policy.Read.All"

$out = "C:\CA-Backup\$(Get-Date -Format yyyy-MM-dd)"
New-Item -ItemType Directory -Path $out -Force | Out-Null

$uri = "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies"
do {
    $page = Invoke-MgGraphRequest -Method GET -Uri $uri
    foreach ($p in $page.value) {
        $file = ($p.displayName -replace '[\\/:*?"<>|]', '_') + '.json'
        $p | ConvertTo-Json -Depth 20 | Out-File -FilePath (Join-Path $out $file) -Encoding utf8
    }
    $uri = $page.'@odata.nextLink'
} while ($uri)

Get-ChildItem $out | Select-Object Name, Length

To import one policy, strip the read-only properties (id, createdDateTime, modifiedDateTime) and the template link, and force the state to report-only. The example below keeps -WhatIf so nothing is created until you remove it:

# PowerShell 7 (ConvertFrom-Json -AsHashtable). Creates ONE policy, always in report-only mode.
Connect-MgGraph -Scopes "Policy.Read.All","Policy.ReadWrite.ConditionalAccess","Application.Read.All"

$body = Get-Content -Path ".\CA001 - Block legacy authentication.json" -Raw |
        ConvertFrom-Json -AsHashtable

# Remove read-only and tenant-specific properties before creating a new policy
foreach ($k in 'id','createdDateTime','modifiedDateTime','templateId') { $body.Remove($k) }

# Never import straight into "enabled"
$body['state'] = 'enabledForReportingButNotEnforced'

New-MgIdentityConditionalAccessPolicy -BodyParameter $body -WhatIf   # remove -WhatIf to create it

Exported policies contain object IDs for users, groups, roles, named locations and apps. When importing into a different tenant, replace every user, group and named location ID with the target tenant’s IDs first, especially your break-glass exclusion group, or the policy will apply without its exclusions.

If a policy you can see in the portal is missing from the v1.0 export, it may use a feature that the v1.0 endpoint does not return yet; compare counts with the portal and use the beta endpoint for those few if needed.

Check that it worked

1. Sign in as a test user from a browser and a desktop app: you should get an MFA prompt, and the sign-in log should list CA003 as Success under Conditional Access.
2. Try an IMAP or POP client with a test mailbox: the sign-in should fail and the log should show CA001 as the blocking policy.
3. Sign in with a break-glass account and confirm no policy applied (status Not applied for each).
4. Re-run the export script and keep the dated folder as your baseline record.
5. Check our Microsoft 365 MFA status report for users who still have no MFA method registered.

Common problems

• Cannot switch a policy to On while security defaults are enabled: go to Entra ID > Overview > Properties > Manage security defaults, set it to Disabled, and enable your tested policies in the same change window.
• Locked out after enabling a policy: sign in with a break-glass account, set the policy back to Report-only, then fix the exclusion.
• New-MgIdentityConditionalAccessPolicy returns error 1007 “does not match the schema”: the JSON still contains read-only properties or SDK object wrappers. Export with Invoke-MgGraphRequest as above and remove id and the timestamp fields.
• Insufficient privileges: the session did not consent to Policy.ReadWrite.ConditionalAccess, or the account lacks a Conditional Access Administrator role. Run Get-MgContext to see the granted scopes.
• Risk policies do nothing: the tenant has no Entra ID P2 licences, or users are not registered for MFA and cannot complete remediation.

Official documentation: Plan a Conditional Access deployment · Microsoft-managed policies · Manage emergency access accounts · New-MgIdentityConditionalAccessPolicy

Related: Microsoft 365 MFA Status Report: PowerShell Script for Graph · Intune Device Compliance Report: PowerShell Script via Graph · Windows LAPS with Intune and Entra ID: Setup and Retrieval · Entra ID Inactive Users Report: signInActivity PowerShell Script · Employee Offboarding Checklist: Secure AD, M365 and Workspace Steps

See also: Microsoft 365 Business Basic vs Standard vs Premium (2026)

Frequently asked questions

Maintenance record

This guide changes servers, data or security settings, so we re-check it against current versions on a fixed schedule. Take a backup or snapshot before you start.

Maintained by

srvScripts editorial team

Supported versions

Microsoft Entra ID P1 or P2 (Microsoft 365 Business Premium, E3, E5)

Last full review

7 Oct 2026

Next review

5 Apr 2027

Sources

learn.microsoft.com/en-us/entra/identity/conditional-access/plan-conditional-access
learn.microsoft.com/en-us/entra/identity/conditional-access/managed-policies
learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access
learn.microsoft.com/en-us/powershell/module/microsoft.graph.identity.signins/new-mgidentityconditionalaccesspolicy?view=graph-powershell-1.0