What Is Conditional Access?

Conditional access is an access-control approach that evaluates a request's identity, device, resource, location, risk and session context against policy, then allows, blocks, limits or requires additional verification before or during access to an organizational resource.

The approach replaces a single, static sign-in rule with decisions suited to the request. A payroll application may require a managed, compliant device and stronger authentication, while a low-sensitivity employee directory permits access under less restrictive conditions.

Conditional access operates between authentication and resource access, often when an identity system issues or refreshes a session or token. It can change the requirements for a request, but it does not authenticate a user, make a device compliant or define the application's business permissions by itself.

Device trust is the prerequisite concept: it explains how device identity and current posture become evidence for an access decision. This article places that evidence within the broader identity trust system.

Why conditional access matters

Authentication answers whether a claimant has demonstrated control of an accepted authenticator. It does not establish that every subsequent request is appropriate. The same authenticated person can request different resources from a company laptop, a personal phone or a session showing new risk.

Conditional access lets policy account for those differences. The decision can consider the subject, target resource, requested action and current context instead of granting broad access because a password was accepted or a request originated inside a familiar network. NIST describes zero-trust policy decisions as using subject and asset attributes, resource requirements and contextual information in its NIST architecture.

This policy layer also makes exceptions visible. Rather than leaving access rules embedded inconsistently across applications, an organization can define who receives an exception, why it exists, when it expires and which compensating controls apply. The resource must still enforce the result correctly.

How conditional access works

Conditional access works as a request-time policy evaluation. Products differ in signal availability, evaluation timing and supported controls, but the logical flow is consistent.

1. A subject requests a resource. A user, device or workload attempts to open an application, obtain a token or continue a protected session.
2. The system establishes identity context. The identity service identifies the subject and relevant account, group, role and authentication state. User identity and device identity remain separate inputs.
3. Signal providers supply context. Available evidence may include device compliance, management state, platform, network location, sign-in risk, session state, client type and resource sensitivity. Each signal needs a known source and freshness limit.
4. Applicable policies are selected. The policy decision point matches the subject, resource and conditions against policy assignments, inclusions and exclusions. Several policies may apply to one request.
5. The policy returns requirements or a decision. The result may allow access, block it, require multifactor authentication, require a compliant device or constrain the session.
6. An enforcement point applies the result. An identity service may withhold a token, while an application, proxy or operating system may limit a session or deny an action. A policy decision has no effect if the relevant enforcement point ignores it.
7. The system records evidence and reevaluates when supported. Logs can preserve the inputs, matched policy and outcome. Some systems evaluate again when a token refreshes, a session event occurs or new risk information becomes available.

Microsoft Entra is one provider implementation. Its Microsoft overview describes signals including identity, location, device, application and risk, with decisions that can block access or require controls such as authentication strength and device compliance. Those named signals and controls should not be assumed to exist identically in every identity platform or license.

Conditional access policy components

A conditional access policy should identify the whole path from request to evidence. The following components prevent a condition from being mistaken for a complete control.

The distinction between a condition and a control is important. A location, device state or risk score is an input. Requiring another authenticator, denying token issuance or limiting a session is an enforced response.

Risk-based access

Risk-based access changes requirements when current evidence indicates a different level of risk. A policy might require fresh, stronger authentication for an unusual sign-in or block a request when the risk cannot be reduced to an acceptable level.

A risk signal is an estimate, not proof of compromise. False positives can interrupt legitimate work, while missing or delayed telemetry can leave a risky request looking normal. Policy owners need defined thresholds, investigation paths and a way to recover safely from incorrect decisions.

Device-based access

Device-based access uses endpoint identity or posture as part of the decision. Useful signals can include whether the device is enrolled, recognized, encrypted, running a supported operating-system version or meeting assigned security configuration. Ownership alone does not establish current health, and a compliance label is only as reliable as its underlying checks and reporting time.

CISA's CISA model treats identities and devices as separate zero-trust pillars and describes access decisions that increasingly use device information and automated policy. This separation helps prevent successful user authentication from being treated as evidence that the endpoint is trustworthy.

How device compliance affects conditional access

Device compliance is a calculated posture result from a defined set of checks. An endpoint management system may compare an enrolled device with requirements for encryption, operating-system version, screen lock or security controls, then report a current compliant or noncompliant state to the access system.

A conditional access policy can use that state as one condition. For example, access to a finance application may require both suitable authentication and a compliant device. The identity service evaluates the reported state; it does not configure the endpoint or repair the failed setting.

Supplying usable device context across a mixed fleet requires accurate enrollment, inventory, policy and status reporting. Teams evaluating that endpoint layer can review unified endpoint management. The identity provider remains responsible for the access-policy decision, and the target resource remains responsible for its own authorization and enforcement.

