Conditional Access Explained

Modern enterprises can’t afford to rely on static, one-size-fits-all access controls. With users signing in from different devices, locations, and risk contexts, security needs to adapt dynamically.

Conditional Access is Microsoft Entra ID’s Zero Trust policy engine that checks who’s signing in, from where, on what device, and under what risk conditions, then decides whether to allow, block, or require extra verification such as multi-factor authentication (MFA) or a compliant device.

In fact, Microsoft’s Digital Defense Report 2024 revealed that 99% of identity attacks still exploit passwords, while only 41% of organizations have adopted strong, phishing-resistant authentication methods.

In 2025, Conditional Access has evolved beyond basic sign-in checks, introducing Continuous Access Evaluation (CAE) and deeper Intune integration for real-time device compliance and session enforcement.

This intelligent, signal-based approach makes Conditional Access the backbone of identity-driven security and a cornerstone of any Zero Trust architecture.

What is Conditional Access?

Conditional Access (CA) is an adaptive security framework that governs how and when users can access corporate resources based on predefined conditions. Acting as a gatekeeper, CA evaluates multiple factors before determining whether an access request should be granted, challenged, or denied.

Built on the principle of least privilege access, CA ensures that users receive only the minimum level of access required for their role. This significantly reduces the risk of unauthorized access, insider threats, and credential-based attacks.

Key decision factors in Conditional Access include:

• User identity: Who’s logging in – an employee, contractor, or third party?
• Device compliance: Is the device managed, encrypted, and updated?
• Network context: Is access coming from a trusted corporate network or an unfamiliar location?
• Application sensitivity: Is the user accessing a general internal portal or a highly confidential app?
• Risk score: Are there unusual patterns, like failed login attempts?

Access is granted only when all specified conditions are met, preventing unauthorized or risky attempts from reaching critical data.

By enforcing context-aware authentication, Conditional Access helps organizations protect data, prevent unauthorized access, and enhance security without disrupting productivity.

This impact is amplified when integrated with Unified Endpoint Management (UEM), which ensures that only compliant and secure devices can connect to corporate networks, adding an extra layer of enforcement to access decisions.

How Conditional Access works in Microsoft Entra ID

Traditional access controls assume that once a user logs in, they’re safe. Conditional Access takes a Zero Trust approach, treating every sign-in as untrusted until verified.

Step 1: Signal evaluation

Conditional Access evaluates multiple signals at every sign-in attempt and, with Continuous Access Evaluation (CAE) enabled, even mid-session:

• User and group identity: Who is trying to access the resource and what privileges do they hold?
• Device compliance status: Is the device managed and compliant through Microsoft Intune or UEM tools like Hexnode?
• Location and network: Is the sign-in request coming from a trusted network or region?
• App or resource type: What cloud application or service is being accessed?
• Sign-in risk: Are there any abnormal behaviors, such as unfamiliar devices or impossible travel patterns, detected by Microsoft Entra ID Protection?

Step 2: Policy decision

Based on these signals, Conditional Access enforces contextual controls, such as:

• Requiring MFA or device compliance
• Limiting session duration or access to sensitive apps
• Blocking risky or noncompliant sign-ins

The Conditional Access decision flow

Conditional Access policies follow a structured process inside Microsoft Entra ID, guiding how you assign users, define conditions, and apply access or session controls.

Each layer narrows who, what, and how the policy applies.

1. Assignments

Define who and what the policy targets:

• Users or groups
• Directory roles (Admins, Support Engineers)
• Cloud apps (Microsoft 365, Salesforce, etc.)
• User actions (like registering security info)

2. Conditions

Add contextual filters such as:

• Device platform (Windows, iOS, macOS, Android)
• Sign-in risk level (low, medium, high – via Entra ID Protection)
• Client app type (browser, legacy, modern)
• Location/network (trusted IPs, geofencing)
• Device filters (managed vs unmanaged)

3. Access controls

Define what happens when conditions are met:

