Microsoft Entra ID Conditional Access: Complete Setup Guide (2026)

The Problem with Traditional Security

Here's a scenario that plays out in organizations every week: a company has strong passwords, maybe even MFA on paper, but once someone authenticates they have unrestricted access to everything: from any device, any country, any network. That's not security. That's a perimeter that evaporated in 2020.

Microsoft Entra Conditional Access is the enforcement layer that fixes this. Instead of asking only "who are you?", it asks "who are you, where are you, what device are you on, and given everything I know about this sign-in right now - should I let you through?"

Note: Microsoft rebranded Azure Active Directory (Azure AD) to Microsoft Entra ID in 2023. If you searched for "Azure AD Conditional Access", you are in the right place; same product, now with expanded identity governance capabilities. Throughout this guide, "Entra Conditional Access" and "Conditional Access" refer to the same feature.

This guide walks through prerequisites, a step-by-step policy creation walkthrough, the top five best practices, named locations, MFA integration, and a full FAQ. Whether you're enabling your first policy or hardening an existing tenant, this is your 2026 reference.

How Entra Conditional Access Works

Conditional Access sits between authentication (proving identity) and authorization (granting access). Every sign-in event is evaluated against your policy set in real time. The engine collects signals across five dimensions:

1. Who: User identity, group membership, role assignment, and guest vs. member status
2. What: Which cloud application or resource is being accessed
3. Where: IP address, named location (country/region or IP range), network type
4. How: Device platform, compliance state, join type (Entra joined, hybrid, registered), browser vs. app
5. Risk: Sign-in risk score and user risk score from Microsoft Entra ID Protection (requires P2 license)

Based on those signals, each matching policy returns one of three outcomes: Allow, Block, or Grant with conditions (MFA, compliant device, terms of use, etc.).

This is the technical foundation of a [Zero Trust security model](/blog/what-is-zero-trust-security-complete-guide): never implicitly trust, always verify, and enforce least-privilege access at every session.

Prerequisites

Before creating your first Entra Conditional Access policy, verify the following:

1. Entra ID P1 or P2 license: Conditional Access requires at least Microsoft Entra ID P1. Risk-based policies require P2. P1 is included in Microsoft 365 Business Premium, E3, and EMS E3.
2. Global Administrator or Conditional Access Administrator role: You need one of these roles to create or modify policies.
3. At least two break-glass emergency access accounts: Cloud-only accounts excluded from all CA policies. If you lock yourself out without these, tenant recovery requires a Microsoft support case.
4. MFA registration baseline: Users should complete MFA registration before you enforce it via policy. Use the combined registration experience under Entra ID > Identity > Overview > Self-service password reset.
5. Intune enrollment (for device compliance policies): If you plan to require compliant devices, Intune must be configured and devices enrolled.
6. Report-only mode understanding: All new policies should be created in Report-only mode first and monitored in Sign-in logs before switching to On.
7. Named locations defined: If you plan location-based policies, configure your trusted IP ranges and country allowlists in advance (see Named Locations section below).

Creating Your First Entra Conditional Access Policy

The most impactful first policy is MFA for all users. Here's the full Azure portal walkthrough:

Step 1: Open the Conditional Access blade

Navigate to portal.azure.com → Microsoft Entra ID → Protection → Conditional Access. You can also search "Conditional Access" in the top search bar.

Step 2: Create a new policy

Click + New policy. Give it a descriptive name that encodes the intent: CA001 - Require MFA - All Users - All Apps.

Use a naming convention from day one. A flat list of 30 policies named "Policy 1" through "Policy 30" is unmanageable.

Step 3: Configure Users

Under Users, select All users. Then click Exclude and add:

• Your break-glass emergency access accounts (by user object, not group)
• Any service accounts that use legacy protocols (temporarily, while you migrate them)

Never skip the exclusion step. A policy with no exclusions and a misconfiguration can lock every admin out of the tenant.

Step 4: Configure Target Resources

