Conditional access is the set of rules an identity provider applies at sign-in to decide whether to let a user in, block them, or require more before granting access. Each policy combines conditions, such as who the user is, which app they’re opening, whether their device is managed and healthy, where they’re signing in from and how risky the sign-in looks, with an outcome: allow, block, require multi-factor authentication (MFA), require a compliant device, or limit the session. The name is closely associated with Microsoft’s identity platform, but the concept is offered widely under names like adaptive or context-aware access.
At a glance
- Policies evaluated at sign-in, usually by your identity provider (IdP), and sometimes again during a session.
- Combines signals such as user, group, application, device status, location and risk.
- Outcomes include allow, block, require MFA or a stronger method, require a managed device, or restrict the session.
- A practical way to apply zero trust principles to application access.
- Signals and features available depend on the identity provider, license tier and device management in place.
What problem it solves
A single sign-in rule for everyone tends to be either too strict or too loose. Requiring MFA on every login annoys users and encourages them to approve prompts without thinking; requiring it only sometimes leaves gaps. Treating a sign-in from a managed laptop in the office the same as one from an unknown device in another country makes little sense.
Conditional access lets you match controls to risk. Routine access from a managed, healthy device can be smooth, while risky situations get stronger checks or are blocked outright. It also lets you protect sensitive applications more tightly than general ones, and enforce rules like “finance systems only from company devices” without separate tools for each app.
How it works
Assignments. Each policy targets specific users or groups, often with exclusions such as emergency access accounts, and specific applications or actions.
Conditions. The policy checks signals at sign-in. Typical ones include device platform, whether the device is enrolled in management and meets compliance rules, network location or country, the client app type, and risk scores calculated from sign-in behavior or known leaked credentials. Device signals usually come from mobile device management (MDM) or endpoint management tools.
Controls. If conditions match, the policy grants access, blocks it, or grants it only if the user completes MFA, uses a phishing-resistant method, signs in from a compliant device or accepts terms. Session controls can limit what users do, such as preventing downloads on unmanaged devices, or shorten how long a session lasts.
Evaluation. When several policies apply, they are usually combined so that all applicable requirements must be met, and a block generally wins. Administrators test new policies in report-only mode before enforcing them.
Beyond sign-in. Some platforms re-evaluate sessions when conditions change, for example revoking access when a user is disabled or a device falls out of compliance. Signals from identity threat detection and response (ITDR) tools can feed risk-based policies.
Because policies run at the identity provider, they cover apps connected through single sign-on (SSO). Zero trust network access (ZTNA) services often apply similar checks to private applications.
When it matters for buyers
- When rolling out MFA or phishing-resistant methods. Conditional access decides who must use which method, and when.
- When allowing personal devices. Policies can restrict unmanaged devices to browser-only or read-only access.
- When choosing identity provider license tiers. Conditional access, risk-based policies and session controls are often in higher tiers.
- When adopting zero trust or secure service edge. Consistent policy between the identity provider and access services avoids gaps.
- After an account takeover. Blocking legacy sign-in methods and risky locations is a common quick fix.
Questions to ask vendors
- Which signals can policies use, and which require additional licenses or device management?
- Can policies require specific authentication methods, such as phishing-resistant MFA, for certain apps or users?
- Do you offer a report-only or what-if mode to test policies before enforcing them?
- Can sessions be re-evaluated or revoked when risk or device status changes?
- How do your policies apply to legacy protocols and apps that don’t support modern sign-in?
- How do your policies work alongside our ZTNA or secure service edge provider?
How it differs from zero trust security
Zero trust security is a broad model: never assume trust based on network location, verify each request, grant least privilege and assume breach. Conditional access is one mechanism for putting that model into practice at the identity layer, by evaluating identity, device and context before granting access to an application. A full zero trust program also covers network segmentation, workload and data controls and monitoring that conditional access doesn’t address. For identity-aware access to web, cloud and private apps, see our secure service edge overview.