Contact Us
Support
Partners
Downloads
Cayosoft®
Book a Demo
Blog > Conditional Access Policy Best Practices for Entra ID
  • Cybersecurity

Conditional Access Policy Best Practices for Entra ID

TL;DR 

Microsoft Entra Conditional Access policies evaluate sign-in context like user identity, device state, location, and risk level to enforce controls such as MFA, device compliance, or outright access blocks, with all matching policies applied simultaneously using the most restrictive outcome. Conditional Access best practices include blocking legacy authentication first, requiring phishing-resistant MFA for privileged roles, rolling out policies in stages using report-only mode, and maintaining ongoing governance to catch unauthorized policy changes before they create security gaps.

A single misconfigured Conditional Access policy can silently disable MFA for every admin in your tenant. No alert fires, and no one notices until it’s too late. That’s a real risk when managing identity security in Microsoft Entra ID.

This guide covers how Conditional Access policies work, the conditions driving their decisions, and the Conditional Access best practices you should follow when designing, deploying, and governing them. It provides a structured approach that includes the post-deployment auditing steps most organizations skip entirely.

What Is Conditional Access in Microsoft Entra ID?

Microsoft Entra Conditional Access is the policy engine inside Microsoft Entra ID that evaluates every cloud authentication request and decides what happens next. It functions as a checkpoint between a user completing their first-factor sign-in and actually reaching the resource they requested. It governs identity-layer access decisions based on context, sitting alongside (but not replacing) your firewall and endpoint protection.

How Conditional Access Policies Work

Every Conditional Access policy uses if-then logic. If a specific set of conditions is true at sign-in, then Entra ID enforces a specific set of controls. For example, if a user signs in from an unmanaged device outside the corporate network, you could require MFA and restrict the session to browser-only access. If that same user signs in from a compliant device on a trusted IP range, you might want to grant full access with no additional prompts.

One detail that trips people up is that Conditional Access fires after first-factor authentication, not before. It doesn’t act as a front-line network filter. The user has already proven their identity at least once before a policy even begins to evaluate.

When several Conditional Access policies match a single sign-in, Entra ID evaluates all of them simultaneously and enforces the most restrictive combination. If one policy requires MFA and another requires a compliant device, the user must satisfy both. If any matching policy issues a block, access is denied regardless of what other policies would have granted.

Multiple Conditional Access policies are not processed sequentially. Entra ID enforces the aggregated, most restrictive outcome of all matching policies on every sign-in.

Key Components: Signals, Decisions, and Enforcement

Every Conditional Access policy is built using three components:

  • Signals are contextual inputs like user identity, group membership, device platform, compliance state, client app type, sign-in risk score, named location, and target application.
  • Decisions are binary: Either grant access with conditions attached or block it outright.
  • Enforcement is what Entra ID actually does at the authentication endpoint once it aggregates results from all matching policies.

Signals themselves fall into two categories. Static signals like device platform and client app type don’t change during a session. Dynamic signals, such as sign-in risk and user risk from Microsoft Entra ID Protection, are calculated in real time based on behavioral analysis and threat intelligence. The distinction matters because risk-based policies in Microsoft Entra Conditional Access adapt to changing threat conditions without manual intervention.

Core Conditions That Drive Conditional Access Policy Decisions

The signals that feed into a Conditional Access policy determine whether it triggers at all and what it requires when it does. Getting these conditions right separates a policy set that quietly protects your environment from one that either blocks legitimate work or lets threats slip through unchallenged. 

Identity and Risk-Based Conditions

Two risk signals matter here, and they measure different things:

  • User risk reflects the likelihood that an identity has been compromised. This includes leaked credentials discovered on the dark web or anomalous behavior patterns that develop over time. 
  • Sign-in risk evaluates the specific authentication attempt itself. Is this sign-in coming from an anonymous IP, an impossible travel scenario, or infrastructure tied to known attackers? 

Both signals come from Entra ID Protection, and they update in real time as threat intelligence changes.

One licensing detail that catches teams off guard is that risk-based Conditional Access conditions require Entra ID P2. If you’re on P1, you can still build policies for group membership, device state, and location, but you won’t get the dynamic risk scoring that lets policies tighten automatically when something looks suspicious. For organizations already running Microsoft Purview, there’s also an additional layer available: Insider risk signals can feed into Conditional Access decisions, flagging users whose behavior patterns suggest data exfiltration or policy violations.

Device, Location, and Client App Conditions

Device platform targeting lets you write policies that apply only to iOS, Android, Windows, macOS, or Linux. However, platform detection relies on user-agent strings, which are trivially falsifiable. A policy that says “require a compliant device on Windows” does nothing if it can’t actually verify compliance. That’s why device platform conditions should almost always be paired with Intune compliance checks.

The following table highlights the key differences between static and dynamic conditions.

Condition Type

Examples

Changes During Session?