Under Target resources, select All cloud apps. For a baseline MFA policy this is correct: you want every cloud application covered.

For more targeted policies (e.g., compliant device required only for Azure Portal), you would select Select apps and pick specific applications from the list.

Step 5: Set Conditions (optional for this policy)

For the baseline MFA policy, leave Conditions unconfigured. This means the policy applies regardless of location, device, or risk level, providing the broadest possible enforcement.

For location-based or risk-based policies, you'll configure Conditions here (covered in their respective sections below).

Step 6: Configure Grant

Under Grant, select Grant access and check Require multifactor authentication. Click Select.

Do not select "Block access" here; that would block all users from all apps entirely.

Step 7: Enable in Report-only mode first

At the bottom, set Enable policy to Report-only (not On). Click Create.

Step 8: Monitor Sign-in logs

Go to Entra ID > Monitoring > Sign-in logs. Filter by Conditional Access: Report-only. Review which sign-ins would have been affected. Look for unexpected blocks: service accounts, break-glass accounts, or critical applications that need exclusions.

Monitor for 24–48 hours minimum before enabling.

Step 9: Switch to On

Once you're satisfied with the report-only results, go back to the policy and set Enable policy to On. The policy is now live.

Setting Up Your Core Policy Baseline

After you're comfortable with the process, deploy this five-policy baseline. Each policy follows the same creation steps above; only the configuration differs.

Policy 1: Require MFA for All Users

The non-negotiable baseline. No exemptions for executives (especially not for executives; they are the highest-value targets in every phishing campaign).

• Users: All users (exclude break-glass accounts)
• Target resources: All cloud apps
• Grant: Require MFA

Policy 2: Block Legacy Authentication

Legacy protocols (POP3, IMAP, SMTP AUTH, older Office clients) do not support modern MFA. They are responsible for a disproportionate share of credential spray attacks. Block them completely.

• Users: All users
• Target resources: All cloud apps
• Conditions → Client apps: Select Exchange ActiveSync clients and Other clients
• Grant: Block access

This is one of the highest-ROI security changes available in any Microsoft 365 tenant. If you only implement one policy, make it this one.

Policy 3: Require Compliant Device for Sensitive Apps

For your most sensitive applications (Azure Portal, Exchange admin center, SharePoint admin, Microsoft 365 admin center), require devices that are Intune-compliant in addition to MFA.

• Users: All users (exclude service accounts)
• Target resources: Select apps - Microsoft Admin Portals, Azure Management
• Grant: Require MFA and Require device to be marked as compliant

Policy 4: Block High-Risk Sign-ins

Requires Entra ID P2. Microsoft Identity Protection assigns a risk score to every sign-in based on behavioral anomalies, leaked credentials, impossible travel, and threat intelligence.

• Users: All users
• Target resources: All cloud apps
• Conditions → Sign-in risk: High
• Grant: Block access

For medium risk, use Require MFA rather than Block; this allows legitimate users who triggered a medium-risk event to verify themselves.

Policy 5: Require MFA for Azure Management

Azure Portal and Azure Resource Manager deserve special attention: access to these is effectively root access to your cloud infrastructure.

• Users: All users
• Target resources: Select apps → Microsoft Azure Management
• Grant: Require MFA + Require compliant device

Recommended Baseline at a Glance

Top 5 Entra Conditional Access Best Practices

These are the practices that consistently separate well-secured tenants from those that generate incident reports.

1. Always Use Report-Only Mode Before Enabling

Every new policy should spend at least 48 hours in Report-only mode. Check the Sign-in logs under Conditional Access: Report-only. Look for service accounts, shared mailboxes, or automation that would be blocked. The cost of a false positive in production (locking out a business-critical service) is far higher than 48 hours of monitoring.

2. Maintain Two Break-Glass Emergency Access Accounts

Create two cloud-only accounts with .onmicrosoft.com UPNs, assign Global Administrator, and explicitly exclude them from every single Conditional Access policy by user object (not via group; group membership changes can silently remove the exclusion). Store credentials in an offline password manager and physical safe. Alert on any sign-in from these accounts. If you ever need them, something is seriously wrong.

