Most tenants I review either have no Conditional Access policies at all, or they have fifteen of them that nobody can explain. Neither is safe. This guide gives you a starter set of eight Conditional Access policies that covers the attacks we actually see against 20 to 500 person businesses, and it shows you how to name, scope and roll them out without locking anyone out.
You need Microsoft Entra ID P1 for Conditional Access. Microsoft 365 Business Premium, E3 and E5 all include it. Two of the eight policies use risk signals from Microsoft Entra ID Protection, which needs Entra ID P2 (included in E5, or as an add-on).
Why a small, deliberate set beats a long list
Conditional Access works by combining every policy that applies to a sign-in. If one policy says “require MFA” and another says “require a compliant device”, the user must satisfy both. Block always wins. That makes the engine powerful, and it also means overlapping policies create confusing results that are hard to troubleshoot at 8 a.m. on a Monday.
A small set of broad policies is easier to reason about. Each policy should do one job, apply to a clearly defined group of users, and have a name that tells you what it does without opening it. When a user calls to say they can’t get into Outlook, you want to open the sign-in log and see three or four policies, not eleven.
Before you build anything, create two emergency access accounts that are excluded from every policy. If you skip this step and a policy goes wrong, you can lock every administrator out of the tenant. We cover this in detail in a separate article on break glass accounts.
The eight policies
Here is the starter set, in the order I usually deploy them. The naming follows a simple pattern: a number, the users in scope, the target, and the control.
Name
Users
Target resources
Control
License
CA001-All-AllApps-BlockLegacyAuth
All users
All resources
Block (client apps: Exchange ActiveSync, other clients)
Compliant device, or app protection policy on mobile
P1 + Intune
CA007-All-AllApps-SignInRiskMFA
All users
All resources
Sign-in risk medium/high: require MFA, sign-in frequency every time
P2
CA008-All-AllApps-UserRiskRemediate
All users
All resources
User risk high: require risk remediation or secure password change
P2
Every one of these excludes your emergency access accounts. Policies that target “All users” should also exclude any directory sync service account, such as the Microsoft Entra Connect account, if one exists in your tenant.
CA001: Block legacy authentication
Legacy protocols like POP, IMAP and SMTP basic auth can’t perform MFA, so an attacker with a password can walk straight past your MFA policy. Blocking them is the single highest value policy on the list. Check the sign-in logs first (filter on Client app) to find old scanners, printers or line of business apps that still use them, and fix those before you enforce.
CA002 and CA003: MFA for admins and everyone else
Admins get a stricter policy because their accounts are the ones attackers want most. Use the built-in Phishing-resistant MFA authentication strength, which accepts passkeys (FIDO2), Windows Hello for Business and certificate-based authentication. Everyone else gets the standard Multifactor authentication strength to start. Using authentication strengths rather than the older “Require multifactor authentication” checkbox lets you raise the bar later without rewriting the policy.
CA004: Protect security info registration
If an attacker has a user’s password and that user has never registered MFA, the attacker can register their own phone. This policy targets the Register security information user action and requires MFA, so new registrations happen only from an already-verified session. New hires can satisfy it with a Temporary Access Pass.
CA005: Block device code flow
Device code phishing tricks users into entering a code on a legitimate Microsoft page, which hands the attacker a token. Very few small businesses have a real need for device code flow. Block it for everyone, and create a narrow exception group if you find a conference room device that genuinely needs it.
CA006: Require a managed device for Microsoft 365
This is the policy that stops a stolen session or password from being used on a random home PC. Windows and macOS devices must be marked compliant in Intune. On iOS and Android, require an app protection policy so personal phones can still be used for Outlook and Teams while company data stays inside managed apps. This one takes the most planning, so it goes in last among the P1 policies.
CA007 and CA008: Risk-based policies (P2)
Microsoft Entra ID Protection scores each sign-in and each user for risk. Keep sign-in risk and user risk in separate policies, as Microsoft recommends. Note that the legacy risk policies inside ID Protection retired on October 1, 2026, so if you still have them configured there, rebuild them in Conditional Access.
A safe rollout order
Create two cloud-only emergency access accounts, register passkeys on them, and exclude them from every policy.
Create an exclusion group per policy (for example CA001-Exclude) so you never edit the policy itself to grant an exception.
Build all eight policies in Report-only mode.
Wait at least one week, then review results in Entra ID > Conditional Access > Insights and reporting or the Report-only tab in individual sign-in logs.
Fix anything that would have failed: old protocols, unmanaged devices, users with no MFA registered.
Turn policies On one or two at a time, starting with CA001 to CA003. Leave a few days between each change.
Document each policy’s purpose and owner, and review the list every quarter.
If you have not yet registered MFA for most users, do that first. Our MFA enablement service covers the user communication and registration campaign that makes CA003 painless.
Common mistakes to avoid
Using per-user MFA alongside Conditional Access. Turn the old per-user MFA setting off once Conditional Access handles MFA, or users get inconsistent prompts.
Leaving security defaults on. Security defaults and Conditional Access can’t be used together. Turn security defaults off only when your replacement policies are ready in report-only.
Scoping by named location as a substitute for MFA. “Skip MFA in the office” sounds convenient, but it means a compromised device on the office network gets a free pass.
Targeting custom or administrative unit-scoped roles. Conditional Access role targeting only applies to built-in directory roles.
No exclusion groups. Editing a live policy to add a single person is how typos turn into outages.
Want a quick read on where your tenant stands today? Our free tenant checker flags missing basics, and a full Microsoft 365 security assessment reviews your Conditional Access design line by line.
When to add more policies
The starter set is a foundation, not a ceiling. Common next steps once these eight are stable:
Raise CA003 to phishing-resistant MFA for finance and executives once passkeys are rolled out.
Add a sign-in frequency and no persistent browser session policy for unmanaged browsers.
Protect Azure management with a dedicated admin policy if you run workloads in Azure.
Add guest-specific policies if you collaborate heavily with external partners.
Each new policy should go through the same report-only cycle. Microsoft’s own guidance on planning a Conditional Access deployment is worth reading alongside this list.
Frequently asked questions
Do I need Conditional Access if I already have security defaults?
Security defaults are a good baseline for very small tenants with no Entra ID P1. Once you have Business Premium or E3, Conditional Access gives you control over exclusions, device requirements and risk, which security defaults can’t provide. You can’t run both at the same time.
How long should policies stay in report-only mode?
At least a week, so you capture a full work cycle including people who travel or work odd hours. For the device compliance policy, two weeks is safer because it depends on every device being enrolled and compliant in Intune.
What happens if our Entra ID P1 licenses lapse?
Policies aren’t deleted or disabled when licenses expire. They keep working, but you can’t edit them. That gives you time to renew or plan a change without a sudden drop in protection.
Not sure your Conditional Access policies would stop a real attack? Book a free Microsoft 365 security assessment and we will review your current policies, exclusions and sign-in logs, then hand you a prioritized fix list.
Most tenants I review either have no Conditional Access policies at all, or they have fifteen of them that nobody can explain. Neither is safe. This guide gives you a starter set of eight Conditional Access policies that covers the attacks we actually see against 20 to 500 person businesses, and it shows you how to name, scope and roll them out without locking anyone out.
You need Microsoft Entra ID P1 for Conditional Access. Microsoft 365 Business Premium, E3 and E5 all include it. Two of the eight policies use risk signals from Microsoft Entra ID Protection, which needs Entra ID P2 (included in E5, or as an add-on).
Why a small, deliberate set beats a long list
Conditional Access works by combining every policy that applies to a sign-in. If one policy says “require MFA” and another says “require a compliant device”, the user must satisfy both. Block always wins. That makes the engine powerful, and it also means overlapping policies create confusing results that are hard to troubleshoot at 8 a.m. on a Monday.
A small set of broad policies is easier to reason about. Each policy should do one job, apply to a clearly defined group of users, and have a name that tells you what it does without opening it. When a user calls to say they can’t get into Outlook, you want to open the sign-in log and see three or four policies, not eleven.
Before you build anything, create two emergency access accounts that are excluded from every policy. If you skip this step and a policy goes wrong, you can lock every administrator out of the tenant. We cover this in detail in a separate article on break glass accounts.
The eight policies
Here is the starter set, in the order I usually deploy them. The naming follows a simple pattern: a number, the users in scope, the target, and the control.
Every one of these excludes your emergency access accounts. Policies that target “All users” should also exclude any directory sync service account, such as the Microsoft Entra Connect account, if one exists in your tenant.
CA001: Block legacy authentication
Legacy protocols like POP, IMAP and SMTP basic auth can’t perform MFA, so an attacker with a password can walk straight past your MFA policy. Blocking them is the single highest value policy on the list. Check the sign-in logs first (filter on Client app) to find old scanners, printers or line of business apps that still use them, and fix those before you enforce.
CA002 and CA003: MFA for admins and everyone else
Admins get a stricter policy because their accounts are the ones attackers want most. Use the built-in Phishing-resistant MFA authentication strength, which accepts passkeys (FIDO2), Windows Hello for Business and certificate-based authentication. Everyone else gets the standard Multifactor authentication strength to start. Using authentication strengths rather than the older “Require multifactor authentication” checkbox lets you raise the bar later without rewriting the policy.
CA004: Protect security info registration
If an attacker has a user’s password and that user has never registered MFA, the attacker can register their own phone. This policy targets the Register security information user action and requires MFA, so new registrations happen only from an already-verified session. New hires can satisfy it with a Temporary Access Pass.
CA005: Block device code flow
Device code phishing tricks users into entering a code on a legitimate Microsoft page, which hands the attacker a token. Very few small businesses have a real need for device code flow. Block it for everyone, and create a narrow exception group if you find a conference room device that genuinely needs it.
CA006: Require a managed device for Microsoft 365
This is the policy that stops a stolen session or password from being used on a random home PC. Windows and macOS devices must be marked compliant in Intune. On iOS and Android, require an app protection policy so personal phones can still be used for Outlook and Teams while company data stays inside managed apps. This one takes the most planning, so it goes in last among the P1 policies.
CA007 and CA008: Risk-based policies (P2)
Microsoft Entra ID Protection scores each sign-in and each user for risk. Keep sign-in risk and user risk in separate policies, as Microsoft recommends. Note that the legacy risk policies inside ID Protection retired on October 1, 2026, so if you still have them configured there, rebuild them in Conditional Access.
A safe rollout order
CA001-Exclude) so you never edit the policy itself to grant an exception.Entra ID > Conditional Access > Insights and reportingor the Report-only tab in individual sign-in logs.If you have not yet registered MFA for most users, do that first. Our MFA enablement service covers the user communication and registration campaign that makes CA003 painless.
Common mistakes to avoid
Want a quick read on where your tenant stands today? Our free tenant checker flags missing basics, and a full Microsoft 365 security assessment reviews your Conditional Access design line by line.
When to add more policies
The starter set is a foundation, not a ceiling. Common next steps once these eight are stable:
Each new policy should go through the same report-only cycle. Microsoft’s own guidance on planning a Conditional Access deployment is worth reading alongside this list.
Frequently asked questions
Do I need Conditional Access if I already have security defaults?
Security defaults are a good baseline for very small tenants with no Entra ID P1. Once you have Business Premium or E3, Conditional Access gives you control over exclusions, device requirements and risk, which security defaults can’t provide. You can’t run both at the same time.
How long should policies stay in report-only mode?
At least a week, so you capture a full work cycle including people who travel or work odd hours. For the device compliance policy, two weeks is safer because it depends on every device being enrolled and compliant in Intune.
What happens if our Entra ID P1 licenses lapse?
Policies aren’t deleted or disabled when licenses expire. They keep working, but you can’t edit them. That gives you time to renew or plan a change without a sudden drop in protection.
Not sure your Conditional Access policies would stop a real attack? Book a free Microsoft 365 security assessment and we will review your current policies, exclusions and sign-in logs, then hand you a prioritized fix list.