Requires Entra ID P2?

Device platform

Windows, iOS, Android, macOS

No

No

Client app type

Browser, mobile app, legacy auth

No

No

Named location / trusted IP

Corporate network, country-based ranges

No

No

Sign-in risk

Anonymous IP, impossible travel, malware-linked IP

Yes: evaluated per request

Yes

User risk

Leaked credentials, anomalous behavior over time

Yes: updated continuously

Yes

How Conditions Combine in Practice

Consider a concrete scenario in Microsoft Entra Conditional Access. You create one policy that requires MFA for all users, a second that requires a compliant device for access to SharePoint, and a third that blocks access entirely when sign-in risk is high. When an admin signs in from a compliant laptop with no risk flags, MFA and device compliance are satisfied, and access is granted. When that same admin signs in from an unfamiliar location with a high-risk score, the block policy wins.

Within grant controls specifically, the default behavior is “require all,” meaning that if one policy demands MFA and another demands device compliance, both must be satisfied. You can configure “require one of the selected controls,” but that loosens enforcement and should be used sparingly.

“Block” always wins. If any matching Conditional Access policy issues a block decision, access is denied, regardless of what other policies would have granted.

Conditional Access Best Practices for Microsoft Entra ID

Building a policy set that actually holds up in real-world conditions without locking out half your organization or leaving gaps for attackers to slip through requires discipline. These Conditional Access best practices give you a structured approach to get it right from the start.

Design Policies With a Clear Structure Before You Build

Before you open the Entra admin center, map out your policies. Organize them first by persona: admins, internal employees, guests, and workload identities. Then layer in purpose: baseline protection, app-specific controls, and compliance requirements. This keeps your signal-to-decision logic predictable as the policy count grows.

Give each policy exactly one job. A rule that tries to block legacy authentication and enforce device compliance in the same policy becomes a troubleshooting nightmare the first time something breaks. Use a naming convention and document each policy’s intent directly in its description field, where anyone troubleshooting at midnight can find it.

Block Legacy Authentication and Require MFA First

Your very first Conditional Access policy should block legacy authentication protocols. IMAP, POP3, SMTP, and older Office clients can’t respond to MFA prompts because they were never designed to. Leaving them open is like installing a deadbolt on your front door while leaving the basement window wide open. One dedicated block policy closes an entire class of credential-stuffing and password-spray attacks.

Next, require MFA for all users as a baseline. Standard MFA alone no longer stops determined attackers. Adversary-in-the-middle (AitM) proxy toolkits can steal session tokens even after a user completes MFA successfully. That’s why you should use Authentication Strengths to mandate phishing-resistant methods (FIDO2 security keys, Windows Hello for Business, or certificate-based authentication) for privileged roles and sensitive applications. These are the only methods that defeat AitM token theft.

Protect Privileged Access and Workload Identities Separately

Admin accounts need their own dedicated Conditional Access policies. A blanket “all users” MFA policy doesn’t address the unique risk profile of someone holding Global Administrator or Exchange Administrator privileges. Require compliant or hybrid-joined devices for access to sensitive resources, and enforce phishing-resistant MFA for these roles.

If your Conditional Access policy only targets human users, you’re leaving a significant portion of your authentication surface completely unprotected. Service principals and managed identities need coverage too.

Don’t forget break-glass accounts. Maintain at least two emergency access accounts excluded from blanket policies, place them inside Restricted Management Administrative Units so no well-meaning admin can accidentally modify them, and check at least quarterly that they actually work.

Apply Session Controls Where They Matter Most

Grant controls decide whether someone gets in. Session controls shape what they can do once inside. Set shorter reauthentication windows (one to four hours) for high-risk applications like admin portals, financial systems, or HR platforms. Disable persistent browser sessions for unmanaged devices so closing the browser forces a fresh sign-in. However, leave standard productivity apps like Outlook and Teams on default token lifetimes. Applying aggressive sign-in frequency on a global basis just generates helpdesk tickets without proportional security gain.

Test Before You Enforce, and Roll Out in Stages

Before you deploy, disable Security Defaults. The two features are mutually exclusive in Entra ID, and Entra will block you from creating Conditional Access policies until Security Defaults is turned off. New tenants created after October 22, 2019 typically have it enabled, so verify before you begin and only flip it off once your replacement policies are ready to enable.

Here is the staged rollout sequence that prevents the most common deployment disasters:

  1. Deploy the legacy auth block first in report-only mode, run it for five to seven business days to capture weekday patterns and weekend automation jobs, then switch to enforcement.
  2. Enable baseline MFA for all users once legacy auth is blocked, using the “What If” tool to simulate edge-case sign-in scenarios before going live.
  3. Layer in device compliance policies after MFA stabilizes, targeting managed device requirements for sensitive applications first.

Add app-specific and role-specific controls last, scoping policies to “All cloud apps” rather than individual apps, so new applications automatically inherit protection.