3. Apply Least Privilege to Policy Scope

Start with broad policies for baseline controls (MFA, legacy auth blocking) and narrow policies for high-privilege actions (admin portal access). Avoid "all users, all apps, all conditions" for restrictive Grant controls, as it creates an unmanageable blast radius if something goes wrong. As part of a broader [Zero Trust](/blog/what-is-zero-trust-security-complete-guide) strategy, segment your policies by user role, sensitivity tier, and resource type.

4. Name Policies with a Consistent Convention

A naming convention saves hours of troubleshooting when you have 30+ policies. A common format:

CA[number] - [Action] - [Scope: Users or Apps] - [Condition]

Examples:

• CA001 - Require MFA - All Users - All Apps
• CA002 - Block - All Users - Legacy Auth
• CA010 - Require Compliant Device - All Users - Azure Management

This makes policy intent readable at a glance in the Conditional Access blade and in audit logs.

5. Review Policies Quarterly and After Every Security Incident

Business needs change: acquisitions, new SaaS tools, remote work expansions. Policies that made sense six months ago may now have gaps or unnecessary blocks. Schedule a quarterly review: check for policies with expired exclusions, users or groups that no longer exist, and applications that should be added to sensitive-app policies. After any security incident related to identity, review every policy that should have caught the attack, and determine why it didn't. This is also directly relevant to [OWASP security controls](/blog/owasp-top-10-agentic-ai-security-2026-enterprise-guide) for access control validation.

Named Locations and Trusted Networks

Named locations are one of the most underused features in Entra Conditional Access. They let you define trusted IP ranges or trusted countries and use location as a signal in policies.

Defining a Named Location

Navigate to Entra ID > Protection > Conditional Access > Named locations > + IP ranges location.

For a corporate network:

• Name: Corporate Network - HQ Seattle
• IP ranges: Your public egress IPs in CIDR notation (e.g., 203.0.113.0/24)
• Mark as trusted location: Enabled

For a country allowlist:

• Click + Countries location
• Select allowed countries (e.g., United States, United Kingdom, Canada)
• Name it: Allowed Countries - North America + UK

Using Named Locations in Policies

Once defined, reference named locations under Conditions → Locations in any policy:

Require MFA outside trusted networks:

• Conditions → Locations → Exclude: Your corporate named location
• Grant: Require MFA
• Effect: On-premise users on the corporate network skip MFA; remote users always get prompted

Block access from disallowed countries:

• Conditions → Locations → Include: Any location
• Conditions → Locations → Exclude: Your Allowed Countries named location
• Grant: Block access
• Effect: Sign-ins from outside your approved countries are blocked outright

Considerations

• Trusted IP ranges only cover egress IPs. VPN split tunneling, cloud-hosted VMs, and mobile data will not match corporate IPs.
• Country-based blocking is imperfect - VPNs and Tor can defeat it. Use it as defense-in-depth, not a primary control.
• Named locations can be referenced across multiple policies. If your corporate IP range changes, update the named location once and all policies update automatically.

Conditional Access and MFA

MFA and Entra Conditional Access are related but distinct controls. Understanding the difference is essential for correct deployment.

MFA vs. Conditional Access: What's the Difference?

MFA (Multi-Factor Authentication) is the verification method - something you know (password) plus something you have (authenticator app, FIDO2 key, SMS code).

Entra Conditional Access is the policy engine that decides *when and whether* to require MFA (or other controls) based on context. Conditional Access doesn't replace MFA; it orchestrates it.

You can have MFA enabled per-user (the legacy method) without Conditional Access. This is not recommended; it applies MFA uniformly without context, cannot adapt to risk, and does not support modern grant controls like device compliance.

With Conditional Access, MFA is one of several grant controls, applied conditionally based on who, what, where, how, and risk signals.

Microsoft Authenticator: The Recommended MFA Method

