Microsoft Entra Conditional Access: A Practical Guide

Conditional Access is Microsoft Entra ID's policy engine for evaluating context, not just credentials, before granting access — the mechanism that turns "MFA is enabled" into "MFA is required specifically when the sign-in looks risky, from an unmanaged device, or from outside expected locations." This guide covers how Conditional Access policies are structured, common policy patterns, and how to avoid the single most common rollout mistake: locking administrators out of their own tenant.

What Conditional Access actually evaluates

A Conditional Access policy is built from signals (who, what, where, and how someone is signing in) and a resulting decision (grant, block, or grant-with-requirements). Every policy follows the same basic structure:

A policy might read, in effect: "For all users, accessing all cloud apps, from outside the corporate network, require MFA." Or more specifically: "For administrative roles, accessing any application, from any location, require a compliant device and MFA."

Common policy patterns

1. Require MFA for all users, all applications. The baseline every tenant should have — this is often what "MFA is enabled" actually means operationally.
2. Require a compliant or hybrid-joined device for access to sensitive applications. Ensures access only comes from devices meeting the organization's own security baseline (patched, encrypted, managed), not just from any authenticated browser.
3. Block legacy authentication protocols entirely. Legacy protocols (older mail clients, certain API-based sign-ins) don't support modern authentication and therefore can't enforce MFA — blocking them closes a well-known bypass path.
4. Require stronger authentication for administrative roles specifically. Privileged roles warrant phishing-resistant MFA (hardware key or platform authenticator) rather than the standard method used for general staff — see Privileged Identity Management and Privileged Access.
5. Block or restrict access from unexpected locations, either as an outright block for countries with no legitimate business presence, or as a trigger requiring additional verification.
6. Require re-authentication on a defined session frequency for high-risk applications, rather than trusting an indefinitely long session.

How to roll out Conditional Access without locking yourself out

The single most common Conditional Access incident is an administrator applying a new policy tenant-wide and immediately losing their own access — because the policy's conditions unexpectedly matched their own sign-in.

1. Always configure new policies in Report-only mode first. This mode evaluates the policy and logs what would have happened without actually blocking or requiring anything — giving visibility into real-world impact before enforcement.
2. Review Report-only sign-in logs for at least several days before switching a policy to enforced, checking for legitimate sign-ins that would have been blocked.
3. Always maintain at least one documented, monitored break-glass account excluded from Conditional Access policies, specifically to recover tenant access if a policy misconfiguration locks out standard administrative accounts. See Privileged Identity Management and Privileged Access for how to secure break-glass accounts properly — excluded from policy does not mean weakly protected.
4. Roll out to a pilot group before the full tenant, especially for device-compliance-based policies, which depend on device enrollment status that may not be complete organization-wide yet.
5. Document every active policy's intent, not just its technical configuration — a policy with no documented rationale is difficult to safely modify or retire later.

Policy conflicts and the "most restrictive wins" principle

When multiple Conditional Access policies apply to the same sign-in, Entra ID applies the combination of all their grant controls — if one policy requires MFA and another requires a compliant device, both requirements apply. This means policies should be reviewed holistically, not just individually, since the interaction between several reasonable-looking policies can produce an access requirement no single policy author intended (or, in a misconfiguration, an unintended block).

Common mistakes

• Applying a new policy directly in enforced mode instead of Report-only first — the leading cause of self-inflicted lockouts.
• No break-glass account excluded from all policies, leaving no recovery path if a policy change blocks normal administrative access.
• Break-glass accounts that are excluded from policy but otherwise weakly protected — exclusion from Conditional Access should be paired with strong credentials and close monitoring, not treated as a convenient bypass.
• Hardcoding IP ranges directly into multiple policies instead of using named locations, making future updates error-prone.
• Never reviewing policies after initial rollout, letting them drift out of alignment with how the organization actually operates (new offices, new applications, changed device fleet).

FAQ

What's the difference between Conditional Access and MFA itself? MFA is an authentication method; Conditional Access is the policy engine that decides when to require it (and what else to require — device compliance, location restrictions) based on context. MFA can be turned on via Security Defaults without Conditional Access, but Conditional Access provides the granular, context-aware control most organizations actually need.

Can Conditional Access block sign-ins entirely, not just add requirements? Yes — a policy's grant control can be set to "Block access" rather than "Grant access with requirements," commonly used for known-risky conditions like specific countries with no legitimate business need or sign-ins flagged as high risk by Identity Protection.

How many break-glass accounts should an organization maintain? Commonly two, stored and monitored per a documented emergency-access procedure — enough for redundancy without creating unnecessary additional attack surface. Both should be excluded from Conditional Access policies specifically, monitored for any sign-in activity (which should be rare/emergency-only), and secured with strong, unique credentials.

Does Conditional Access require a specific Microsoft 365 license tier? Conditional Access itself requires Entra ID P1 or higher (included in several Microsoft 365 business/enterprise bundles); Security Defaults provide a more limited, non-customizable MFA baseline available without that add-on. Confirm current licensing requirements directly with Microsoft, since tier structures are periodically revised.

Related reading

• Multi-Factor Authentication: Methods and Best Practices
• Privileged Identity Management and Privileged Access
• Microsoft Password Best Practices
• Conditional Access Best Practices (Microsoft 365-specific patterns)
• Conditional Access Policy Analyzer (reviewing an existing policy set)
• PCI DSS 4.0 Overview — Conditional Access as a Requirement 8 access control implementation
• Download: Conditional Access Policy Worksheet
• Download: Conditional Access Planning Workbook
• Conditional Access Planner tool