Conditional Access Explained: 4 Key Components and 4 Common Policies

What Is Conditional Access?

Conditional access is a security policy engine that uses real-time signals (like user identity, device health, location, and risk level) to decide whether to grant, block, or limit access to applications and data. A policy can allow access, block it, or require additional controls such as multifactor authentication or a compliant device. For example, an organization can require multifactor authentication when a user signs in from an unfamiliar location while allowing normal access from a managed corporate device.

How it works:

• Identity and authentication: Verifies the user and applies policies based on identity, group, role, or authentication method.
• Device trust and security posture: Checks whether the device is managed, compliant, encrypted, registered, or otherwise trusted.
• Context and risk evaluation: Evaluates signals such as location, IP address, application, sign-in behavior, and detected risk.
• Policy-based access decision: Compares the request with configured policies to allow, block, or require additional controls such as MFA.
• Access and session enforcement: Applies session restrictions and can require reauthentication or terminate access if conditions change.

Key components:

• Assignments (who and what): Targets specific users, groups, cloud apps, or actions.
• Conditions (the context): Evaluates real-time data, including device platform (Windows, iOS, Android), IP location, and sign-in risk.
• Access controls (the decision): Grants access, requires extra verification like MFA, or blocks entry.
• Session controls: Limits what a user can do after logging in, such as restricting downloads or forcing frequent re-authentication.

This is part of a series of articles about DLP

Why Is Conditional Access Important? 

Conditional access is important because it helps organizations make access decisions based on risk, context, and security requirements rather than relying only on passwords or network location. It supports stronger identity protection, enables Zero Trust principles, and helps secure modern work environments such as remote access and BYOD.

• Enables context-aware access control: Conditional access evaluates signals such as user identity, device compliance, location, application, and sign-in risk to allow, block, or require extra verification such as multifactor authentication.
• Supports Zero Trust security: It helps enforce Zero Trust by requiring verified identity, trusted devices, approved apps, or other controls before granting access to sensitive resources.
• Strengthens BYOD and remote work security: Conditional access applies different requirements to managed, unmanaged, and noncompliant devices, helping protect corporate data while still supporting flexible access.

How Does Conditional Access Fit into a Zero Trust Strategy?

Conditional access supports Zero Trust by evaluating each access request instead of assuming that a user or device can be trusted based on network location or a previous sign-in. It uses signals such as identity, authentication strength, device compliance, location, application, and risk to determine whether the request meets security requirements. Access can then be allowed, blocked, or subjected to additional controls such as MFA or device compliance checks.

This approach helps organizations apply the Zero Trust principles of explicit verification and least-privilege access. A user may receive normal access from a compliant corporate device but face stronger requirements when using an unmanaged device or attempting a risky sign-in. Conditional access can also restrict sessions or require reauthentication as conditions change, reducing reliance on permanent trust after the initial authentication.

How Does Conditional Access Work? 

Identity and Authentication

The process starts when a user attempts to sign in to an application or service. The identity provider verifies the user’s identity using credentials, authentication tokens, multifactor authentication, passwordless authentication, or other configured methods.

Identity information also provides input for policy evaluation. For example, policies may apply differently based on the user’s group, role, department, or administrative privileges. Privileged accounts can therefore be subject to stricter controls than standard user accounts.

Device Trust and Security Posture

Conditional access can determine whether the requesting device meets the organization’s security requirements. Relevant signals may include whether the device is registered, managed, compliant, encrypted, or running a supported operating system.

Device posture helps distinguish trusted corporate endpoints from unmanaged or potentially compromised devices. A policy might allow full access from a compliant managed laptop while limiting or blocking the same request from an unknown personal device.

Context and Risk Evaluation

The system evaluates contextual signals associated with the access request. These can include network location, IP address, application, geographic location, sign-in behavior, and detected identity or sign-in risk.

Risk information can make policies adaptive rather than static. A routine sign-in may proceed normally, while an unusual sign-in can trigger multifactor authentication or be blocked entirely. The available risk signals depend on the conditional access platform and its security integrations.

Policy-Based Access Decision

The collected signals are compared with configured conditional access policies. Each policy defines conditions that determine when it applies and specifies the controls required when those conditions are met.

The resulting decision can allow access, block access, or require additional controls. For example, access to a sensitive application might require both multifactor authentication and a compliant device. Multiple applicable policies may contribute requirements to the final decision.

Access and Session Enforcement

After the policy requirements are satisfied, the system grants access and applies any required restrictions. These restrictions can affect what the user can do during the session, such as downloading files, using specific applications, or maintaining a session for a certain period.

Enforcement can also continue after the initial sign-in. Depending on the platform, changes in account risk, device compliance, or session conditions can trigger reauthentication or termination of access. This helps prevent an initially valid session from remaining trusted indefinitely.

Key Components of Conditional Access 

