> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/cortex-cloud-runtime-security/threat-management/identity-threat-module-itdr/conditional-access-policy.md). # Enforce dynamic access control with CAP {% hint style="success" %} ### 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. {% endhint %} 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: 1. **Create rules** : Define Conditional Access Policy rules with conditions, actions, and MFA settings. Assign rule priority to control evaluation order. 2. **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. 3. **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](broken://pages/1TgAsRGp6oTHQ0dlajYG#set-up-identity-profiles) 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. 1. Go to **Modules** → **Identity Security** → **Conditional Access** → **Rules.** 2. Click **Create** **New Rule**. Use one of the provided templates and customize according to your rules, or create the rule from scratch. 3. In **General, specify a Rule Name** and a **Rule Description**. 4. 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. 5. 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. 6. 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. 7. 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. 8. Review the rule summary generated from the selected conditions. You can go back and edit rule details. 9. 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. | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://cortex-docs.paloaltonetworks.com/cortex-cloud-runtime-security/threat-management/identity-threat-module-itdr/conditional-access-policy.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.