• Allow or Block access
• Require:
  • MFA
  • Compliant/hybrid-joined device
  • Approved client app
  • Terms of use acceptance

4. Session controls

Manage risk during active sessions:

• Adjust sign-in frequency
• Enable/disable persistent browser sessions
• Apply App Enforced Restrictions (limited browser access)
• Use App Control via Microsoft Defender for Cloud Apps

Top Conditional Access policy examples

Once you understand the Conditional Access flow, you can start building policies that enforce identity and device security in the real world.

Here are a few tried-and-tested examples you can copy and adapt for your organization.

1. Require MFA for admin roles

Goal: Protect high-privilege accounts from credential compromise.
Setup:

• Assignments: All privileged roles (Global Admin, Security Admin, etc.)
• Controls: Require MFA and/or compliant device
• Session: Disable persistent browser sessions; re-authenticate every 8-12 hours.

✅ Best for: Preventing lateral movement in attacks targeting admin accounts.

Reinforcing cybersecurity with Multi-Factor Authentication (MFA)

2. Block legacy authentication

Goal: Eliminate insecure protocols that bypass modern Conditional Access.
Setup:

• Assignments: All users
• Conditions: Client app = “Other clients/legacy protocols”
• Controls: Block access

✅ Best for: Closing password-only authentication gaps in Exchange, POP, IMAP.

️3. Require compliant device for Microsoft 365

Goal: Allow access only from devices that meet your organization’s security baseline.
Setup:

• Assignments: All users; apps = Microsoft 365, Exchange, SharePoint, Teams
• Controls: Require device to be marked as compliant (via Intune or Hexnode UEM)

✅ Best for: Enforcing device hygiene and data protection on mobile and desktop endpoints.

4. Step-up MFA for risky sign-ins

Goal: Add adaptive authentication based on sign-in risk.
Setup:

• Assignments: All users
• Conditions: Sign-in risk = medium or higher (requires Entra ID Protection)
• Controls: Require MFA at medium risk; block at high risk

✅ Best for: Balancing user experience and security with adaptive friction.

5. Require access controls for workload identities (Advanced)

Goal: Control access for non-user identities like Service Principals, which can be just as powerful as admin accounts.
Setup:

• Assignments: Target Workload Identities (instead of Users/Groups)
• Conditions: Location (Block from unfamiliar locations)
• Controls: Block Access

✅ Best for: Preventing compromise of service accounts used by automation or backend services. (Requires Entra ID P1/P2)

Quick reference: Common Conditional Access policies

Benefits of Conditional Access for enterprises

Conditional Access brings clarity and control to identity-driven security, balancing protection, compliance, and usability.

Key Benefits

• Adaptive security: Responds to risk in real time with Continuous Access Evaluation (CAE), ensuring that policy decisions evolve as conditions change.
• Unified policy engine: Enforces consistent Zero Trust access rules across all users, devices, and applications from Microsoft 365 to third-party SaaS.
• Enhanced user experience: Reduces unnecessary prompts by granting access only when context demands additional verification.
• Stronger compliance posture: Maintains device and identity hygiene across managed and unmanaged endpoints through integrations with Intune or UEM tools like Hexnode.
• Simplified management: Centralizes access decisions, eliminating scattered MFA rules or inconsistent app-level permissions.
• Faster incident response: Instantly blocks or limits risky sessions when suspicious behaviour or device drift is detected.

Conditional Access vs MFA: What’s the difference?

Multi-Factor Authentication (MFA) and Conditional Access are closely related, but they serve very different purposes within Microsoft Entra ID’s Zero Trust framework.

MFA is an authentication method, it verifies a user’s identity using multiple factors (something they know, have, or are).

Conditional Access, on the other hand, is a policy engine that decides when MFA or other access requirements should apply, based on contextual signals like risk level, device compliance, and location.

Conditional Access and device compliance (Intune + UEM)

Conditional Access depends heavily on device compliance data to make risk-based decisions.

