.svg){kind=small}
A username and password stopped protecting a Microsoft 365 tenant a long time ago. Yet most tenants are still one stolen credential away from a breach .The reason is simple. Their Conditional Access policies were never deployed, layered, or revisited.
Attackers know this, and they target identity because that is where the door is unlocked. Ten Conditional Access policies form the baseline for a hardened Microsoft 365 tenant. Two more become available once you add Entra ID P2 or the Defender Suite for Business.
Why Conditional Access is the Foundation of Microsoft 365 Identity Security
Conditional Access is Microsoft's Zero Trust enforcement layer. Think of it as firewall rules for identity. It decides where, when, and how a user can reach your tenant. Blocking legacy authentication alone stops roughly 97% of credential stuffing attacks. Requiring MFA blocks the vast majority of common identity attacks against Microsoft 365. Deployed together, these two policies close most of the gap threat actors use 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. He 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.
What do you Need Before Deploying Conditional Access in Microsoft 365?
Conditional Access requires Entra ID P1. That license is included in Microsoft 365 Business Premium, E3, and E5. Business Basic and Business Standard tenants fall back to Security Defaults. Security Defaults cover roughly 99% of common account compromise, but they offer no granular control.
Three habits prevent self inflicted lockouts during deployment.
- Use report only mode on every new policy. This lets you see the impact in the sign-in logs before you enforce anything.
- Exclude at least one admin account from every policy while you test. Use a security group for exclusions so changes propagate right away instead of taking 20 to 30 minutes.
- Configure a break glass emergency access account that sits outside all Conditional Access policies. Wire loud alerts to its use.
What is the Best Way to Set Up Admin Accounts for Conditional Access?
In most Microsoft 365 tenant, global admins run privileged rights from the same account they use for daily email, spam, and calendar invites. That is a problem. Microsoft recommends dedicated admin accounts with minimal licensing and no mailbox. Pair those accounts with Privileged Identity Management under Entra ID P2 for just in time role activation and audit logging.
What are the Top 10 Conditional Access Policies Every Microsoft 365 Tenant Should Have?
The policies below are ordered by impact. Deploy them 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 |
Which Policies Stop Microsoft 365 Session Token Theft?
Policies 9 and 10 close the two token theft patterns Microsoft 365 tenants see most often in 2026. Managed and compliant device policies block token replay. They require the sign-in to come from a known device, so a stolen token will not work on an attacker's machine. Device Code Flow phishing tricks the victim into completing MFA on the attacker's behalf. Blocking Device Code Flow at the tenant level removes the exposure entirely.
How do you Check Sign-In Logs Before Blocking Legacy Auth and Device Code Flow?
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. Go to 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.
Which Conditional Access Policies Require Entra ID P2?
Two more policies dramatically improve identity protection, and both require Entra ID P2. For a Business Premium tenant, the most efficient way to add P2 is through the Microsoft Defender Suite for Business Premium. This $10 per user per month add-on 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 costs $9 per user per month. That pricing makes the Defender Suite one of the strongest values in Microsoft's current lineup.
What is the Difference Between Risky Sign-In and Risky User Policies?
Risky sign-in policies trigger on anomalies. Examples include impossible travel, anonymous IP addresses, password spray patterns, and leaked credentials. Risky user policies look at the account itself. They use signals like leaked credentials, unusual file access, suspicious API activity, and threat intelligence matches. Most tenants block high risk sign-ins outright. They also force MFA plus a password change on medium risk or high risk users.
What Other Conditional Access Policies Should you Consider for Microsoft 365?
Mobile device policies for iOS and Android are a separate layer of Conditional Access, and they deserve their own scoping conversation. A hardened tenant usually adds mobile application management, mobile device management, and app protection policies. These control corporate data access on personal devices. Many tenants also add SharePoint download restrictions from unmanaged browsers. Once mobile is included, most tenants end up with 16 to 18 policies.
For the most sensitive environments, consider layering a 24/7 identity SOC on top. That puts a live analyst on anomalous logins outside business hours instead of leaving them for a Monday morning ticket queue.
Get Help Deploying Conditional Access in your Microsoft 365 Tenant
Sourcepass MCOE deploys these policies for customers as part of security hardening engagements. 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 guidance without the marketing noise.
