How to Harden Entra ID Conditional Access for Zero Trust
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Most Microsoft 365 breaches involve credential compromise: and most credential compromise succeeds because legacy authentication protocols bypass MFA, weak Conditional Access policies allow authentication from unmanaged devices, or administrator accounts lack the additional protections they require.
Conditional Access is the enforcement point that closes these gaps. It evaluates every authentication attempt and applies policies before granting access: the right configuration blocks 99% of credential-based attacks. The wrong configuration (or no configuration beyond the defaults) leaves basic credential attack vectors open.
Policy 1: Block Legacy Authentication (Priority 1)
Legacy authentication protocols (Basic auth, SMTP AUTH, POP3, IMAP, Exchange ActiveSync with basic credentials) do not support modern MFA and bypass Conditional Access entirely. Blocking them is the single highest-impact Conditional Access policy.
Create policy: "BLOCK-Legacy-Authentication-All-Users"
Assignments:
Users: All users
Exclude: Break-glass accounts, service accounts that legitimately use legacy auth
Cloud apps: All cloud apps
Conditions:
Client apps: Select all legacy authentication clients:
✓ Exchange ActiveSync clients
✓ Other clients ← catches Basic auth clients
(Uncheck: Browser, Mobile apps and desktop clients)
Grant: Block access
Enable policy: Report-only first (monitor for 14 days)
Then: Enable
# Verify there are no blocking legacy auth clients first:
# Check Sign-in logs filtered to Client App = 'Other clients'
# Any legitimate services using legacy auth must be migrated before enabling
Identify legacy auth usage before blocking:
// Find all legacy authentication sign-ins in last 30 days:
SigninLogs
| where TimeGenerated > ago(30d)
| where ResultType == "0" // Successful
| where ClientAppUsed in (
"Exchange ActiveSync",
"IMAP4",
"MAPI Over HTTP",
"Offline Address Book",
"Other clients",
"POP3",
"SMTP"
)
| summarize
Count = count(),
Users = make_set(UserPrincipalName)
by ClientAppUsed, AppDisplayName
| order by Count desc
// Each row represents a legacy auth use case that must be remediated before blocking
Policy 2: Require MFA for All Users and Apps
Create policy: "REQUIRE-MFA-All-Users-All-Apps"
Assignments:
Users: All users
Exclude:
- Break-glass accounts (these are policy exceptions; protect them another way)
- Guest users (if you have a separate guest policy)
Cloud apps: All cloud apps
Exclude: Windows Azure Service Management API (if using automation)
Conditions:
Locations: Any location (no location exceptions)
Grant: Require multi-factor authentication
(Check ONLY 'Require multi-factor authentication')
Enable policy: Report-only first → verify no legitimate breakage → Enable
IMPORTANT: Do not exclude specific apps or locations to "make it easier"
Every exclusion is a potential MFA bypass vector
Policy 2b: Require phishing-resistant MFA for high-sensitivity apps:
Create policy: "REQUIRE-PhishingResistant-MFA-SensitiveApps"
Assignments:
Users: All users
Cloud apps: Select sensitive applications:
- Microsoft Azure Management
- Azure DevOps
- Your on-prem apps via App Proxy that handle sensitive data
Conditions: Any location
Grant: Require authentication strength
Authentication strength: Phishing-resistant MFA
(Phishing-resistant = FIDO2 security key or Windows Hello for Business)
# This overlays the standard MFA policy for high-sensitivity resources
# Users without FIDO2 keys are blocked from these apps: drives FIDO2 adoption
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Policy 3: Protect Administrator Accounts
Administrator accounts require additional controls beyond standard MFA: they are the highest-value targets for attackers.
Create policy: "PROTECT-Admins-Phishing-Resistant-MFA"
Assignments:
Users: Select roles:
Global Administrator, Security Administrator,
Privileged Role Administrator, Privileged Identity Management Administrator,
Exchange Administrator, SharePoint Administrator,
Application Administrator, Cloud Application Administrator,
User Administrator, Authentication Administrator
Cloud apps: All cloud apps
Conditions: Any location
Grant: Require authentication strength
Authentication strength: Phishing-resistant MFA
(FIDO2 or Windows Hello for Business: not TOTP or SMS)
Session:
Sign-in frequency: Every 4 hours (reduce from default 1 day for admins)
Persistent browser session: Never persistent
# This means admin accounts cannot use TOTP authenticator apps for privileged actions
# Requires physical FIDO2 key or Windows Hello: raises the bar significantly
Policy 3b: Block admin account risky sign-ins:
Create policy: "BLOCK-Admins-Risky-SignIn"
Assignments:
Users: [same admin roles as above]
Cloud apps: All cloud apps
Conditions:
Sign-in risk: High (Identity Protection P2 required)
Grant: Block access
# High sign-in risk on an admin account = almost certainly an attack
# Auto-block prevents the attacker from using the compromised admin session
# This is an emergency control: admin cannot unblock themselves; require process
Policy 4: Require Compliant Device and Named Location
Create policy: "REQUIRE-Compliant-Device-SensitiveApps"
Prerequisite: Intune enrollment + compliance policies configured
Assignments:
Users: All users (or specific groups accessing sensitive apps)
Cloud apps: Select high-sensitivity apps:
- SharePoint sites with sensitive labels
- Azure Management
- HR system (Workday, etc.)
Conditions: Any location
Grant: Require one of the selected controls:
✓ Require device to be marked as compliant ← Intune-enrolled
✓ Require Hybrid Azure AD joined device ← Domain-joined + Entra joined
(Grant requires = user must meet ONE of these)
# Rollout tip: Enable in report-only mode, review sign-ins with non-compliant devices
# Before enforcing, fix device enrollment issues for all affected users
Named Location for corporate IP restriction:
Entra admin center > Protection > Conditional Access > Named Locations >
New location > IP ranges location
Name: Corporate-IP-Ranges
IPs: 203.0.113.0/24 [your public IP range(s)]
Mark as trusted location: Yes
Create policy: "REQUIRE-MFA-Outside-Corporate"
Assignments:
Users: All users
Cloud apps: All cloud apps
Conditions:
Locations: Exclude Corporate-IP-Ranges
Grant: Require MFA
# Users inside corporate IP range: MFA skipped (trusted location)
# Users outside: MFA required
# Note: this only adds exemption, does not BYPASS the global MFA policy above
# The global MFA policy requires MFA always; trusted location only affects
# policies that grant bypass for trusted locations
Monitor Conditional Access policy effectiveness:
// Check how many sign-ins are being blocked vs. granted by CA policies:
SigninLogs
| where TimeGenerated > ago(7d)
| summarize
Total = count(),
Blocked = countif(ResultType != "0"),
Granted = countif(ResultType == "0")
by ConditionalAccessStatus, ResultType
| order by Total desc
// Find sign-ins that bypassed MFA (policy gap indicator):
SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType == "0"
| where AuthenticationRequirement == "singleFactorAuthentication"
// If MFA-required policies are correctly configured, this should be empty
// or limited to break-glass and excluded accounts only
| project TimeGenerated, UserPrincipalName, AppDisplayName,
IPAddress, ClientAppUsed, AuthenticationRequirement
The bottom line
The essential Conditional Access baseline has four policies: (1) Block all legacy authentication clients (Other clients + Exchange ActiveSync in Conditions > Client apps): verify no legitimate legacy auth use before enforcing; (2) Require MFA for all users and all cloud apps with no location or app exclusions; (3) Require phishing-resistant MFA (FIDO2/Windows Hello) for administrator roles with a 4-hour session frequency; (4) Block high-risk sign-ins (Identity Protection sign-in risk = High) for administrators automatically. Deploy each policy in Report-only mode first, review impact in Sign-in logs, then enable. Use KQL on SigninLogs to verify no single-factor authentication sign-ins exist after enabling MFA policies.
Frequently asked questions
Why is blocking legacy authentication the most important Conditional Access policy?
Legacy authentication protocols (Basic auth, SMTP AUTH, POP3, IMAP) cannot participate in the Conditional Access evaluation flow: they authenticate before the Conditional Access engine runs. This means any user account that can authenticate via legacy protocols can bypass all MFA requirements and Conditional Access policies, including location restrictions and device compliance. Microsoft reports that over 99% of password spray attacks and a large proportion of credential compromise attacks specifically target legacy authentication to bypass MFA.
What is the difference between requiring MFA and requiring phishing-resistant MFA in Conditional Access?
Requiring MFA (multi-factor authentication) accepts any second factor including SMS codes, TOTP authenticator apps (Microsoft Authenticator, Google Authenticator), and hardware keys. These are all susceptible to real-time phishing interception in AiTM attacks where the attacker's proxy captures the TOTP code or push notification approval. Requiring phishing-resistant MFA (via Authentication Strength in Conditional Access) restricts to FIDO2 hardware security keys or Windows Hello for Business: these use public key cryptography bound to the specific domain, making relay attacks technically impossible.
What is the first Conditional Access policy every organization should implement?
The first Conditional Access policy should block legacy authentication: create a policy targeting all users, all cloud apps, with a condition of Client Apps = 'Exchange ActiveSync clients' and 'Other clients', and set Grant to Block. This blocks Basic authentication, SMTP AUTH (when used by legacy mail clients), POP3, IMAP, and other non-modern authentication protocols that bypass MFA entirely. Before enforcing, run the policy in report-only mode for 14 days and review the sign-in logs to identify any business-critical applications using legacy auth that need to be migrated to modern authentication first.
How do I deploy Conditional Access without locking out users?
Safe Conditional Access rollout: (1) Enable report-only mode on all new policies before enforcement — report-only logs what would have been blocked without actually blocking anything, giving 14-30 days of validation data. (2) Exclude break-glass accounts from all Conditional Access policies — these emergency admin accounts must bypass CA to recover from misconfiguration. (3) Roll out in phases: start with a pilot group of 10-20 IT staff, validate for one week, then expand to departments in batches. (4) Monitor the Conditional Access failure workbook in Entra for unexpected blocks during rollout. The most common lockout cause: a CA policy requiring compliant devices applied before devices are enrolled in Intune.
What are named locations in Conditional Access and when should I use them?
Named locations define trusted IP ranges (office networks, VPN egress IPs) or trusted countries that can be used as conditions in Conditional Access policies. Use cases: (1) Require MFA only when users access from outside named trusted locations (reduces MFA fatigue for office users while enforcing MFA for remote access); (2) Block sign-ins from countries your organization has no presence in (reduces attack surface from nation-state groups); (3) Enforce additional controls (compliant device, phishing-resistant MFA) for access from unknown locations. Named locations are configured in Entra ID > Security > Conditional Access > Named locations. Keep the trusted IP list current: stale IPs (expired office leases, old VPN endpoints) create unauthorized trust relationships.
How do you validate that Conditional Access policies are actually enforcing MFA and not silently exempting accounts?
Run the Conditional Access What If tool in the Entra admin center against a sample of user accounts (a standard user, a break-glass account, and a service principal) to confirm which policies apply and which grant controls fire. After enabling policies, query SigninLogs in Log Analytics for `AuthenticationRequirement == 'singleFactorAuthentication'` across all successful sign-ins: any result for a non-excluded account indicates a gap in policy scope. Check the ConditionalAccessPolicies field in each sign-in log entry, which lists every policy evaluated and its result (success, failure, notApplied): a policy showing notApplied for a user who should be in scope indicates an assignment error. Run this audit weekly for the first 30 days after any policy change, and configure a Sentinel alert rule to fire whenever a sign-in completes with single-factor authentication from an account that is not on the break-glass exclusion watchlist.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.