That’s where Intune and UEM platforms like Hexnode come in.

How device compliance powers Conditional Access

Conditional Access policies can require that a device be “marked as compliant” before a user can access Microsoft 365 or other cloud apps.

This compliance state is determined by the UEM platform, which evaluates factors such as:

• OS version and patch status
• Encryption and secure boot configuration
• Presence of endpoint protection or EDR
• Jailbreak/root detection
• Configuration policy adherence

If a device meets the defined baseline, Intune (or the integrated UEM) reports it as compliant, allowing Conditional Access to grant access seamlessly. Noncompliant or unmanaged devices can be prompted for remediation or blocked entirely.

Beyond Microsoft Intune: Extending compliance with Hexnode

While Microsoft Intune handles compliance for enrolled Windows and mobile devices, Hexnode UEM extends that control to a broader range of endpoints across the enterprise.

It can:

• Sync compliance posture into Microsoft Entra ID for unified enforcement.
• Manage non-Microsoft endpoints (macOS, Android, iOS, Linux) that still participate in Conditional Access evaluations.
• Provide real-time device posture visibility, ensuring that unmanaged or noncompliant devices are restricted from corporate resources.

By combining Hexnode’s endpoint intelligence with Microsoft Entra Conditional Access, organizations achieve a truly device-aware Zero Trust framework – one that adapts dynamically to both user identity and device health.

When possible, pair “Require device to be marked as compliant” with risk-based access. Trusted users enjoy frictionless access, while high-risk endpoints trigger MFA or blocking.

Best practices for rolling out Conditional Access policies

Implementing Conditional Access across your organization is a phased process. Start simple, validate policies, and expand gradually to avoid lockouts or user friction.

Here’s a best-practice rollout sequence to help you deploy with confidence.

1. Start with admin MFA enforcement
   Protect your most privileged accounts first.
   • Create a policy targeting Global Admins and other high-privilege roles.
   • Require MFA and compliant devices for all sign-ins.
2. Block legacy authentication
   • Disable outdated protocols like POP, IMAP, and SMTP AUTH that bypass Conditional Access controls.

   This single step removes one of the biggest identity attack surfaces.

3. Require device compliance for key apps
   • Enforce that only Intune- or Hexnode-compliant devices can access Microsoft 365, Exchange, and Teams.

   Keeps data protected on endpoints that meet your security baseline.

4. Add risk-based policies
   • Integrate with Microsoft Entra ID Protection to dynamically require MFA or block sign-ins based on user risk, location, or device posture.

   Introduces adaptive access without increasing user friction.

5. Pilot in “Report-only” mode
   Always deploy new Conditional Access policies in Report-only mode first.
   • Monitor sign-in logs and adjust conditions before turning enforcement on.
6. Monitor sign-in logs and adjust conditions before turning enforcement on.
   Start with critical apps, then extend organization-wide.
   • CAE ensures real-time enforcement when risk, device state, or location changes.
7. Governance Tip: Use a Consistent Naming Standard
   A good naming convention is vital for governance and troubleshooting. It should immediately communicate the policy’s action and target.
   • Recommended Format: CA-[TargetGroup]-[Condition]-[Control]

   Example	Purpose
   CA-Admins-MFA-Compliant	Admins, Require MFA + Compliant Device
   CA-Finance-TrustedLocation-MFA	Finance Users, Trusted Location, Require MFA

8. Integrate with PIM for Just-in-Time Access
   • For the highest level of security, pair your administrative CA policy with Microsoft Entra Privileged Identity Management (PIM).

   PIM ensures that users only receive their privileged roles (like Global Administrator) on a time-bound, “just-in-time” basis.

   Your CA policy can then be configured to only apply when a user has an active PIM role assignment, eliminating standing access and enforcing a true least-privilege model.

Summary checklist

Common pitfalls and how to avoid them

Even well-planned Conditional Access deployments can stumble if key configurations are overlooked.