For most organizations, Microsoft Authenticator with number matching is the right default:

• More phishing-resistant than SMS OTP (no code to intercept)
• Push notifications with number matching defeat MFA fatigue attacks
• Supports passwordless sign-in (phone sign-in) as a future upgrade path

Configure the authentication methods under Entra ID > Protection > Authentication methods > Policies.

FIDO2 Security Keys for High-Privilege Accounts

For Global Administrators, Security Administrators, and other tier-0 roles, require FIDO2 security keys (YubiKey, Titan, etc.). These are phishing-resistant by design; the key is bound to the origin domain and cannot be tricked by a spoofed login page.

Configure this in a Conditional Access policy targeting admins:

• Users: Directory role - Global Administrator, Privileged Role Administrator
• Grant: Require authentication strength → Phishing-resistant MFA

Pair this with [Microsoft Entra ID PIM](/blog/microsoft-entra-id-pim-privileged-identity-management-guide) for just-in-time activation of privileged roles, so admin MFA is only triggered when roles are actively needed.

MFA Fatigue and How Conditional Access Helps

MFA fatigue (also called MFA bombing) is when attackers flood a user with push notifications until they accidentally approve one. Conditional Access reduces the attack surface by:

1. Requiring number matching - Users must enter a number displayed on the sign-in screen, not just tap "Approve"
2. Sign-in frequency controls - Set how long an MFA session is valid. Don't set it too long (reduces security) or too short (burns user patience). 8–24 hours for standard users; require re-auth for every privileged session.
3. Risk-based step-up - Require MFA only when risk is elevated; trusted devices on trusted networks can sign in without friction

Risk-Based Policies with Identity Protection

If you have Entra ID P2, Risk-based Conditional Access is one of the most powerful controls available. Microsoft Identity Protection analyzes every sign-in against behavioral baselines, threat intelligence feeds, and historical patterns, then assigns a risk score: Low, Medium, or High.

Recommended configuration:

User risk is distinct from sign-in risk. A high user risk score indicates the account itself is likely compromised (e.g., credentials found in a breach), regardless of any individual sign-in's risk level.

Testing Your Policies

Never enable a policy without testing. Three tools make this safe:

Report-Only Mode

All policies should start in Report-only. The policy evaluates every sign-in and records what it *would* have done, without actually blocking or requiring anything. Check results in Sign-in logs under the Conditional Access tab of each log entry.

What If Tool

Conditional Access > Policies > What If lets you simulate a specific sign-in scenario:

• User: select a test account
• Cloud app: specify an application
• Conditions: specify IP, device platform, risk level

The tool shows which policies apply, which do not apply, and why. Use this to verify exclusions are working and policies are matching the right scenarios.

Pilot Groups

For high-impact policies, create a pilot group of 5–10 IT staff, add them to the policy scope before all users, and run in On mode for the pilot group while keeping Report-only for everyone else. Fix issues at small scale before rolling out broadly.

Monitoring and Maintenance

Conditional Access is not a set-it-and-forget-it control. Active monitoring is required.

Set up Azure Monitor alerts for:

• Sign-in failures attributed to Conditional Access (ResultType: 53003 = blocked by Conditional Access)
• Changes to any Conditional Access policy (Audit log: Update conditional access policy)
• Any sign-in from your break-glass emergency access accounts

Review Conditional Access Insights (Conditional Access > Insights and Reporting) monthly. This workbook shows policy impact across your user population: how many sign-ins are being affected, which policies are triggering most, and whether exclusion lists have grown unsustainably.

Common Mistakes to Avoid

1. No break-glass accounts: The single most dangerous Conditional Access configuration is no emergency access accounts. Before enabling any policy, verify exclusions.
2. Enabling policies without report-only validation: Report-only costs nothing. A production outage costs everything.
3. Using groups for break-glass exclusions: Group membership can be modified accidentally (or by an attacker). Exclude break-glass accounts by user object directly.
4. Forgetting service principals: Workload identity policies are separate from user identity policies. Service accounts authenticating via legacy protocols need their own migration plan.
5. No naming convention: 40 policies named "New Policy" and "Copy of New Policy" cannot be maintained at 2 AM during an incident.
6. Treating Conditional Access as a one-time project: Business changes, new SaaS tools, acquisitions; quarterly reviews are mandatory.

