A new joiner can't open Teams on her personal laptop. A finance user gets an MFA prompt from a country he has never visited. An attacker sends a "sign in to view the shared document" email with a device code. In Microsoft 365, the thing that decides what happens in each of these moments is Conditional Access.
Identity is the new perimeter, and Conditional Access policies are the rules on that perimeter: if this user, on this device, from this place, opens this app, then allow, ask for MFA, or block. This guide gives you 25 Conditional Access policies that cover admins, users, devices, guests, apps and AI agents, along with what each one does and the safe way to roll it out.
Who this is for: Microsoft 365 and Entra ID admins, IT support engineers and anyone preparing for an identity or security role. You need at least Microsoft Entra ID P1 (included in Microsoft 365 E3 and Business Premium) for Conditional Access, and Entra ID P2 (Microsoft 365 E5) for the risk-based policies.
Before you create any policy: 4 rules that prevent lockouts
Most Conditional Access horror stories ("we locked out the whole company, including ourselves") come from skipping these steps:
- Create two emergency access (break-glass) accounts and exclude them from every policy. Use cloud-only accounts, long passwords or FIDO2 keys, and alert on every sign-in.
- Start every policy in Report-only mode. Let it run for at least a week and review what it would have done in the sign-in logs and the Conditional Access insights workbook.
- Use a pilot group first, then expand to all users.
- Use a clear naming convention, for example
CA01-Admins-PhishingResistantMFA, so anyone can understand the policy list at a glance.
You'll find the policies in the Microsoft Entra admin center > Entra ID > Conditional Access > Policies. Microsoft also offers ready-made templates there (Secure foundation, Zero Trust, Remote work, Protect administrator and Emerging threats), which are a quick way to create many of the policies below.
Part 1: Protect administrators (CA01 to CA05)
Admin accounts are the keys to the kingdom. Protect them first.
CA01: Require phishing-resistant MFA for admin roles
Target directory roles such as Global Administrator, Security Administrator, Exchange Administrator and User Administrator. Under Grant, choose Require authentication strength > Phishing-resistant MFA. This allows only passkeys/FIDO2 keys, Windows Hello for Business or certificate-based authentication, so a fake login page or an MFA fatigue attack can't steal the session.
Not sure what a passkey is? Read Passkeys explained.
CA02: Short, non-persistent admin sessions
For the same admin roles, set Session > Sign-in frequency to a few hours (for example 4 hours) and Persistent browser session > Never persistent. A stolen or forgotten admin session then expires quickly.
CA03: Require a compliant device for admins
Admins should manage the tenant only from a compliant (Intune-managed) or hybrid-joined device, ideally a dedicated admin workstation. Grant: Require device to be marked as compliant.
CA04: Require MFA for Azure management
Target the Windows Azure Service Management API resource for all users. This covers the Azure portal, Azure CLI and Azure PowerShell. Microsoft now enforces MFA here too, but your own policy gives you control and reporting.
CA05: Block high-risk sign-ins for admins
With Entra ID P2, include admin roles, set Conditions > Sign-in risk to Medium and High, and choose Block access. An admin sign-in that looks like an attacker shouldn't just get an MFA prompt.
Part 2: Protect every user (CA06 to CA13)
CA06: Require MFA for all users
The single most effective policy. Target All users (excluding break-glass accounts) and All resources, and require MFA or the Multifactor authentication authentication strength.
CA07: Block legacy authentication
Old protocols like POP, IMAP, SMTP AUTH and older Office clients can't do MFA, so attackers love them for password spraying. Under Conditions > Client apps, select Exchange ActiveSync clients and Other clients, and block access.
CA08: Block device code flow
Device code phishing tricks users into entering a code on the real Microsoft login page and approving the attacker's session, MFA included. Under Conditions > Authentication flows, select Device code flow and block it. Exclude only the specific users or rooms (for example Teams Rooms devices) that truly need it. Our device code phishing breakdown shows how this attack works.
CA09: Block authentication transfer
In the same Authentication flows condition, Authentication transfer lets a session move from a PC to a phone by scanning a QR code. Block it unless you need it.
CA10: Secure security info registration
Attackers who steal a password often try to register their own phone for MFA. Use Target resources > User actions > Register security information and require MFA, or allow registration only from trusted locations or compliant devices.
CA11: Protect device registration
Choose User actions > Register or join devices and require MFA, so a stolen password alone can't add a rogue device to your tenant. If you use this, set "Require Multifactor Authentication to register or join devices" to No in Entra device settings, so the Conditional Access policy is in control.
CA12: Require MFA for risky sign-ins
Entra ID P2: for all users, set Sign-in risk to Medium and High and require MFA. If a sign-in looks unusual (anonymous IP, impossible travel, password spray), the user must prove it's really them.
CA13: Require a secure password change for high user risk
Entra ID P2: when User risk is High (for example leaked credentials), require password change together with MFA. Build risk policies in Conditional Access rather than the older Identity Protection risk policy pages, which Microsoft is retiring.
Part 3: Protect devices and apps (CA14 to CA18)
CA14: Require compliant or hybrid-joined devices on Windows and macOS
For desktop platforms, grant access only if the device is compliant or Microsoft Entra hybrid joined. Company data stays on company-managed laptops.
CA15: Require app protection on iOS and Android
On phones, require an app protection policy (Intune MAM). Users can read email in Outlook on a personal phone, but can't copy company data into WhatsApp or personal storage.
CA16: Block unknown or unsupported device platforms
Include Any device platform, exclude the platforms you support (Windows, macOS, iOS, Android), and block. Attack tools often report strange or empty platform values.
CA17: Limit access from unmanaged devices
Instead of blocking personal devices completely, use Session > Use app enforced restrictions for SharePoint, OneDrive and Exchange Online. Users get browser-only access with no downloads, printing or syncing.
CA18: Require token protection for sign-in sessions
Token theft (stealing the session cookie after MFA) is now a common attack. Token protection binds sign-in tokens to the device, so a stolen token doesn't work elsewhere. Check Microsoft's current list of supported platforms and apps, and test with a pilot group first.
Part 4: Location and session controls (CA19 to CA21)
CA19: Block countries you don't operate in
Create a named location with countries you never do business from, and block sign-ins from it. It's not a complete defense (attackers use VPNs), but it removes a lot of noise. Remember to plan for travelling staff.
CA20: No persistent sessions on unmanaged devices
For devices that aren't compliant, set a sign-in frequency (for example 8 hours) and never persistent browser sessions, so nobody stays signed in on a shared or cyber-café computer.
CA21: Step-up authentication for sensitive data
Use an authentication context (for example "Highly confidential") linked to sensitivity labels or SharePoint sites. When someone opens HR or finance files, they're asked for phishing-resistant MFA again, even if already signed in.
Part 5: Guests and external users (CA22 to CA23)
CA22: Require MFA and terms of use for guests
Target Guest or external users, require MFA, and add a Terms of use agreement so every guest accepts your data rules before accessing Teams or SharePoint.
CA23: Block guests from Microsoft admin portals
Target the Microsoft Admin Portals resource for guest users and block access. Guests have no reason to open the Entra, Exchange or Microsoft 365 admin centers.
Part 6: Workload identities and AI agents (CA24 to CA25)
CA24: Restrict service principals to trusted locations
Apps and scripts sign in with service principals, and attackers abuse leaked app secrets. With Workload Identities Premium, you can block single-tenant service principals that sign in from outside your known IP ranges.
CA25: Block unapproved AI agents
AI agents now sign in with their own agent identities. Conditional Access for agents lets you include all agent identities, exclude the agents you've approved, and block the rest. It became generally available in mid-2026 and needs Microsoft Agent 365 or Microsoft 365 E7 licensing. Start in report-only mode, like every other policy.
Quick reference: all 25 policies
| # | Policy | Licence |
|---|---|---|
| CA01 | Phishing-resistant MFA for admins | P1 |
| CA02 | Short, non-persistent admin sessions | P1 |
| CA03 | Compliant device for admins | P1 + Intune |
| CA04 | MFA for Azure management | P1 |
| CA05 | Block risky admin sign-ins | P2 |
| CA06 | MFA for all users | P1 |
| CA07 | Block legacy authentication | P1 |
| CA08 | Block device code flow | P1 |
| CA09 | Block authentication transfer | P1 |
| CA10 | Secure security info registration | P1 |
| CA11 | Protect device registration | P1 |
| CA12 | MFA for risky sign-ins | P2 |
| CA13 | Password change for high user risk | P2 |
| CA14 | Compliant or hybrid-joined Windows/macOS | P1 + Intune |
| CA15 | App protection on iOS/Android | P1 + Intune |
| CA16 | Block unknown device platforms | P1 |
| CA17 | Browser-only access on unmanaged devices | P1 |
| CA18 | Token protection | P1 |
| CA19 | Block unused countries | P1 |
| CA20 | No persistent sessions on unmanaged devices | P1 |
| CA21 | Step-up for sensitive data | P1 |
| CA22 | MFA and terms of use for guests | P1 |
| CA23 | Block guests from admin portals | P1 |
| CA24 | Service principals from trusted locations | Workload ID Premium |
| CA25 | Block unapproved AI agents | Agent 365 / M365 E7 |
Check your current policies with PowerShell
Before adding anything, export what you already have. This read-only Microsoft Graph PowerShell command lists every policy and whether it's on, off or in report-only mode:
Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgIdentityConditionalAccessPolicy |
Select-Object DisplayName, State, CreatedDateTime |
Sort-Object DisplayName |
Format-Table -AutoSizeenabledForReportingButNotEnforced in the State column means report-only. New to PowerShell automation? See our 10 PowerShell scripts for IT admins.
When users get blocked: how to troubleshoot
Sooner or later a policy will block someone it shouldn't. Open Entra admin center > Sign-in logs, find the failed sign-in, and check the Conditional Access tab. It shows which policy applied and why. The What If tool lets you test a user, app and device combination before you change anything.
The classic example is Teams error code 53003, which means a Conditional Access policy blocked the sign-in, usually because of an unmanaged device or location.
FAQ
Do I need all 25 Conditional Access policies?
Not on day one. Start with break-glass accounts, then CA06 (MFA for all), CA07 (block legacy auth), CA01 (phishing-resistant MFA for admins) and CA08 (block device code flow). Add the rest as your licensing and device management allow.
What licence do I need for Conditional Access?
Microsoft Entra ID P1, which is included in Microsoft 365 Business Premium, E3 and E5. Risk-based policies need Entra ID P2 (included in E5).
What is report-only mode?
The policy is evaluated at every sign-in and the result is logged, but nothing is enforced. It's the safest way to see the impact before turning a policy on.
Is security defaults the same as Conditional Access?
Security defaults is a free, one-switch baseline (MFA registration, legacy auth blocked). Conditional Access gives you fine-grained control. You can't use both at the same time, so turn off security defaults when you move to Conditional Access.
Can Conditional Access stop phishing completely?
No single control does, but phishing-resistant MFA, token protection and blocking device code flow together stop the most common Microsoft 365 phishing techniques used today.
Bottom line: protect your admins first, enforce MFA for everyone, close the old doors (legacy auth and device code flow), and test every policy in report-only mode with break-glass accounts excluded. That alone puts your tenant ahead of most organizations.
.png)
){kind=link}
0 Comments