Here are some of the most common mistakes and how to sidestep them.

• Overlapping policies = inconsistent MFA prompts
  Multiple policies targeting the same user or app can trigger redundant MFA requests or conflicting grant controls.
• Advanced Pitfall: The Cumulative “AND” Effect
  Conditional Access policies are cumulative, meaning when multiple policies apply to a single user’s sign-in, the user must satisfy the requirements of all applicable policies.
  This operates on a logical AND rule.
  Example:
  • • Policy A: Applies to User X, requires MFA.
    • Policy B: Applies to User X, requires a compliant device.

  Result: User X must complete MFA and sign in from a compliant device.

  Solution: Use the “What If” tool in the Microsoft Entra admin center to simulate combined effects and preview the final grant controls before enforcing policies.

  This helps prevent unexpected blocks and redundant authentication prompts.

The “What If” Tool in Action

The Microsoft Entra “What If” Tool helps administrators test Conditional Access policies before rollout by simulating real-world sign-in conditions.
How it works:

1. 1. Select parameters like user, device platform, app, location, and risk level.
   2. The tool identifies which policies apply to that scenario.
   3. It then reveals the final grant decision – Allow, Require MFA, or Block, showing exactly how multiple policies interact.

Microsoft Entra “What If”
Why it matters:
This visualization helps predict cumulative “AND” effects, reduce unexpected MFA prompts, and validate your configuration before enforcement.

1. Forgetting “break-glass” accounts
   Locking out emergency admin accounts can cut off all administrative access.Solution: Maintain at least one highly secure account excluded from Conditional Access, stored offline and MFA-protected.
2. Legacy clients bypassing modern authentication
   Older mail or sync apps using POP, IMAP, or ActiveSync may ignore Conditional Access entirely.Solution: Block legacy authentication protocols organization-wide.
3. Incorrect device compliance sync Delays or errors in UEM-Intune sync can cause compliant devices to appear noncompliant.Solution: Check sync intervals, enforce Intune/Hexnode compliance policy refresh, and monitor reporting logs.
4. Untrusted locations misconfigured Missing or incorrect IP ranges can mark corporate networks as risky.Solution: Regularly review Named Locations in Entra ID and update IP ranges for offices, VPNs, and data centers.

❓ Frequently Asked Questions (FAQs)

? Conditional Access is Microsoft Entra ID’s zero trust policy engine.

It evaluates signals like user identity, device compliance, location, and sign-in risk to decide whether to allow, block, or require additional verification (like MFA).

? How is Conditional Access different from MFA?

MFA is a verification method – it checks who you are.

Conditional Access is a policy layer – it decides when and under what conditions MFA (or other controls) should apply.

? What is Continuous Access Evaluation (CAE)?

Continuous Access Evaluation (CAE) reassesses access in real time.

If a user’s location, risk, or device state changes, CAE can revoke or limit access instantly, reducing the window for compromised sessions.

? Can Conditional Access require a compliant device?

Yes. Conditional Access integrates with Intune and UEM tools like Hexnode to enforce the “Require device to be marked as compliant” control before granting access to Microsoft 365 or SaaS applications.

? Should I still use per-user MFA?

No, Microsoft recommends migrating from per-user MFA to Conditional Access-based MFA policies.

This approach is more flexible, context-aware, and consistent with the Zero Trust model.

Wrapping up

Conditional Access sits at the core of modern identity security, the decision engine that ensures only the right users, on trusted devices, under the right conditions, can reach corporate resources.

By combining Microsoft Entra ID’s adaptive policy framework with device compliance signals from management platforms like Intune and Hexnode UEM, organizations can achieve true Zero Trust enforcement across users, apps, and endpoints.

Hexnode UEM strengthens this ecosystem by extending Conditional Access coverage to every device platform – Windows, macOS, iOS, Android, and beyond.

It simplifies compliance verification, unifies device posture data, and helps security teams implement Conditional Access confidently, without friction.