Enforce dynamic access control with CAP ↗

Prerequisites

View or View/Edit RBAC permissions for Conditional Access Policy
ITDR add-on license : Activate the ITDR add-on license for your Cortex tenant.
Cortex agent on Domain Controllers : Deploy the Cortex agent on all Domain Controllers where you want to enforce Conditional Access Policy rules.\
Note: The CAP agent requires a minimum of 200 MB of RAM and 10 GB of storage.
Cortex Identity Engine (CIE) : Connect your Active Directory (AD) integration and MFA Provider via CIE.
MFA provider : Configure Okta or Entra ID as the MFA provider in your environment.

Conditional Access Policy (CAP) provides context-driven access control by evaluating real-time authentication requests against user-centric security contexts, risk levels, and protocol data. Leveraging Cortex XSIAM-enriched telemetry, it enables you to dynamically enforce access decisions such as allowing, blocking, or triggering multi-factor authentication (MFA) challenges.

Key capabilities

Conditional Access Policy delivers the following core capabilities:

Context-driven access control: Evaluate authentication requests in real time by checking user-centric security contexts, risk, and protocol structural data.
Real-time enforcement: Enforce access decisions in near real time with minimal delays, leveraging Cortex XSIAM-enriched data.
MFA integration: Trigger multi-factor authentication challenges based on risk conditions, with configurable challenge frequency and context scope.
Simulation mode: Monitor access patterns without blocking users, allowing security teams to validate rules before enforcing access restrictions.

Supported environments

The following table summarizes the environments and integrations that Conditional Access Policy supports.

Category	Supported options
Domain Controllers	Enterprise integration
Authentication protocols	Kerberos, NTLM
Operating system platforms	Windows, Linux, Mac
Device types	Managed devices, unmanaged devices, devices outside the organization domain
MFA providers	Okta, EntraID

Conditional Access Policy use cases

The following table shows example rules based on common access conditions.

Objective	Example rule
Critical Infrastructure Protection	Implement zero-trust boundaries by restricting RDP access to Domain Controllers exclusively to authorized "IT Admins".
Risk-Based Threat Mitigation	Dynamically trigger mandatory MFA challenges when an identity with a "High" User Risk Score attempts to authenticate to critical Database Servers.
Protocol Hardening	Enforce MFA for high-risk protocols such as RDP and SMB.
Third-Party Risk Management	Restrict the "Contractors" security group from accessing designated sensitive internal assets.

Target personas

Conditional Access Policy serves three primary personas:

SecOps engineer: Create and configure Conditional Access Policy rules, manage rule priority, and optimize policies based on audit data.
SecOps analyst: Review audit logs, monitor policy enforcement trends, and identify security gaps.
End-user: Receive MFA challenges or access-blocked notifications based on Conditional Access Policy enforcement.

High-level workflow

Conditional Access Policy follows a three-phase workflow:

Create rules : Define Conditional Access Policy rules with conditions, actions, and MFA settings. Assign rule priority to control evaluation order.
Enforce policies : Cortex XSIAM evaluates authentication attempts against Conditional Access Policy rules in real time, and enforces the configured action for the first matching rule: MFA Verification, Block, Monitor, or Allow.
Monitor and optimize : Review audit logs and policy widgets to assess rule effectiveness. Adjust rules, conditions, and priorities based on observed access patterns.

Access the Conditional Access Policy page under Modules → Identity Security → Conditional Access

Deploy and configure the Conditional Access Policy

Configure your identity profiles, create and manage context-driven access rules, and analyze authentication results through centralized identity access logs.

Configure an Identity profile

Use the toggle in Set up an Identity profile to enable or disable the Conditional Access policy .

Important: To activate the engine, you must enable the Conditional Access Policy (CAP) feature flag and configure its specific system parameters within the Identity Profile settings. These global configurations determine how the underlying agent handles authentication interception and structural service errors across your domain.

Create a Conditional Access Policy rule

Define a new rule to control access based on contextual conditions. Your entire policy can contain a maximum of 20 rules.

