What Is Conditional Access? The Identity Gate

A user who already typed the right password is the most common starting point of the intrusions you will investigate. The credential was phished, or sprayed, or bought, and the sign-in itself looks clean: valid username, valid password, a successful authentication event in the log. What stops the attacker at that moment is not another password. It is whether the sign-in came from a compliant device, from a country the account never logs in from, against an admin role, with a risk score the platform already flagged. Conditional access is the control that asks those questions and decides what to do with the answer.

Conditional access is the identity gate that sits between a successful first-factor sign-in and the resource. It grants, blocks, or steps up access by evaluating signals about the request: who the user is, what device they are on, where they are coming from, which application they want, and what risk the platform has scored on that session. This guide covers what conditional access is, the if-then policy model that drives it, how it implements zero trust and risk-based access, the policies practitioners actually deploy, Microsoft Entra Conditional Access as the canonical implementation, its relationship to continuous evaluation, and the ways it fails. It is written for the people who read sign-in logs after the fact: SOC analysts, threat hunters, and DFIR responders who have to explain why a request was allowed or blocked.

What is conditional access?

Conditional access is a policy-driven gate that evaluates signals at sign-in and returns an access decision: allow, block, or allow with additional requirements. It runs after authentication has already proved who the user is, and it answers a different question. Authentication asks whether the credential is valid. Conditional access asks whether this validated sign-in, on this device, from this location, against this application, at this risk level, should actually be let through.

That distinction is the whole point. A stolen password passes authentication cleanly, because the password is correct. Conditional access is the layer that can still stop it, because it weighs the context the password says nothing about. A correct credential from an unmanaged device in a country the user has never signed in from is a different request than the same credential from a compliant corporate laptop on the office network, even though the password is identical in both.

The inputs are signals. A signal is any attribute of the sign-in the platform can evaluate: the user or group, the device and its compliance state, the source IP and the location it resolves to, the application being requested, and the real-time risk the platform has calculated for the user or the session. The output is a control: permit the session, deny it outright, or grant it only if the user satisfies an extra requirement such as multi-factor authentication or a compliant device. Conditional access is the engine that maps signals to controls.

This is an enforcement layer, not a model. It builds directly on access control: authentication establishes the identity, the authorization model decides what that identity is broadly entitled to, and conditional access adds a contextual check on top, re-deciding each sign-in against live signals rather than trusting a one-time grant.

The if-then policy model

A conditional access policy is an if-then statement. If a set of conditions is true for this sign-in, then apply this access control. The structure is the same whether you write one rule or a hundred: signals feed conditions, conditions select a policy, and the policy applies a decision.

Signals are the raw inputs described above: user and group membership, device platform and compliance, IP and location, target application, sign-in and user risk. They are facts about the request, not yet decisions.

Conditions are the assignments that decide whether a policy applies to this sign-in. A policy scoped to "members of the Global Administrators role, accessing any cloud app, from any location" only fires when those assignments match. Conditions are how one tenant runs many policies at once without every rule evaluating every sign-in the same way.

Access controls are the then. They split into two kinds. Block controls deny the sign-in, the most restrictive outcome. Grant controls allow it, optionally subject to one or more requirements the user must satisfy first: require multi-factor authentication, require a compliant device, require a hybrid-joined device, require an approved client app, require a password change. A single policy can demand several of these at once and require all of them.

The three parts line up cleanly. The signal is the raw fact, the condition is the assignment that decides whether a policy applies, and the control is the decision the policy enforces.

The decision is not always allow or deny. The most useful conditional access outcome is the middle path: allow, but only after the user proves more. That is what "step up" means. A low-risk sign-in from a known device proceeds without friction; the same account flagged as risky, or reaching for an admin portal, gets challenged for MFA before the session is granted. The policy raises the bar in proportion to the signal, which is the core idea behind adaptive authentication: the strength of the challenge tracks the risk of the request.

How conditional access implements zero trust

Zero trust holds that no request is trusted on the strength of where it comes from or because the user authenticated once before. Every request is verified on its own merits, in context, every time. Conditional access is one of the concrete mechanisms that turns that principle into enforced policy, and Microsoft positions it explicitly as a zero trust policy engine.

The connection is direct. Zero trust says verify explicitly, use least privilege, and assume breach. Conditional access verifies explicitly by evaluating device, location, application, and risk on each sign-in rather than granting standing access. It supports least privilege by scoping policies to the users, roles, and apps that need a given control. And it assumes breach by treating a valid credential as insufficient on its own, demanding more proof when the context is wrong.

This is also where conditional access becomes risk-based and adaptive. When the platform scores a sign-in as risky, because the credentials appeared in a leak, the location is anomalous, or the session matches known attacker patterns, a policy can react to that score in real time. A clean sign-in passes; a risky one is challenged or blocked. The access decision is no longer a fixed property of the account but a live function of how the current request looks, which is exactly the shift zero trust calls for.

Common conditional access policies

Conditional access is only as good as the policies written into it. A handful of policies recur across nearly every mature deployment because they close the gaps attackers reach for first.

Block legacy authentication. Older protocols like IMAP, POP, and basic-auth SMTP cannot perform MFA, so they are the path attackers use to bypass it entirely during password spraying. A policy that blocks legacy authentication outright removes that bypass. It is widely treated as the first policy to deploy.

Require MFA for administrators. Privileged roles are the highest-value target, so the strictest control goes there first. A policy requiring MFA for users in administrative roles ensures a stolen admin password alone is not enough to act.