Compliance is not continuous proof that a device is uncompromised. Reports can be stale, checks can omit relevant conditions and an endpoint can change after the last evaluation. High-impact access may therefore combine compliance with recent authentication, device identity, risk telemetry and resource-level authorization.

A conditional access example

Marshline Ecology, a fictional environmental consultancy, lets employees read general project schedules from supported browsers. Its payroll application contains more sensitive employee data, so its conditional access policy requires a current workforce identity, phishing-resistant authentication and a managed device reported compliant within the organization's accepted freshness window.

Elena signs in from her assigned laptop and requests payroll. The identity service identifies Elena, the payroll resource and her laptop. The endpoint system reports that the device is enrolled but noncompliant because its disk-encryption check failed. The policy therefore withholds access and sends Elena to the approved remediation path.

After support restores encryption and the endpoint reports a fresh compliant state, Elena repeats the request. She completes the required authentication, the identity service issues a token for payroll and the application applies her employee-level permissions. Conditional access allowed the session; it did not authorize Elena to edit payroll records, because that business permission belongs to the application.

If Elena instead requests the general schedule from a personal phone, a separate policy permits browser access with a shorter session and no download. The different result follows the resource and device context, not a judgment that the person has two identities.

Diagram brief: The conditional access decision flow

Learning objective: Show how separate identity, device, resource and risk signals feed a policy decision that an enforcement point applies and records.

Nodes: Subject request; user identity; device identity and compliance; resource and action; location and risk; policy decision point; allow, challenge, limit or deny result; enforcement point; application authorization; decision log; exception and remediation path.

Relationships: The request identifies the subject, resource and action. Signal sources send current context to the policy decision point. Policy produces a result for the enforcement point. An allowed request proceeds to application authorization. Every outcome creates evidence, while unmet requirements lead to remediation or a governed exception.

Reading order: Left to right: request and signals → policy evaluation → enforcement result → resource authorization and evidence. A return arrow from remediation to a new request shows reevaluation rather than automatic access.

Labels: Request; identity; posture; risk; policy; allow; verify; limit; deny; enforce; authorize; log; remediate.

Text alternative: A subject requests an action on a resource. User identity, device compliance, location and risk feed a policy decision point. The policy returns allow, additional verification, limited access or denial to an enforcement point. Allowed requests still pass through application authorization, all outcomes are logged and failed requirements can lead to remediation before a new evaluation.

Benefits of conditional access

Conditional access can improve the precision and consistency of access decisions when signals and enforcement are reliable.

• Context-sensitive requirements: Stronger controls can apply to sensitive resources or higher-risk requests without adding the same friction everywhere.
• Device-aware protection: Access can depend on recognized device identity and current compliance rather than user authentication alone.
• Central policy expression: Teams can define common conditions and outcomes across supported resources instead of duplicating every rule inside each application.
• Visible decision evidence: Logs can show which policy applied, which requirement failed and where an exception was used.
• Faster policy response: A changed risk, device or identity signal can affect later evaluations without waiting for a network boundary to change.

These benefits depend on coverage. Resources, authentication flows or local accounts outside the policy path can retain separate access routes.

Conditional access risks and limitations

Conditional access can deny legitimate work or permit inappropriate access when its inputs, rules or enforcement are incomplete. Common failure conditions include:

• Stale signals: Old group, device or risk data can produce a decision that no longer fits the request.
• Policy gaps: Excluded users, unprotected resources and unsupported client flows can bypass the intended rule.
• Conflicting policies: Overlapping requirements can create unexpected combinations or make remediation impossible.
• Administrative lockout: A broad deny rule can block administrators needed to repair the configuration. Governed emergency access and staged testing are necessary.
• Weak device criteria: Enrollment or ownership alone may be treated as trust even when current posture is unknown.
• Excessive reliance on location: A familiar network address does not establish user identity, device health or safe behavior.
• Uneven enforcement: A central decision cannot protect an application that accepts another credential path or fails to validate the issued session.
• Privacy overcollection: Device, location and behavior signals should be limited to justified purposes, protected and reviewed under applicable requirements.
• Poor recovery design: A blocked user needs a safe, auditable way to satisfy the requirement or request an exception.

Policies should be tested with representative users, devices, applications and failure states before broad enforcement. Teams should also monitor denial patterns and exception use so that a control remains both effective and operable.

Conditional access and related concepts

Conditional access coordinates several identity controls but does not replace them.

Multifactor authentication can satisfy one requirement in a conditional access policy, while identity management maintains the identities, roles and lifecycle data the policy consumes. Neither control determines endpoint compliance by itself.

Conditional access is therefore a decision layer, not a synonym for authentication or device management. It combines available evidence for a particular request, returns an outcome to an enforcement point and records enough context to explain or review that outcome. Policy enforcement is the downstream mechanism that turns such a decision into an applied control.