Most environments have Conditional Access in place. But having policies doesn’t mean they’re effective.
If you’re using Conditional Access, these are the core policies you should seriously consider because they directly impact your exposure to common identity attacks.
! Prerequisites: Licensing
Before deploying these policies, confirm your licensing tier. Implementing the wrong policy without the right license will either silently fail or simply not appear as an option in your tenant.
- Entra ID P1 – Required for Policies 1–5 (MFA, Legacy Auth Block, Privileged Role Protection, Device Compliance, Location-Based Control, Session Controls)
- Entra ID P2 – Required for Policies 6 and 7 (Sign-In Risk and User Risk policies). These are the policies that respond to real-time threat signals and compromised account detection. Without P2, these options will not be available in your Conditional Access blade.
If you are on P1 only, prioritize Policies 1, 2, and 3. Those three alone will block the majority of common identity attacks.
! Using This as an Audit
Audit Tip: Don’t just check for the existence of a policy – check its coverage. Go through your current setup and verify that the users, apps, and conditions are actually covered. A policy with the wrong scope is a back door you didn’t know was open.
1. Require MFA for All Users
Reason:
Passwords alone are not a control. Credential-based attacks like password spray and credential stuffing are automated, high-volume, and cheap to run. MFA breaks the attack chain even when credentials are fully compromised. This is the single highest-impact policy in any Conditional Access deployment.
Assignments:
- Users: All users (exclude break-glass accounts)
- Cloud apps: All cloud apps
Conditions:
- None (apply broadly)
Grant Controls:
- Require multi-factor authentication
Exclude break-glass accounts by direct account assignment, never by group. Minimum two accounts per tenant cloud-only, no MFA dependency, credentials stored offline. Alert on any sign-in. Missing this can mean full tenant lockout with no recovery path.
2. Block Legacy Authentication
Reason:
Legacy protocols like SMTP, IMAP, and POP3 do not support modern authentication, which means they cannot enforce MFA. Attackers actively target these protocols because a valid credential is all they need. Microsoft data has consistently shown that the majority of password spray attacks come through legacy auth endpoints. If you have MFA deployed but legacy auth open, your MFA coverage has a hole in it.
Assignments:
- Users: All users
- Cloud apps: All cloud apps
Conditions:
- Client apps → Select “Other clients” (legacy auth)
Grant Controls:
- Block access
3. Protect Privileged Roles
Reason:
Admin accounts are the highest-value target in any tenant. A compromised Global Admin gives an attacker the ability to disable security policies, exfiltrate data, create backdoor accounts, and persist indefinitely. Standard user protections are not enough here privileged roles need stricter controls, and device compliance on top of MFA significantly raises the bar for attackers.
Assignments:
- Users: Directory roles (Global Admin, Privileged Role Admin, etc.)
- Cloud apps: All cloud apps
Conditions:
- Optional: Locations (restrict to trusted)
Grant Controls:
- Require MFA
- Require a compliant device (recommended) or at least a managed device
4. Require Compliant or Hybrid Joined Devices
Reason:
A valid credential from a managed device is very different from the same credential coming from a personal laptop or an attacker-controlled machine. Device compliance ensures the endpoint meets your security baseline before access is granted, EDR installed, disk encrypted, OS patched. Without this, you have no visibility or control over what is actually connecting to your environment.
Assignments:
- Users: All users (or scoped groups)
- Cloud apps: Office 365 / critical apps
Conditions:
- Device platforms: All
Grant Controls:
- Require device to be marked as compliant
OR - Require hybrid Azure AD joined device
This policy will block unmanaged and personal devices by default. For BYOD or contractor scenarios, scope this to internal users only. Use Intune App Protection Policies (MAM) as an alternative for unmanaged devices, data protection without requiring full enrollment.
5. Location-Based Access Control
Reason:
Most organizations have a reasonably predictable sign-in geography. Sign-ins from unexpected regions particularly high-risk countries with no business presence are worth challenging or blocking entirely. This policy does not stop a determined attacker using a local proxy, but it raises the cost and eliminates a significant volume of opportunistic attacks originating from regions you have no reason to trust.
Assignments:
- Users: All users
- Cloud apps: All cloud apps
Conditions:
- Locations:
- Include: Any location
- Exclude: Trusted locations
Grant Controls:
- Block access OR require MFA
Block – Only if your trusted locations are accurate and stable. Misconfigured locations plus block equals locked out users with no self-service recovery.
Require MFA – Safer default. Users are challenged, not blocked, which handles travel and remote work cleanly.
Start with Require MFA. Move to Block only after validating your trusted location coverage in sign-in logs.
6. Sign-In Risk Policy
Reason:
Entra ID evaluates each sign-in against behavioral signals, impossible travel, anonymous IP, unfamiliar location, token anomalies. A medium or high risk score means something about that sign-in does not look right. This policy acts on that signal in real time, requiring MFA or blocking access before the session is established. Without it, suspicious sign-ins succeed silently and show up in logs only after the fact.
Assignments:
- Users: All users
Conditions:
- Sign-in risk: Medium and above
Grant Controls:
- Require MFA OR block access
7. User Risk Policy
Reason:
User risk is different from sign-in risk. It accumulates over time based on signals like leaked credentials appearing in threat intelligence feeds, patterns of suspicious behavior, or confirmed compromise indicators. A high user risk score means the account itself is likely compromised, not just a single sign-in. Forcing a password change remediates the most common root cause, credential theft and resets the risk score.
Assignments:
- Users: All users
Conditions:
- User risk: High
Grant Controls:
- Require password change
8. Session Controls
Reason:
Long-lived sessions and persistent browser sessions create a window for token theft attacks. If an attacker extracts a valid session token, they can replay it without credentials or MFA until the session expires. Shortening sign-in frequency and disabling persistent sessions limits that window. This is particularly important for high-value apps like email and SharePoint where session tokens are a known target.
Assignments:
- Users: All users
- Cloud apps: Selected apps (e.g., Office 365)
Conditions:
- Optional (can apply broadly)
Session Controls:
- Sign-in frequency (e.g., every 8–12 hours)
- Disable persistent browser session (where required)