1. Assignments (Who and What)

Assignments define the identities and resources covered by a conditional access policy. They can include specific users, groups, roles, applications, or other protected resources supported by the identity platform.

For example, an organization might apply a policy to all administrators accessing management applications or to employees accessing a financial system. Policies can also contain exclusions for accounts or groups that should not be affected.

Assignments should be kept as specific as practical. Broad assignments can simplify management, but they can also create unintended access restrictions if exclusions and application dependencies are not understood.

2. Conditions (The Context)

Conditions define the circumstances under which a policy applies. Common signals include device platform, network location, client application, device state, and identity or sign-in risk.

For example, a policy might apply when a user accesses an application from outside an approved network or uses an unmanaged device. Multiple conditions can be combined to target more specific access scenarios.

The available conditions depend on the identity platform and connected security services. Because some signals can be incomplete or change during a session, important decisions should generally use several relevant signals rather than relying on a single condition.

3. Access Controls (The Decision)

Access controls specify what must happen when a request matches the policy. The system can block access completely or require the user to satisfy one or more requirements before access is granted.

Common requirements include MFA, a compliant device, an approved client application, or a specific authentication strength. Several controls can sometimes be combined so that users must meet multiple requirements.

Access controls should reflect the sensitivity and risk of the protected resource. Blocking access may be appropriate for clearly unacceptable conditions, while additional verification can provide a less disruptive response to moderate risk.

4. Session Controls

Session controls determine how access is handled after authentication succeeds. Instead of deciding only whether a user can enter an application, these controls can restrict what the user can do or how long the session remains valid.

Depending on the platform, session controls can limit session duration, require periodic reauthentication, restrict downloads, or enforce application-level protections. They are particularly useful when users access corporate resources from unmanaged devices.

Session controls can also reduce the risk associated with long-lived sessions. Requiring authentication again after a defined period or responding to changes in risk helps ensure that previously granted access does not remain valid indefinitely.

Related content: Read our article about data leakage.

Common Conditional Access Policies 

The following table summarizes common conditional access policies used in organizations. We explore each type of policy in more detail below.

Policy	Primary Signal	Typical Access Decision	Common Use Case	Key Considerations
Require multi-factor authentication	User identity, authentication context, sign-in risk	Require MFA before granting access	Protect privileged accounts and sensitive applications	Balance authentication strength with unnecessary MFA prompts
Require a trusted or compliant device	Device management and compliance status	Allow access only from devices meeting security requirements	Protect sensitive applications from insecure endpoints	Define compliance requirements and remediation processes
Block access from high-risk locations	Geographic location, IP address, network	Block access or require stronger verification	Restrict unexpected or higher-risk sign-in locations	Location can be affected by VPNs, proxies, and mobile networks
Restrict access from unmanaged devices	Device management status	Block access or allow a restricted session	Support BYOD and external users while limiting data exposure	Decide which applications and actions unmanaged devices can access

1. Require Multi-Factor Authentication

This policy requires users to complete multi-factor authentication (MFA) before accessing specified applications or resources. It can apply to every sign-in or only under defined conditions, such as privileged access, unfamiliar locations, or elevated sign-in risk.

Why this policy is important: Passwords can be stolen through phishing, credential reuse, malware, and other attacks. Requiring an additional authentication factor makes compromised credentials less useful because the attacker must satisfy another verification requirement before gaining access.

Key considerations:

• Apply stronger authentication requirements to privileged accounts and sensitive applications.
• Decide whether MFA should apply continuously or only when specific risk conditions occur.
• Select authentication methods appropriate to the sensitivity of the resource.
• Plan recovery procedures for users who lose access to an authentication factor.
• Monitor MFA failures and repeated prompts that may indicate attacks or configuration problems.

2. Require a Trusted or Compliant Device

This policy grants access only when a device meets defined security requirements. Compliance signals can include device registration, management status, operating system version, encryption, screen-lock configuration, and endpoint protection.

Why this policy is important: Valid user credentials do not guarantee that the device requesting access is secure. Requiring device compliance reduces the chance that sensitive applications and data will be accessed from endpoints that are outdated, compromised, or missing required security controls.

Key considerations:

• Define which security requirements make a device compliant.
• Integrate conditional access with the system responsible for evaluating device compliance.
• Apply stricter device requirements to sensitive applications and administrative systems.
• Define what happens when a previously compliant device becomes noncompliant.
• Provide a remediation process so users can restore device compliance and regain access.

3. Block Access from High-Risk Locations

This policy blocks access or requires stronger verification when requests originate from specified locations or networks. Organizations can evaluate countries, regions, IP address ranges, anonymous networks, and known trusted network locations.

Why this policy is important: Location can provide useful context for identifying access that falls outside expected operating patterns. Blocking locations where an organization does not operate, or applying additional controls to unusual locations, can reduce exposure to unauthorized access attempts.