Frequently Asked Questions

What is Microsoft Entra Conditional Access?

Microsoft Entra Conditional Access is a Zero Trust policy engine built into Microsoft Entra ID (formerly Azure AD) that evaluates every sign-in request against a set of conditions (user identity, device compliance, location, application, and risk signals) and returns a decision: allow, block, or grant with additional requirements such as MFA or a compliant device. It replaces static, per-user MFA enforcement with context-aware, dynamic access control.

What is the difference between MFA and Conditional Access?

MFA (Multi-Factor Authentication) is a verification mechanism: it proves that the person signing in controls a second factor (authenticator app, FIDO2 key, SMS code). Conditional Access is the policy engine that decides *when* to require MFA and what other controls to enforce. You can run MFA without Conditional Access (legacy per-user MFA), but this is inflexible and does not support risk signals or device compliance. The recommended architecture uses Conditional Access to require MFA contextually, based on location, device trust, and risk score.

How do I create a Conditional Access policy in Azure?

Sign in to portal.azure.com, navigate to Microsoft Entra ID > Protection > Conditional Access, and click + New policy. Configure: (1) a descriptive name, (2) Users: select All users and add break-glass exclusions, (3) Target resources: All cloud apps or specific apps, (4) Conditions: optionally configure location, device platform, or risk level, (5) Grant: select grant access and check Require multifactor authentication. Set the policy to Report-only first, monitor Sign-in logs for 48 hours, then switch to On. Full step-by-step walkthrough is in the "Creating Your First Conditional Access Policy" section above.

What is a Conditional Access named location?

A named location is a saved definition of an IP address range (e.g., your corporate network egress IPs) or a set of countries, referenced in Conditional Access policies as a location signal. You can mark IP-based named locations as "trusted". Trusted named locations can be used to relax controls for on-premise users (e.g., skip MFA on the corporate network) or to enforce stricter controls for users outside them (e.g., block all sign-ins from countries where you have no operations). Named locations are configured under Conditional Access > Named locations.

Is Conditional Access available in Azure AD Free?

No. Conditional Access requires Microsoft Entra ID P1 at minimum. The P1 license is included in Microsoft 365 Business Premium, Microsoft 365 E3, Enterprise Mobility + Security E3, and can be purchased as a standalone add-on. Risk-based Conditional Access policies (sign-in risk, user risk) additionally require Microsoft Entra ID P2, which is included in Microsoft 365 E5 and EMS E5. Microsoft Entra ID Free (the default license) includes only Security Defaults: a fixed set of baseline policies that cannot be customized.

What to Configure in [Azure DevOps](/blog/azure-devops-pipelines-beginners-guide) and CI/CD Pipelines

If your organization uses [Azure DevOps](/blog/azure-devops-pipelines-beginners-guide) for CI/CD, your service connections and pipeline identities are service principals that authenticate against Entra ID. These are distinct from user identities and are not covered by user-targeted Conditional Access policies.

For workload identities (service principals and managed identities), Microsoft introduced Workload Identity Conditional Access (preview as of 2026). This allows you to require that service principals only authenticate from specific IP ranges, useful for locking down pipeline service connections to known Azure DevOps agent IPs.

For now, the most practical control is: ensure service principals used in pipelines have the minimum required permissions (principle of least privilege), rotate their credentials on a defined schedule, and monitor their sign-in logs separately from user sign-ins. For the complementary resource governance layer — enforcing what Azure resources those pipelines are allowed to deploy — see [Azure Policy vs Defender for Cloud](/blog/azure-policy-vs-defender-for-cloud-difference), which explains how to prevent misconfigurations at the infrastructure level rather than catching them after deployment.