5 min read
10 Conditional Access Policies Every Microsoft 365 Tenant Should Have
Username and password stopped being enough to protect a Microsoft 365 tenant a long time ago, but most tenants are still one stolen credential away...
5 min read
Nicole Walker
:
Updated on July 16, 2026
Username and password stopped being enough to protect a Microsoft 365 tenant a long time ago, but most tenants are still one stolen credential away from a breach because their Conditional Access policies were never deployed, layered, or revisited.
Attackers know it, and they target identity because that is where the door is unlocked. 10 Conditional Access policies form the baseline for a hardened Microsoft 365 tenant, with two more that become available once Entra ID P2 or the Defender Suite for Business is in place.
Conditional Access is Microsoft's Zero Trust enforcement layer, the firewall rules for identity that decide where, when, and how a user can reach your tenant. Blocking legacy authentication alone stops roughly 97% of credential stuffing attacks, and requiring MFA blocks the vast majority of common identity attacks against Microsoft 365. Deployed together, these policies eliminate most of the edge cases threat actors rely on to slip in through stolen tokens, guest access, and legacy protocols.
In this episode of the Demystifying Microsoft podcast, Nathan Taylor runs a live lab inside a demo tenant and deploys the 10 Conditional Access policies Sourcepass MCOE recommends for every Microsoft 365 tenant, plus the two bonus policies for tenants with Entra ID P2.
Conditional Access requires Entra ID P1, which is included in Microsoft 365 Business Premium, E3, and E5. Business Basic and Business Standard tenants fall back to Security Defaults, which cover roughly 99% of common account compromise but offer no granularity.
Three habits prevent self inflicted lockouts during deployment.
Use report only mode on every new policy so you can see impact in the sign-in logs before you enforce anything.
Exclude at least one admin account from every policy while you test, and use a security group for exclusions so changes propagate immediately instead of taking 20 to 30 minutes.
Configure a break glass emergency access account that sits outside all Conditional Access policies with loud alerts wired to its use.
In most Microsoft 365 tenant, global admins are running privileged rights from the same account they use for daily email, spam, and calendar invites. Microsoft recommends dedicated admin accounts with minimal licensing and no mailbox, paired with Privileged Identity Management under Entra ID P2 for just in time role activation and audit logging.
The policies below are ordered by impact. Deploy in this order and layer them intentionally. Some look redundant on paper, but the redundancy is the point. Each policy catches a failure mode the others miss.
|
# |
Policy |
What It Does |
Why It Matters |
|---|---|---|---|
|
1 |
Require MFA for All Users |
Enforces MFA on every user for every cloud app |
Baseline control that stops most credential attacks |
|
2 |
Require MFA for Admin Roles |
Second MFA layer scoped to admin directory roles |
Catches admins accidentally excluded from Policy 1 |
|
3 |
Block Legacy Authentication |
Blocks ActiveSync, POP, IMAP, and unauthenticated SMTP |
Legacy protocols cannot enforce MFA and are brute forced daily |
|
4 |
Require MFA for Azure Management |
MFA on the Azure resource management app |
Stops attackers from spinning up crypto mining VMs on forgotten subscriptions |
|
5 |
Require MFA to Register or Join Devices |
Prompts MFA at device registration |
Blocks attackers with stolen tokens from joining rogue devices |
|
6 |
Require MFA for Intune Enrollment |
MFA on the Intune enrollment resource |
Closes the same pivot path at the MDM layer |
|
7 |
Require Phishing Resistant MFA for Admins |
Enforces FIDO2, Windows Hello, or certificate based auth |
Blocks token theft patterns that bypass push and one-time codes |
|
8 |
Limit Browser Sessions for Privileged Users |
Caps admin browser sessions at four hours, no persistence |
Shrinks the window a stolen admin session can be replayed |
|
9 |
Require a Managed or Compliant Device |
Requires Entra joined, hybrid joined, or Intune compliant device |
One of two controls that actually stops session token replay |
|
10 |
Block Device Code Flow |
Disables device code authentication at the tenant level |
Shuts down a phishing pattern that bypasses MFA entirely |
Policies 9 and 10 close the two token theft patterns Microsoft 365 tenants are seeing most often in 2026. Managed and compliant device policies block token replay by requiring the sign-in to come from a known device, which stops a stolen token from working on an attacker's machine. Device Code Flow phishing tricks the victim into completing MFA on the attacker's behalf, and blocking Device Code Flow at the tenant level removes the exposure entirely.
Before enforcing Policies 3 and 10, filter the Entra sign-in logs to find real world usage. Sign-in logs live under entra.microsoft.com in Entra ID, then Monitoring & health, then Sign-in logs. For legacy authentication, filter by client app for Exchange ActiveSync, IMAP, POP, and SMTP. For Device Code Flow, filter by authentication protocol. Anything that appears is a candidate for exclusion, replacement, or a compensating control like a trusted named location.
Two more policies dramatically improve identity protection, and both require Entra ID P2. The most efficient way to add P2 for a Business Premium tenant is through the Microsoft Defender Suite for Business Premium, a $10 per user per month add-on that bundles Entra ID P2, Defender for Endpoint Plan 2, Defender for Identity, Defender for Office 365 Plan 2, and Defender for Cloud Apps under a single Defender XDR layer. Standalone Entra ID P2 is $9 per user per month, which makes the Defender Suite one of the strongest values in Microsoft's current lineup.
Risky sign-in policies trigger on anomalies like impossible travel, anonymous IP addresses, password spray patterns, and leaked credentials. Risky user policies look at the account itself using signals like leaked credentials, unusual file access, suspicious API activity, and threat intelligence matches. Most tenants block high risk sign-ins outright and force MFA plus a password change on medium risk or high risk users.
Mobile device policies for iOS and Android are a separate layer of Conditional Access that deserves its own scoping conversation. A hardened tenant usually adds mobile application management, mobile device management, and app protection policies that control corporate data access on personal devices, along with SharePoint download restrictions from unmanaged browsers. Most tenants at this maturity end up with 16 to 18 policies once mobile is included. For the most sensitive environments, layering a 24/7 identity SOC on top puts a live analyst on anomalous logins outside business hours instead of leaving them for a Monday morning ticket queue.
Conditional Access requires Entra ID P1, which is included in Microsoft 365 Business Premium, E3, and E5. Risk-based Conditional Access policies like risky sign-in and risky user detection require Entra ID P2, which is included in E5 or available through the Defender Suite for Business Premium add-on. Business Basic and Business Standard tenants fall back to Security Defaults, which cover roughly 99% of common account compromise but do not offer granular control.
MFA is a single control that requires a second factor at sign-in. Conditional Access is the policy engine that decides when MFA is required, when access is blocked, and what conditions like device compliance, location, or sign-in risk have to be met. MFA without Conditional Access applies the same rule to every user in every scenario. Conditional Access lets you enforce stricter controls on admin accounts, sensitive apps, and risky sign-in while keeping normal user access smooth.
Most tenants need at least 10 core policies to cover identity protection, plus two more if Entra ID P2 is in place for risky sign-in and risky user detection. Tenants that also manage mobile devices, guest access, and app protection typically end up with 16 to 18 policies once the full stack is deployed. The exact number depends on how many admin roles, device types, and sensitive workloads need scoped policies.
Use report only mode before enforcement, exclude at least one admin account from every policy, and configure a break glass emergency access account with alerts wired to its use. These three habits catch nearly every self inflected lockout scenario.
Sourcepass MCOE deploys these policies for customers as part of security hardening engagements, and every tenant has edge cases that need to be scoped, tested, and documented before enforcement.
If you want a second set of eyes on your Conditional Access configuration, we can walk through your tenant with you and tailor the policies to your users, devices, and licensing.
Subscribe to the Demystifying Microsoft podcast for more episodes where we break down Microsoft 365 security, licensing, and identity strategy for IT teams that want practical guidance without the marketing noise.
5 min read
Username and password stopped being enough to protect a Microsoft 365 tenant a long time ago, but most tenants are still one stolen credential away...
4 min read
The Copilot that frustrated your early testers is not the Copilot Microsoft is shipping through Frontier. Excel handles hundreds of thousands of...
5 min read
The most dangerous Microsoft 365 attack right now is the one that does not look like an attack.
1 min read
The average BEC attack costs organizations over $125,000. Most of them succeed not because defenses were bypassed, but because the right controls...
1 min read
Most of the Microsoft 365 accounts compromised in the last 18 months had MFA enabled at the time of the attack.
5 min read
Attackers no longer need a password to take over a Microsoft 365 account. They just need a session token, and they are getting it after users...