The Conditional Access Policies Every Microsoft 365 Tenant Should Have

TL;DR

Conditional Access (CA) is the gatekeeper for Microsoft 365 sign-ins: “if this kind of sign-in happens, then require that.” A brand-new tenant has almost none of it switched on, which is a big reason account takeover is so common. This guide is the baseline set every tenant should run, plus how to turn it on without locking yourself out.

• CA decides who can sign in, from where, on what device, and what they must prove (like MFA).
• The essentials: block legacy sign-ins that skip MFA, require MFA for everyone (admins especially), and only trust managed or compliant devices where you can.
• Do two things first or you will regret it: create two emergency break-glass admin accounts, and roll every policy out in report-only mode to test before you enforce it.
• You can keep it painless: a device filter lets already-managed devices sail through with fewer prompts, while unmanaged and unknown devices get the full set of checks.

Now for the more technical explanation

What is Conditional Access?

Conditional Access is Entra ID’s policy engine for sign-ins. Each policy is an if / then rule:

• Assignments (the “if”): which users/groups, which cloud apps or actions, and conditions like device platform, location, client app, and sign-in or user risk.
• Access controls (the “then”): block access, or grant it but require something first (MFA, a compliant device, a hybrid-joined device, an approved app, a password change), plus session controls (sign-in frequency, persistent-browser limits).

If you are on a small tenant and this feels like a lot, Security Defaults is Microsoft’s one-switch baseline (forces MFA registration, blocks legacy auth, protects admin actions). It is far better than nothing. But the moment you need any nuance (excluding a service account, relaxing prompts on managed devices, risk-based rules), you turn Security Defaults off and move to Conditional Access, which is what the rest of this guide covers.

Before you touch anything: break-glass accounts

The single most common Conditional Access disaster is locking yourself out. Create your escape hatch first.

• Create two cloud-only global admin accounts (for example [email protected] and breakglass2) on the .onmicrosoft.com domain so they never depend on a custom domain or federation.
• Give them long, unique, random passwords, stored offline (a sealed record, a vault entry two people can reach).
• Exclude these accounts from every Conditional Access policy. That is the whole point: if a policy misfires, these still get in.
• Protect them another way instead: a phishing-resistant method (FIDO2 key) held securely, and alerting on their sign-ins so misuse is noticed.

Without this, one bad policy plus one expired token can leave nobody able to sign in to fix it.

Roll everything out in report-only mode first

Every new policy supports Report-only mode. It evaluates the policy against real sign-ins and logs what would have happened, without actually enforcing it.

1. Create the policy in Report-only.
2. Leave it for a few days and watch Sign-in logs (the Conditional Access tab shows “would have” results) and the Insights and reporting workbook.
3. Look for anyone who would have been unexpectedly blocked (service accounts, shared mailboxes with sign-in, a mail-scanning integration, a room device).
4. Fix the assignments/exclusions, then flip to On.

Report-only is how you get strong policy without a support-ticket avalanche.

The baseline policies

Each one below lists what it does, sensible generic settings, and the gotchas. Names are just labels; use whatever naming scheme you like.

1. Block legacy authentication. Legacy protocols (older Exchange ActiveSync, IMAP, POP, SMTP AUTH, older Office clients) can’t do modern MFA, so attackers love them for password spraying.

• Assignments: all users; all cloud apps; condition Client apps = Exchange ActiveSync clients + Other clients.
• Control: Block.
• Gotchas: find legacy sign-ins first (Sign-in logs, filter Client app = legacy). Multifunction printers/scanners and old line-of-business apps that relay mail are the usual casualties; move them to modern auth or a dedicated authenticated submission path before enforcing.

2. Require MFA for all users. The floor. Compromised passwords are a given; MFA is what stops them turning into a breach.

• Assignments: all users (exclude break-glass); all cloud apps.
• Control: Grant, require multifactor authentication.
• Gotchas: have users register MFA before you enforce (or pair with policy 4). Exclude only what you must, and prefer a compliant-device path over blanket exclusions.

3. Require phishing-resistant MFA for admins. Admin accounts are the crown jewels and deserve stronger MFA than a push prompt (which can be phished or MFA-fatigued).

• Assignments: the directory roles that matter (Global Admin, and the other privileged roles Microsoft lists for this).
• Control: Grant, require authentication strength = Phishing-resistant MFA (FIDO2 / passkeys / Windows Hello for Business / certificate).
• Gotchas: make sure admins have a phishing-resistant method enrolled first. This pairs naturally with just-in-time role activation (PIM) if you have Entra ID P2.

4. Require MFA to register security info. Stops an attacker who has only a password from quietly enrolling their own MFA method.

• Assignments: all users; User actions = Register security information.
• Control: require MFA, ideally only from a trusted location or during a controlled onboarding window.
• Gotchas: this is a chicken-and-egg with brand-new users; handle first-time registration via a trusted network, Temporary Access Pass, or a supervised onboarding step.

5. Require a compliant or hybrid-joined device for key apps. Raises the bar from “who are you” to “and is this a device we manage.” Big reduction in risk for the apps that hold your data.

