Entra Conditional Access: Policy Design, Named Locations, and Error Fixes
Why This Is Happening
I've seen this exact situation play out in dozens of enterprise environments: an IT admin spends an afternoon setting up Microsoft Entra Conditional Access, feeling confident, hits save , and the next morning the helpdesk queue is flooded with users who can't sign into Microsoft 365. Or worse, the policy silently does nothing at all. I know that's frustrating, especially when security leadership is breathing down your neck and users are locked out of their work.
Entra Conditional Access is Microsoft's Zero Trust policy engine. At its core, it's an if-then system, if a user tries to access a resource, then they have to satisfy certain conditions first. That sounds straightforward. The reality? The configuration surface is enormous, the order of evaluation isn't always obvious, and the error messages users receive rarely point to the actual policy causing the block.
Here's the core problem most admins run into: Conditional Access policies are enforced after first-factor authentication completes. This means a user already has a password session before your policies fire. If a policy is misconfigured, say, the named location range is wrong, or you forgot to exclude your break-glass admin account, you may not find out until someone gets locked out at 2am. Microsoft is explicit that Conditional Access is not a frontline defense for denial-of-service attacks; it's a post-authentication access control layer that evaluates identity signals, device state, IP location, application context, and real-time risk data all at once.
The signals Entra Conditional Access uses include the user's identity (individual accounts, group membership, or even AI agent identities in preview), their IP location against your defined named locations, the device platform and compliance state, the specific application they're accessing, and live risk signals fed in from Microsoft Entra ID Protection. Get any one of these conditions wrong and your policy either blocks everyone or blocks no one.
Common misconfiguration patterns I see constantly:
- Named locations defined as CIDR ranges that exclude VPN egress IPs, your "trusted office" location doesn't match what traffic actually looks like from the corporate VPN.
- Forgetting to exclude emergency access accounts, one overly-broad MFA policy locks out your break-glass admin.
- Policies left in "Off" state, someone created a policy, never switched it from Off to On, and wonders why nothing changed.
- Legacy authentication protocols bypassing policies entirely, SMTP AUTH, IMAP, and older Office clients can skip modern authentication and walk right past your Conditional Access policies unless you explicitly block legacy authentication.
- Conflicting grant controls, one policy requires a compliant device, another requires hybrid joined device, and the user's machine satisfies neither.
The good news: every one of these is fixable. And with the right approach, using report-only mode first, testing with the What If tool, and understanding exactly how named locations work, you can get Entra Conditional Access doing exactly what you intended. Browse all Microsoft fix guides →
The Quick Fix, Try This First
If users are suddenly getting blocked and you need to diagnose fast, the single most useful tool Microsoft gives you is the What If tool inside the Entra admin center. Here's exactly how to use it right now.
Go to entra.microsoft.com and sign in with an account that has at least the Security Reader role. Navigate to Protection > Conditional Access, then click Policies in the left pane. At the top of the Policies page you'll see a button labeled What If, click it.
In the What If panel, type in the affected user's UPN (their email address), select the application they're trying to reach (for Microsoft 365 issues, choose "Office 365"), and optionally plug in their IP address or device platform. Hit What If again and Entra will show you exactly which policies apply to that user for that scenario, including policies in report-only mode and policies that would block access.
Nine times out of ten, you'll immediately see the offending policy. Look for any policy where the result column shows "Block" that you weren't expecting. Click into it to review the conditions and grant settings.
If the What If tool shows no policies applying when you expected them to, that tells you the opposite problem: your policy conditions aren't matching that user's context. Check whether the user is actually in the assigned group, whether the application assignment matches, or whether the IP falls inside your defined named location.
Once you've identified the problem policy, the fastest safe fix is to switch it to Report-only mode temporarily rather than turning it off entirely. Report-only still evaluates the policy and logs what would have happened, but it doesn't enforce the block. Users get access, you stop the bleeding, and you keep the audit trail. Go to the policy, click it, scroll to Enable policy at the bottom, and select Report-only instead of On.
Before you create or change anything, get a full picture of what's already deployed. This step saves you from creating conflicting policies or accidentally duplicating something the Conditional Access Optimization Agent already set up.
Sign into entra.microsoft.com with at least a Security Reader role (Conditional Access Administrator or Global Administrator for editing). Navigate to Protection > Conditional Access > Policies.
You'll see every policy in your tenant, including report-only policies and any policies generated by the Conditional Access Optimization Agent if that's enabled. The state column tells you On, Off, or Report-only. Sort by State to quickly find everything that's actively enforcing.
On the Overview page (one level up from Policies), Microsoft shows you recent activity: how many policies are enabled vs report-only, sign-in breakdowns, application coverage, device state, and any security alerts with suggestions. This dashboard is your fastest health check.
Switch to the Coverage tab, this is underused and genuinely useful. It shows which applications have Conditional Access policy coverage and which don't, over the past seven days. If you see a critical internal application sitting in the "no coverage" column, that's a gap worth addressing. Any application without at least one active policy is potentially exposed.
Export the full policy list for documentation. There's no one-click export in the GUI, but you can pull it via Microsoft Graph API or PowerShell:
Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgIdentityConditionalAccessPolicy | Select-Object DisplayName, State, CreatedDateTime | Format-TableIf this runs and returns a clean list, you're ready to move on. If it throws an error about permissions, your account is missing the Policy.Read.All scope, that's a sign the admin account itself may be subject to a misconfigured policy, which is a separate problem to solve first.
Go to Protection > Conditional Access > Policies > New policy. Give it a clear, descriptive name, I always recommend a naming convention like [Environment]-[Target]-[Control]-[Version], for example: PROD-AllUsers-RequireMFA-v1. You'll thank yourself six months from now when you have thirty policies and need to find the right one fast.
Under Users, be deliberate about scope. The "All users" option is the most common source of accidental lockouts. If you're testing, target a specific group first, create an Azure AD security group called something like CA-Pilot-Group and put a handful of test accounts in it. Only widen scope to all users once you've validated behavior in report-only mode.
Always configure the Exclude tab under Users. At minimum, exclude your emergency access accounts (break-glass accounts). Microsoft strongly recommends maintaining at least two break-glass admin accounts that are excluded from all Conditional Access policies, these exist precisely so you can recover from a misconfiguration that locks out regular admins. If you don't have break-glass accounts yet, create them before you go any further with Entra Conditional Access policy enforcement.
Under Target resources, choose which applications or services the policy covers. For a broad MFA requirement, you can select "All cloud apps", but think carefully before doing this. Some service accounts and automation pipelines authenticate against cloud apps and may not support modern authentication or MFA. Scope to specific apps like "Office 365" or "Microsoft Azure Management" where you know your users are human and interactive.
Leave the policy in Report-only mode and save. You'll activate it in a later step after testing with the What If tool.
Named locations are one of the most misconfigured parts of Entra Conditional Access. If you've ever set up a "block access from outside the office" policy and had it block your own VPN users, this step is for you.
Navigate to Protection > Conditional Access > Named locations. You have two types to choose from: IP ranges location and Countries location.
For IP ranges, click New location > IP ranges location. Enter a name (e.g., "Corporate Office - Chicago"), then add your CIDR ranges. The critical mistake people make here is entering only their office's public IP, and forgetting the VPN egress IP. Your users working from home route through a VPN concentrator that has its own public IP. If that IP isn't in your trusted named location, those users will fail location-based conditions even though they're on a corporate network. Check with your network team for the full list of egress IPs before saving.
Tick the Mark as trusted location checkbox if this location should be treated as a trusted network. Trusted locations get preferential treatment in some MFA policies, for example, you can write a policy that only requires MFA when the sign-in comes from outside a trusted location, reducing friction for office workers while still protecting remote access.
For country-based blocking, click New location > Countries location. Select the countries you want to define as a location (either to block or allow). You can then reference this named location in a policy condition under Conditions > Locations. To block access from specific countries, set the condition to "Include: [your country location]" and set the grant control to "Block access." This is a blunt instrument, use it carefully, especially if you have remote workers or contractors in those regions.
After saving your named locations, go back to your policy, navigate to Conditions > Locations, and configure Include/Exclude to reference the locations you just created. Verify the logic: "Include: Any location, Exclude: [Corporate Office - Chicago]" means the policy fires for everyone except users coming from that trusted IP range. That's the right setup for requiring MFA from outside the office.
The Grant section is where you define what happens when all your conditions match. This is where most of the real-world complexity lives. You have two top-level choices: Block access (the most restrictive) or Grant access with one or more requirements.
For an MFA requirement, select Grant access > Require multifactor authentication. This is the most common Conditional Access policy configuration and the right place to start for any new tenant. If you have Microsoft Entra ID P2 or Microsoft 365 Business Premium, you can go further and use Require authentication strength, this lets you mandate phishing-resistant MFA methods like FIDO2 security keys or Windows Hello for Business rather than accepting SMS-based codes.
If your organization manages corporate devices, consider adding device-based controls. Require device to be marked as compliant checks whether the device is enrolled in Intune and meets your compliance policies. Require Microsoft Entra hybrid joined device checks whether the machine is domain-joined and registered in Entra ID, useful for traditional on-prem environments that haven't fully moved to Intune yet. Be careful combining these: if you set "Require ALL of the selected controls" and the user's device satisfies neither, they get blocked. Set to "Require ONE of the selected controls" if you want to accept either condition.
For high-privilege accounts, your Global Administrators, Exchange Administrators, Privileged Role Administrators, Microsoft recommends creating a dedicated policy that requires MFA for administrators at every sign-in, regardless of location or device state. These accounts are the highest-value targets for attackers and should have zero exceptions. Create a separate policy scoped to your admin roles, set conditions to "Any location," and grant with "Require multifactor authentication" plus "Require authentication strength" if your license supports it.
Requiring MFA for Azure management tasks is another policy Microsoft recommends out of the box. Target the "Microsoft Azure Management" application specifically, this covers the Azure portal, Azure CLI, Azure PowerShell, and the Azure mobile app. An attacker who compromises an admin credential and skips MFA can do enormous damage through the Azure portal in minutes.
This step is non-negotiable. If you skip it, every other policy you've configured has a potential bypass sitting open. Legacy authentication protocols, SMTP AUTH, IMAP, POP3, older ActiveSync clients, older Office clients using basic authentication, do not support modern authentication and therefore completely bypass Conditional Access policies. An attacker with a stolen credential can try those protocols and walk straight past your MFA requirement.
To block legacy authentication in Entra Conditional Access, create a dedicated policy. Go to New policy and name it something clear like PROD-AllUsers-BlockLegacyAuth-v1.
Set Users to "All users" (this is one of the few cases where All Users is appropriate, you want no exceptions for legacy auth blocking).
Under Conditions > Client apps, switch the toggle to "Yes" and check the following boxes: Exchange ActiveSync clients and Other clients. Leave the modern authentication checkboxes unchecked, you are only targeting legacy clients here.
Set Grant to Block access.
Before turning this On, run it in report-only mode for 48 hours and review the sign-in logs. Navigate to Monitoring > Sign-in logs, filter by Client app = "Other clients" and look at the volume. If you're seeing hundreds of sign-ins per day using legacy protocols, investigate which service accounts or applications are responsible before you flip the policy On, otherwise you may break automated mail workflows, on-prem applications, or shared mailbox scanning tools.
Once you're satisfied with the report-only data, switch the policy to On. Users on modern clients won't notice anything. Users on legacy clients will get an error and need to upgrade their app or switch to a supported authentication method. That's intentional.
Advanced Troubleshooting
When the standard fixes don't resolve the issue, it's time to go deeper into the sign-in logs and Graph API data. These tools give you the full picture of what Conditional Access evaluated and why it made the decision it did.
Reading the Sign-In Logs for Conditional Access Failures
Go to Monitoring > Sign-in logs in the Entra admin center. Find the failed sign-in event, filter by the user's UPN and the time range of the incident. Click into the event and select the Conditional Access tab. This shows you every policy that was evaluated, whether each policy applied, and whether the grant condition was satisfied or not.
The status field will tell you one of: Success, Failure, or Interrupted. For Conditional Access blocks, look for the error code in the Basic info tab. Common ones include:
53003, Access blocked by Conditional Access policy (the policy explicitly blocked the sign-in)50097, Device authentication is required (compliant device condition failed)50076, MFA is required by the Conditional Access policy but wasn't completed530032, Access blocked: security policy disallows sign-in from this location
Using Microsoft Graph API for Deep Policy Analysis
When you need to audit policies programmatically or export configurations for review, Graph API is the right tool. After connecting to Microsoft Graph with the appropriate permissions:
Connect-MgGraph -Scopes "Policy.Read.All", "AuditLog.Read.All"
# Get all conditional access policies with full detail
Get-MgIdentityConditionalAccessPolicy | ConvertTo-Json -Depth 10 | Out-File "CA_Policies_Export.json"
# Get sign-in logs filtered by CA result
Get-MgAuditLogSignIn -Filter "conditionalAccessStatus eq 'failure'" -Top 50 |
Select-Object UserPrincipalName, AppDisplayName, ConditionalAccessStatus, CreatedDateTimeEnterprise and Domain-Joined Device Scenarios
If you're in a hybrid environment where devices are domain-joined on-prem and registered in Entra ID, the Entra hybrid joined device condition can silently fail when device writeback isn't configured in Entra Connect. Check Microsoft Entra Connect health in the portal and verify device writeback is enabled. If devices aren't showing up as hybrid joined in Entra ID, the Conditional Access policy requiring hybrid joined devices will block those users even if they're on a corporate domain machine.
For Group Policy-managed environments, be aware that some legacy GPO settings push registry keys that affect authentication behavior. Check:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUIand verify no GPO is disabling Windows Hello for Business or forcing basic auth if your Conditional Access policies expect modern auth methods.
The Conditional Access Optimization Agent
If your tenant has a Microsoft Entra ID P1 license and security compute units (SCU) for Microsoft Security Copilot, the Conditional Access Optimization Agent can analyze your current policies and suggest improvements aligned with Zero Trust principles. Suggestions appear directly in the Policies page and can be applied with one click. Review them carefully before applying, the agent's recommendations are well-grounded in Microsoft best practices, but you know your environment's specific requirements better than any automated system.
Prevention & Best Practices
Getting Entra Conditional Access right the first time, and keeping it right as your environment changes, comes down to process as much as configuration. Here's what I recommend to any organization that wants to avoid the 2am lockout call.
Maintain a policy change log outside the portal. The Entra audit log captures changes, but a simple shared document or wiki page that records why a policy was changed, not just what changed, is worth its weight in gold. Six months from now when you're investigating why a particular policy has an unusual exclusion, you'll want the human context the audit log doesn't give you.
Review the Coverage tab weekly. New applications get deployed in organizations constantly, and a freshly added SaaS tool with no Conditional Access coverage is a risk waiting to be exploited. The seven-day Coverage view in the Entra admin center makes this review quick. Make it a standing item on your security team's weekly checklist.
Test break-glass accounts monthly. Emergency access accounts are excluded from Conditional Access policies by design, but that exclusion only helps you if those accounts actually work when you need them. Run a monthly test sign-in from a fresh browser or device to confirm the credentials are valid and the accounts can actually access the admin center. Rotate the credentials every 90 days and store them in a physical safe or a highly privileged secrets vault, not in your standard password manager.
Don't manage Conditional Access directly in production. Use a staging tenant or at minimum the report-only mode pipeline for every policy change before it goes live. The What If tool is your pre-flight checklist. Run it every single time.
Align license tiers with the controls you actually need. Some of the most valuable Conditional Access controls, risk-based Conditional Access, session controls via Microsoft Defender for Cloud Apps, and the Optimization Agent, require Microsoft Entra ID P2 or specific add-on licenses. If users are getting error messages about policy features that seem unavailable, check your license assignments in the Entra admin center before spending hours troubleshooting configuration.
- Enable Security Defaults if you haven't deployed Conditional Access yet, they provide baseline MFA protection with zero configuration and are free for all tenants.
- Create a dedicated Conditional Access Administrators group and restrict policy editing to that group, preventing accidental changes from broad admin roles.
- Run the Conditional Access policy export script monthly and save versioned JSON snapshots so you can roll back to a known-good policy state if something goes wrong.
- Review the Entra Conditional Access policy templates in the portal, Microsoft provides pre-built templates for the most common scenarios like requiring MFA for admins, blocking legacy auth, and requiring compliant devices, all grounded in Zero Trust principles.
Frequently Asked Questions
What exactly is Microsoft Entra Conditional Access and how does it work?
Entra Conditional Access is Microsoft's Zero Trust policy engine that evaluates signals, user identity, device state, IP location, application being accessed, and real-time risk data, and then either grants or blocks access based on rules you define. It works as an if-then system: if a user matches certain conditions, then they must satisfy certain requirements (like MFA or a compliant device) before getting access. It fires after the first authentication factor completes, so the user has already proven their password before Conditional Access runs its checks. You configure it in the Microsoft Entra admin center under Protection > Conditional Access.
What are Conditional Access conditions and how do I configure them?
Conditions are the matching criteria that determine whether a policy applies to a given sign-in attempt. Available conditions include User risk, Sign-in risk (requires Entra ID P2), Device platforms (iOS, Android, Windows, macOS), Locations (IP ranges and country locations), Client apps (modern auth vs legacy auth), and Filter for devices (for targeting specific device attributes like privileged access workstations). You configure conditions inside each policy under the Conditions section. Each condition has an Include and Exclude tab, "Include: Any location, Exclude: Trusted corporate network" is a very common pattern for requiring MFA from outside the office.
How do I define named locations in Entra Conditional Access?
Go to Protection > Conditional Access > Named locations and click New location. You have two types: IP ranges location (where you enter CIDR blocks like 203.0.113.0/24) and Countries location (where you select countries from a list). For IP-based locations, make sure you include all your egress IPs, office public IP, VPN concentrator egress IPs, and any cloud proxy IPs your users route through. You can mark IP locations as Trusted, which signals to other policies that sign-ins from those ranges come from a managed network. Once saved, reference your named locations in any policy under Conditions > Locations.
Why are my users getting blocked even though the Conditional Access policy looks correct?
The most common cause is a secondary policy you're not thinking about, use the What If tool (Policies > What If) to test the exact user, application, and IP address combination and see every policy that evaluates. Check the sign-in logs under Monitoring > Sign-in logs and look at the Conditional Access tab on the specific failed event; error code 53003 means a policy explicitly blocked the sign-in. Also confirm the user is actually in the correct group assignment, the application target matches what they're accessing, and that you haven't accidentally scoped a "Block" policy too broadly. If everything looks correct in the UI and the block persists, escalate to Microsoft Support, occasionally policy evaluation service delays cause stale results.
Do I need a Microsoft Entra ID P1 or P2 license for Conditional Access?
Yes, most Conditional Access features require at least Microsoft Entra ID P1, which is included in Microsoft 365 Business Premium, Microsoft 365 E3, and the standalone Entra ID P1 license. Risk-based Conditional Access (using sign-in risk and user risk conditions fed by Entra ID Protection) requires Microsoft Entra ID P2. The Conditional Access Optimization Agent requires both a P1 license and security compute units for Microsoft Security Copilot. If your licenses expire, existing policies aren't automatically deleted but you can't edit them, Microsoft calls this "graceful state," and it gives you time to migrate. Security Defaults remain available to all customers for free as a baseline protection layer.
How do I block legacy authentication with Conditional Access without breaking things?
The key is running the block policy in report-only mode for at least 48 hours before activating it. Create the policy targeting the "Other clients" and "Exchange ActiveSync clients" checkboxes under Conditions > Client apps, set Grant to Block access, and switch Enable policy to Report-only. Then go to Monitoring > Sign-in logs and filter by Client app = "Other clients", review every sign-in that would have been blocked. Identify service accounts, scan-to-email printers, legacy on-premises applications, and any automation using SMTP AUTH or basic authentication. Plan migrations for each one (most can move to OAuth 2.0 or certificate-based authentication), then flip the policy to On once the volume of report-only hits is at or near zero.