Key considerations:

• Define trusted and restricted locations based on actual business requirements.
• Account for employees who travel or work remotely.
• Consider how VPNs, proxies, and mobile networks affect source location.
• Avoid using location as the only indicator of whether a request is trustworthy.
• Combine location with identity, device, authentication, and risk signals where possible.

4. Restrict Access from Unmanaged Devices

This policy limits what users can access or do when connecting from devices that the organization does not manage. Depending on the resource, an unmanaged device can be blocked completely or permitted limited browser-based access with additional session restrictions.

Why this policy is important: Organizations have less control over patching, encryption, endpoint protection, local storage, and other security settings on unmanaged devices. Restricting these endpoints reduces the risk that corporate information will be downloaded, synchronized, printed, or otherwise stored outside controlled environments.

Key considerations:

• Identify which applications and data can safely be accessed from unmanaged devices.
• Distinguish between managed, unmanaged, and noncompliant devices where supported.
• Consider limited browser access instead of blocking every unmanaged device.
• Restrict downloads, synchronization, printing, or other data movement when appropriate.
• Define separate requirements for BYOD users, contractors, temporary workers, and other external users.

Conditional Access Challenges 

Complex Policy Management

Conditional access environments can contain many policies covering different users, groups, applications, devices, locations, and risk levels. As the number of policies increases, administrators may find it difficult to understand which rules apply to a particular sign-in. Policy complexity also makes changes harder to assess. A new requirement for one application might affect users already covered by broader policies. 

How to overcome: Using clear naming conventions, documented policy scopes, and staged testing can make large policy sets easier to maintain. Organizations should also remove obsolete policies and periodically review exclusions. Otherwise, temporary exceptions can remain active long after they are needed and create unintended paths around security controls.

Related content: Read our guide to building a DLP policy.

Limited Visibility into Device Risk

Conditional access decisions are only as reliable as the device information available to the system. Managed devices can usually report compliance status and security configuration, but unmanaged or partially managed devices may provide much less information. A device marked as registered or compliant is also not necessarily free from active threats. Malware, stolen sessions, or newly discovered vulnerabilities may not immediately change its compliance status. 

How to overcome: Conditional access may need data from endpoint detection, device management, and identity protection systems to make better decisions. Organizations should avoid treating a single device attribute as sufficient evidence of trust. Combining device posture with authentication strength, user risk, and session monitoring provides stronger protection.

Policy Conflicts and Misconfiguration

Overlapping policies can produce unexpected access requirements. For example, one policy might allow access from a particular device type while another applicable policy requires additional authentication or blocks the same request under certain conditions. Misconfiguration can also cause widespread lockouts. Incorrect group assignments, application scopes, network locations, or exclusions can affect more users than intended. Policies that appear correct individually may behave differently when evaluated together.

How to overcome: Testing changes against representative users and applications helps identify these problems before enforcement. Policy simulation, report-only modes, sign-in logs, and emergency access procedures can also reduce the operational impact of configuration mistakes.

Supporting Users Across Multiple Platforms

Users may access resources from Windows, macOS, Linux, Android, iOS, browsers, and specialized applications. These platforms do not always expose the same device information or support the same authentication and session controls. A policy that works for a managed desktop application may behave differently in a browser or mobile client. Legacy applications can create additional problems if they use authentication protocols that cannot satisfy modern requirements such as MFA.

How to overcome: Organizations need to test important access scenarios across supported platforms before deploying policies broadly. Where equivalent controls are unavailable, they may need platform-specific policies, restricted access, or alternative security controls to maintain a consistent security level.

Conditional Access Best Practices 

Combine Conditional Access with Strong MFA

Conditional access determines when additional authentication is required, while multi-factor authentication (MFA) provides the additional identity verification. Combining the two reduces the risk that an attacker can access resources using only a compromised password.

MFA requirements can be stronger for sensitive scenarios. Administrator access, high-risk sign-ins, and critical applications can require phishing-resistant methods such as security keys or passkeys when the identity platform supports them.

Organizations should also reduce reliance on weaker authentication methods where practical. Conditional access policies cannot provide strong identity protection if users can satisfy them with authentication methods that are easy to intercept or bypass.

Use Device Trust as an Access Signal

Device state provides useful context when deciding whether access should be granted. Policies can consider whether a device is managed, registered, encrypted, patched, and compliant with organizational security requirements.

For example, a compliant corporate laptop can receive full access to sensitive resources, while an unmanaged device receives restricted browser access. Devices that fail required security checks can be blocked until the problem is corrected.

Device trust should not be treated as a permanent status. Compliance and security posture can change, so organizations should continuously reassess devices and combine device information with identity, authentication, and risk signals.

Apply Least-Privilege Access Policies