• Assignments: all users; your sensitive apps (Exchange Online, SharePoint/OneDrive, and ideally all).
• Control: Grant, require device to be marked compliant OR Hybrid Entra joined (require one of the selected controls).
• Gotchas: needs Intune (for compliant) and/or hybrid join in place. This is where the device filter below becomes your friend for keeping it liveable.

6. Risk-based policies (Entra ID P2). Let Entra’s risk detection do the work: react automatically when a sign-in or a user looks compromised.

• Sign-in risk: if sign-in risk is Medium/High, require MFA (or block High).
• User risk: if user risk is High, require a secure password change.
• Gotchas: P2 licensing required. Start in report-only, because impossible-travel and anonymous-IP detections can be noisy for road-warriors and VPN users.

7. Session controls. Tighten what a session can do and how long it lasts, especially on devices you don’t manage.

• Sign-in frequency: set a periodic re-authentication (a common choice is a fixed number of hours/days) for higher-risk access.
• Persistent browser: never persistent on unmanaged devices, so a closed browser drops the session.
• App-enforced restrictions: limited web-only access to Exchange/SharePoint from unmanaged devices.
• Gotchas: too-short sign-in frequency annoys everyone; reserve the aggressive settings for unmanaged devices (again, the device filter).

8. Location and country conditions (use with care). Named locations let you treat “from the office / known ranges” differently, or block sign-ins from countries you never operate in.

• Use: block or step-up MFA from countries outside where your users actually are; treat known egress IPs as trusted for lighter session controls.
• Gotchas: geo-IP is imperfect and VPNs move people around. Never rely on location as your only control, and never trust a location so much that it skips MFA entirely unless you have a strong reason. Always keep break-glass excluded.

Cut friction on managed devices with a device filter

Strong policies are only sustainable if your managed fleet barely feels them. Filters for devices let a policy target (or skip) devices by their properties, so you can apply strict controls to unmanaged devices while managed ones get the smooth path.

A reliable “this device is enterprise-managed” filter is:

(device.deviceOwnership -eq "Company")
-or (device.trustType -eq "AzureAD")
-or (device.trustType -eq "ServerAD")
-or (device.trustType -eq "Workplace")
-or ( ((device.operatingSystem -eq "iOS") -or (device.operatingSystem -eq "Android")) -and (device.isCompliant -eq true) )

What each condition means:

• device.deviceOwnership -eq "Company": the device is recorded as corporate-owned, not personal/BYOD.
• device.trustType -eq "AzureAD": the device is Entra joined (cloud-joined, fully managed).
• device.trustType -eq "ServerAD": the device is hybrid Entra joined (domain-joined on-premises and synced up to Entra), which is the shape a lot of established Windows estates are still in. Do not leave this one out: policy 5 above explicitly trusts hybrid-joined devices, so a filter without it drops your entire hybrid fleet onto the strict path, which is the exact friction you were trying to remove.
• device.trustType -eq "Workplace": the device is Entra registered (workplace joined, common for BYOD that still has a managed identity).
• The last clause: iOS or Android devices that are Intune compliant, so mobiles are trusted only when they actually meet policy.

How to use it for “strong but low-disruption”:

• Lighter path for managed devices: on your session-control or step-up policies, add the filter set to Include and exclude these devices, or build a companion policy that gives filtered (managed) devices a longer sign-in frequency and a persistent session, while the strict policy hits everything else.
• Full friction for the rest: the “require compliant device”, “no persistent browser”, and “web-only access” controls apply to devices that don’t match the filter, which is exactly where the risk is.
• Result: unmanaged and unknown devices carry the strict controls; Entra joined/registered and compliant-mobile devices sign in smoothly. Security stays high, day-to-day disruption stays low.

Test this in report-only like everything else, because a mistyped filter can either over-trust or over-block.

Licensing reality

• Conditional Access itself needs Entra ID P1 (included in Microsoft 365 Business Premium, E3, and above).
• Risk-based policies (sign-in risk, user risk) and PIM need Entra ID P2 (E5, or the add-on).
• Security Defaults is free but all-or-nothing; you can’t run it and Conditional Access at the same time.
• Compliant-device controls assume Intune.

A sane rollout order

Do it in this sequence, each step in report-only first:

1. Create break-glass accounts and exclude them from everything.
2. Block legacy authentication (after checking for legacy sign-ins).
3. Require MFA for all users (once MFA is registered).
4. Require MFA to register security info and phishing-resistant MFA for admins.
5. Session controls and the device filter for the managed-device experience.
6. Require compliant / hybrid-joined device for your sensitive apps.
7. Risk-based policies last (they’re the noisiest to tune).

Enforce one policy at a time, watch the sign-in logs for a day or two between each, and keep that break-glass account within reach the entire time.

Related

• Phishing-resistant MFA: passkeys, FIDO2, and Windows Hello for Business
• SPF, DKIM, and DMARC: stop people sending email as your domain

Written by Tom Langston, IT Infrastructure and Cybersecurity.