Require a compliant device. Scope sensitive applications so that access requires a device marked compliant by the mobile-device-management platform. An unmanaged or jailbroken device fails the check even with valid credentials, which keeps corporate data off endpoints the organization cannot vouch for.

Block or restrict by location. Define named locations or country ranges and block sign-ins from regions the organization never operates in, or require stronger controls from outside trusted networks. This is the geo-block, and it cuts a large share of automated credential-stuffing noise.

Step up on risky sign-in. When the platform scores a sign-in as risky, a policy can require MFA or a password change before granting access, or block it. This is the risk-based policy, and it is what turns a leaked-credential detection into an enforced response rather than just an alert.

These are starting points, not a finished posture. Real deployments layer many policies, and the order they evaluate and combine in matters as much as any single rule.

Microsoft Entra Conditional Access: the canonical example

Conditional access as a named, productized feature is most strongly associated with Microsoft Entra ID, formerly Azure Active Directory. Microsoft Entra Conditional Access is the reference implementation most practitioners mean when they say "conditional access" without qualification, and its model is worth knowing precisely because it sets the vocabulary.

Entra evaluates conditional access after first-factor authentication completes. Microsoft is explicit that it is not a frontline defense against denial-of-service or pre-authentication attacks; it acts on the sign-in once a credential has been presented. Its signals are user, group, or agent identity, IP location, device platform and state, the target application, and real-time and calculated risk drawn from Microsoft Entra ID Protection. Its decisions are block access, or grant access with optional requirements: require multi-factor authentication, require authentication strength, require a compliant device, require a Microsoft Entra hybrid-joined device, require an approved client app, require an app protection policy, require a password change, or require accepting terms of use.

Licensing matters for accuracy. Conditional access itself requires Microsoft Entra ID P1. Risk-based policies, the ones that consume sign-in risk and user risk, require Microsoft Entra ID P2, because the risk signal comes from ID Protection. Stating that risk-based conditional access is free or built into every tenant is wrong, and it is a common error in vendor glossaries.

The important caveat: conditional access is identity-provider specific, not a universal standard. Microsoft Entra Conditional Access is a product feature, not an open spec. Other identity providers offer equivalent capabilities under their own names, Okta with sign-on and authentication policies, Google with context-aware access, but a policy written for one does not port to another, and the exact signals, controls, and evaluation order differ. Treat "conditional access" as a category of capability that Entra named most prominently, not as a cross-vendor standard.

Conditional access and continuous evaluation (CAEP)

Standard conditional access evaluates at sign-in. Once a token is issued, it is typically valid for its lifetime, often an hour, regardless of what changes during that window. If an account is disabled, a device falls out of compliance, or risk spikes mid-session, the existing token keeps working until it expires. That gap is the problem continuous evaluation addresses.

The Continuous Access Evaluation Profile (CAEP) is an open standard, developed under the OpenID Foundation, that lets an identity provider and a resource provider exchange security events in near real time so access can be revoked mid-session rather than only at the next token refresh. When a critical event occurs, account disablement, a detected high-risk session, a password change, the provider can signal the resource to re-evaluate or revoke access immediately. Microsoft's continuous access evaluation is its implementation of this idea for Entra.

For a defender, the distinction matters during incident response. Conditional access without continuous evaluation means revoking a compromised account does not necessarily kill its active sessions until tokens expire. Continuous evaluation shortens that window from the token lifetime to near real time. Knowing which one is in force tells you how fast a containment action actually takes effect.

Where conditional access fails

Conditional access fails in quiet, recurring ways, and the failures show up in the sign-in logs you investigate, not in alerts at the moment they happen.

Misconfiguration lockout. A policy scoped too broadly, requiring a control no one can currently satisfy, can lock out every administrator, including the person who would fix it. This is why a break-glass account excluded from conditional access policies is standard practice, and why every policy should be tested before it is enforced on everyone.

Stuck in report-only mode. Report-only mode evaluates a policy and logs what it would have done without enforcing it, which is the correct way to test a new rule. The failure is leaving it there. A policy in report-only mode protects nothing; it only records. Plenty of tenants carry policies that were never promoted from report-only to enabled, giving a false sense of coverage.

Coverage gaps. A policy only protects what its conditions scope it to. Applications, user groups, or sign-in types left outside every policy's assignments pass through ungated. Legacy authentication left unblocked is the classic version, but any unscoped app or excluded group is a hole. Conditional access protects the sign-ins it is told to evaluate and nothing else.

Exclusions that outlive their reason. Exclusions added for a migration or a troubleshooting session and never removed become permanent gaps. An account or app excluded from a critical policy is exactly the path an attacker prefers, because it bypasses the control by design.

The thread is that conditional access is a configuration, not a guarantee. It enforces precisely the policies written and enabled, scoped to precisely the sign-ins they cover, and the gap between intended and configured posture is where investigations begin.

The bottom line

Conditional access is the identity gate between a successful sign-in and the resource. It runs after authentication, evaluates signals about the request, the user, device, location, application, and risk, and returns an access decision: allow, block, or allow only after the user proves more. The model is if-then: conditions select a policy, the policy applies a control. That is what lets it stop a credential that is valid but compromised, the case a password check cannot catch.

It is the working layer of zero trust for identity, risk-based and adaptive when paired with a risk signal, and continuous when paired with CAEP. Microsoft Entra Conditional Access is the canonical implementation and the source of the vocabulary, but the capability is identity-provider specific, not a universal standard. For a defender, the practical truth is that conditional access enforces exactly the policies written, enabled, and scoped, and nothing more. The space between the posture you intended and the posture you configured, the report-only policy never promoted, the app never scoped, the exclusion never removed, is where the sign-in logs start telling a story.