Conditional access policies should grant only the level of access needed for a user to perform their work. Higher-risk users, privileged roles, and sensitive applications should generally have stricter requirements than low-risk resources.

For example, administrators can be required to use managed devices and strong MFA when accessing management interfaces. Standard users may have less restrictive requirements for applications containing non-sensitive information.

Organizations should also limit policy exclusions. Broad or permanent exceptions can create access paths that bypass important controls. Exceptions should have a documented reason, a defined scope, and regular reviews to confirm they are still necessary.

Protect Corporate Data on Unmanaged Devices

Completely blocking unmanaged devices is not always practical, particularly in BYOD and remote work environments. Instead, organizations can allow limited access while controlling how corporate information is handled.

For example, users can be allowed to view data through a browser while downloads, local synchronization, printing, or copying are restricted. Sensitive applications can still require a managed device when session-level restrictions do not provide enough protection.

These controls help separate access to information from possession of that information. A user may be authorized to view a document without being allowed to store an uncontrolled copy on a personal endpoint.

Regularly Review and Simplify Access Policies

Conditional access environments tend to become more complex over time as administrators add new applications, user groups, exceptions, and security requirements. Without regular maintenance, overlapping or obsolete policies can become difficult to understand and troubleshoot.

Organizations should periodically review policy scope, exclusions, conditions, and enforcement results. Duplicate policies can be consolidated, unused rules removed, and temporary exceptions closed when they are no longer required.

Changes should be tested before full enforcement whenever the platform provides suitable tools. Monitoring policy results after deployment also helps identify authentication failures, unexpected lockouts, and gaps where intended controls are not being applied.

Extending Conditional Access to the Endpoint with Venn

Conditional access and ZTNA verify every access request and connect users to applications with least privilege, but access is only the first half of the problem. Once a connection is granted and data flows, that data lands and is used on an endpoint that conditional access policies do not govern. On a managed device, you would pair access controls with EDR, a DLP agent, or MDM. On the unmanaged and BYOD laptops that remote workers and contractors actually use, you can’t. Venn’s Blue Border™ closes that gap by creating a company-controlled secure enclave directly on any Mac or PC, so the data your access policies deliver lands somewhere isolated, governed, and revocable, without VDI and without managing the device.

Key capabilities of Blue Border™:

• Company-controlled secure enclave: Installing Blue Border on a Mac or PC creates a secure enclave on the device itself, where work data, apps, networking, and AI all run locally and company data stays encrypted and isolated from the rest of the machine.
• Protection on unmanaged and BYOD devices: Blue Border secures the workspace and the data on any laptop without owning or fully managing it,  precisely where invasive endpoint management agents can’t go, so the endpoints your access policies connect to but can’t protect finally get a controlled place for company data.
• Endpoint DLP at the application layer: Every app, whether installed, browser-based, or AI, is wrapped by a blue line that creates a virtual firewall and enforces DLP on the device across copy/paste, download, upload, screenshot, print, and AI.
• Network traffic control: Work traffic routes through Venn’s built-in VPN gateway or your existing private network, keeping business activity separate from everything else on the device.
• Isolated, encrypted file storage: Users save only to work-sanctioned file systems inside Venn Disk, which are isolated, encrypted, and remote wipeable.
• AI governance on any device: Blue Border governs which AI tools can reach company data inside the enclave, on managed and unmanaged devices alike.
• Revocable data, not just revocable access: Cutting access leaves data already delivered on the device; because company data lives only inside the enclave, a single remote wipe purges it entirely, extending zero trust through to offboarding.
• Complementary to your existing access layer: Blue Border runs alongside ZTNA rather than replacing it,  you keep the identity-driven, least-privilege access you’ve invested in and add the endpoint and data protection it doesn’t cover.
• Privacy outside the enclave: All activity outside Blue Border™ stays 100% private, with no company visibility or control over the user’s personal browsing, apps, and files.

Learn how Venn extends zero trust access with endpoint data protection on any device →

Securing contractors and remote employees doesn’t have to be a pain. For years, IT teams were stuck choosing between virtual desktops that are slow, complex, and expensive. Or buying, locking down, and shipping laptops across the globe. Thankfully, there’s a better way. Introducing Venn, a breakthrough in remote work security. Venn creates a secure enclave on any unmanaged PC or Mac used by contractors and remote employees. No VDI, no need to fully manage the device, and no compromise on security and compliance. Work applications run locally within the enclave, visually indicated by Venn’s blue border, protecting and isolating work from personal activity on the same computer. Both browser and installed apps run locally, natively, and securely. No hosting and no virtualization whatsoever. This approach preserves full app performance and user experience, while ensuring your organization’s DLP policies are always enforced. No file transfers, copy paste screenshots, or any other actions that could lead to data loss or compromise. Ready to see the future of remote work? Well, on behalf of all of us at Venn, we invite you to step inside the blue border. Find out more at Venn dot com.