Auditing and Governing Conditional Access Policies at Scale

Getting your Conditional Access policies right is only half the battle. Keeping them right, week after week, change after change, is where most organizations lose ground. This section covers why post-deployment governance deserves as much attention as the initial design.

Why Policy Changes Are as Risky as Policy Gaps

A single unauthorized modification can silently disable MFA for privileged accounts, reopen access from blocked regions, or flip a policy from “On” to “Report-only” without any user-facing indication. The damage isn’t always immediate; sometimes it takes weeks before anyone realizes that the policy state has drifted.

There’s a hybrid complexity layer here too. Conditional Access only applies to cloud-based sign-ins, so organizations syncing on-prem AD to Entra ID must account for gaps where identity trust signals differ between on-premises and cloud-joined endpoints. A quarterly review cadence (validating break-glass accounts, auditing exclusion groups for scope creep, and checking for redundant or conflicting rules) is the minimum that responsible teams should commit to.

Where Native Entra ID Audit Logs Fall Short

What’s described above is the core problem. Was an exclusion group altered? A named location removed? A policy switched to report-only? The log says “policy updated,” but it doesn’t tell you what actually moved. Default audit log retention is also capped at 30 days on most license tiers unless you route data to Log Analytics or a SIEM. Organizations that rely on Active Directory auditing know how quickly gaps like these become blind spots.

The pattern that keeps security teams up at night is that attackers who gain admin access routinely tamper with logs or policy state as a first move. Logs stored inside the compromised environment aren’t a reliable source of truth during incident response. This is the exact problem Cayosoft Guardian Audit & Restore was built to solve.

How Cayosoft Guardian Audit & Restore Closes the Gap

Cayosoft maintains a continuous, independent change history across on-prem AD, Entra ID, and Microsoft 365, recording who changed what, when, and what the previous value was. Because the change record lives outside the monitored environment, it remains intact even when native logs have been cleared or compromised. This kind of independence is especially critical for teams managing hybrid AD environments where changes can ripple across both on-prem and cloud directories.

The following table breaks down the key differences between what native Entra ID audit logs provide and what Cayosoft Guardian Audit & Restore delivers.

Capability

Native Entra ID Audit Logs

Cayosoft Guardian Audit & Restore

Attribute-level change detail

No: logs “policy modified” only

Yes: captures before and after values

Default retention

30 days (without SIEM routing)

Configurable, long-term retention

Tamper resilience

Logs reside inside the compromised tenant

Independent change record outside the tenant

Instant rollback

Not available

Granular object and attribute recovery

Hybrid AD + Entra ID coverage

Cloud sign-ins only

Unified across on-prem AD, Entra ID, and M365

The agentless deployment means most teams are monitoring within hours, not weeks. If someone modifies a Conditional Access policy, accidentally or otherwise, you get the alert in real time and can roll back the change before it creates exposure. Schedule a demo to see how your team can benefit from that kind of visibility and control.

Building a Conditional Access Foundation You Can Trust

Conditional Access policies are only as strong as the governance wrapped around them. You can design an excellent policy set that blocks legacy authentication, enforces phishing-resistant MFA, and segments privileged access, and still end up exposed if nobody notices when an exclusion group gets quietly expanded, or a policy gets switched to report-only. The technical configuration is where things begin. The discipline of auditing, reviewing, and validating those configurations over time is what actually keeps your tenant secure.

FAQs

No. MFA is one specific control that a Conditional Access Policy can enforce, but Conditional Access is the broader decision engine that determines when MFA is required and what other controls, such as device compliance or session restrictions, should also apply.

It reduces the attack surface by automatically blocking risky sign-ins, requiring stronger authentication for sensitive resources, and restricting what users can do based on real-time signals like location, device health, and threat intelligence. This layered approach stops common attack techniques like credential stuffing and session token theft before they reach critical systems.

A break-glass account is an emergency access account excluded from all Conditional Access policies, used only when normal admin accounts are locked out. Without at least two tested break-glass accounts, a misconfigured policy can lock your entire team out of the tenant with no recovery path.

Report-only mode lets a policy evaluate sign-ins and log what would have happened (blocked, granted, or prompted for MFA)  without actually enforcing anything. It’s the safest way to validate a policy’s impact before turning it on.

Natively, no. Entra ID doesn’t offer a rollback function, so you’d need to manually reconstruct the previous policy state. Purpose-built tools like Cayosoft Guardian Audit & Restore maintain a full change history and can restore a policy to any previous state instantly.

See Cayosoft in Action

Get A Demo

Cayosoft is recognized by Gartner as an ITDR solution provider and provides solutions that make identities more resilient to attacks and guarantee a fast forest recovery, if needed. Learn how Cayosoft Guardian facilitates granular change tracking, post-breach analysis, and long-term AD security improvements. Schedule a demo to see the capabilities in depth.