Go to Modules → Identity Security → Conditional Access → Rules.
Click Create New Rule. Use one of the provided templates and customize according to your rules, or create the rule from scratch.
In General, specify a Rule Name and a Rule Description.
In Mode, select Enforcement if you want to apply the rule immediately and Simulation to monitor the rule and evaluate the potential impact before you decide to enforce the rule. The Simulation mode records the event in silent mode so that you can review and fine-tune the rules.
Select the rule action:
- Allow: Approve the access request.
- Block : Deny the access request entirely. You can select whether to interact with the user, to send an email or to trigger a message on the screen.
- MFA Verification : Requires the user to complete an MFA challenge before granting access. Select how to interact with the user, by sending an email or by triggering a message on the screen. Configure the following MFA settings:
- MFA Provider: Okta or Entra ID. You must have an integration with the MFA provider configured. If you don’t, click Add MFA Integration to configure the integration. After you have integrated an MFA provider, continue with the rule configuration.
- MFA Challenge Duration: How often the user must re-authenticate using MFA. This value can be every 4 hours, every 8 hours, every 12 hours, every 24 hours, or every week.
- MFA Challenge Scope: How the MFA is applied, per user only across devices or per user and source device combination.
- Fail Mode: What to do if the verification fails due to the unavailability of the MFA provider due to an error or a timeout, to allow or block access.
In Target, select who the rule will apply to. You can select all users or certain groups.\
When using Groups Selection, you can define groups of Asset Roles or Security Groups defined in the Active Directory, or any combination of them using AND and OR operators. You can define asset roles in Inventory → Assets → Asset Roles Configuration.\
You can then define exclusions by selecting them under Excluded Users.\
The two tabs under the configuration selections display all the Targeted Users and all the Excluded Users for this rule.
In Conditions, define rule conditions by selecting attribute-based criteria for the users configured in the previous step.
- Authentication Protocol: Kerberos or NTLM.
- Identity: Conditions based on the fields of the identity. When you select a risk level, the Identity attributes condition is displayed. Use the Identity attributes to specify the MITRE Tactics the user is involved in or Security Insights.
- Source: Source Host Name or Source IP.
- Destination: Destination Host name, IP, Authentication Service or SPN.
Review the rule summary generated from the selected conditions. You can go back and edit rule details.
Click Create.

The new Conditional Access Policy rule appears in the rule list on the Conditional Access Policy page.

Adjust the rule priority to control the evaluation order relative to other rules and click Save.\
If you activate the rule, the system begins evaluating authentication attempts against the rule conditions immediately.\
When the conditions of a rule are met for a user, the rule is applied and the rest of the rules aren’t considered.

Monitor and manage Identity Access Rules

The Conditional Access Rules page serves as the centralized management console for your context-aware security policies, accessible under Modules → Identity Security → Conditional Access → Rules. This interface provides a unified workspace to track policy impact metrics via interactive widgets, search and filter existing configurations, and access granular audit events. Using this centralized interface, you can dynamically manage the entire lifecycle of access rules, ensuring a strong corporate identity security posture.

Manage existing rules

In the Rule list, right-click a rule to edit, disable, move to change priority, or delete it as your security requirements change.

Manage rule priority

Control the order in which the system evaluates Conditional Access Policy rules. Because policies are processed sequentially, the engine applies a strict first-match-takes-effect execution flow. When an authentication attempt satisfies all criteria of a rule, that action is enforced, and subsequent rules are skipped. To adjust the evaluation order, drag and drop a rule to its new vertical position in the table grid.

Simulation Mode Exception: Rules configured in Simulation mode do not stop the priority evaluation chain. When an authentication attempt matches a simulation rule, the event is silently logged for impact analysis, and the engine immediately continues evaluating the next rule in the list.

The following table lists the columns available on the Conditional Access Rules table.

Column	Description
Priority	Top-down processing order of the rule.
Rule Name	The title of the rule.
Description	Summary of the rule's logic and objective.
Status	Activation state toggle (Enabled or Disabled).
Mode	Rule state tier (Enforcement or Simulation).
Action	Security behavior triggered on match (Monitor, Allow, Block, or MFA Verification).
Hits	Total number of authentication attempts matching this rule.
Identity Impact	Total unique users affected by the rule.
Modified By	Email of the user who last edited the rule.
Last Modified	Timestamp of the most recent configuration save.
Created By	Email of the user who created the rule.
MFA Provider	An integrated third-party MFA service handles verification challenges (Okta or Entra ID).
Creation Time	Timestamp when the rule was first saved.

Monitor and manage Identity Access Logs

The Identity Access Logs page provides a centralized, high-fidelity audit trail of all authentication events processed by the conditional access engine, accessible under Modules → Identity Security → Conditional Access → Logs. As your primary Policy Enforcement Point visibility interface, it captures real-time telemetry from every matched policy rule, tracking whether an access attempt was allowed, blocked, or challenged with MFA. Use this page for investigation and fine-tuning of your policy.

The following table lists the columns available on the Identity Access Logs table.

Column	Description
Timestamp	Date and time the authentication attempt was evaluated.
Identity	Username of the user initiating the connection.
Source Device Name	Endpoint hostname or IP address originating the request.
Destination Device Name	Target system or asset being accessed.
Protocol	Intercepted network protocol used (Kerberos or NTLM).
Service Type	Connection type requested (RDP, SMB, SSH, etc).
Authentication Status	Final result of the connection attempt (Allowed, Denied, or Failed).
Reason	Explanatory context behind the authentication status (rule block, MFA timeout).
Rule Name	Conditional Access rule matched by the attempt.
Action	Security control is enforced by the rule (Monitor, Allow, Block, or MFA Verification).
Mode	Operational state of the rule (Enforcement or Simulation).
DC Name	Domain Controller that intercepted the request.