>
    Strata Copilot
    Configure Security Risk for the Cloud Identity Engine
    Focus
    Download PDF
    Focus
    1. Home
    2. Identity
    3. Identify Users and Devices with Cloud Identity Engine
    4. Configure Security Risk for the Cloud Identity Engine
    Download PDF
    Identity

    Configure Security Risk for the Cloud Identity Engine

    Table of Contents

    Configure Security Risk for the Cloud Identity Engine

    Find out how to configure Security Risk in the Cloud Identity Engine to obtain risk information about users, groups, and devices to automatically remediate them.
    Where Can I Use This?What Do I Need?
    • NGFW
    • Prisma Access
    		The Cloud Identity Engine service is free; however, the enforcement points utilizing directory data may require specific licenses. Click here for more information.
    Security Risk for the Cloud Identity Engine obtains specific information to evaluate risk (such as an outdated OS, failed password attempts, or suspicious device activity) for users and devices. By using telemetry and receiving risk scores for these sources, the Cloud Identity Engine enables you to define the risk criteria for a group, and then, the Cloud Identity Engine automatically assigns users and devices to that group using the information it receives from your risk assessment sources. This enables closed-loop automation, since after you address the source of the risk for a user or device, the Cloud Identity Engine removes it from the group.
    Microsoft Entra ID analyzes user behavior and sign-in events to determine a user risk score and create a list of risky users. By identifying suspicious or anomalous user activity and assigning a risk score, you can quickly assess user risk level, evaluate priority, and take actions to reduce risk.
    SentinelOne reviews all device activity (such as processes) on the endpoint to assign specific attributes that determine the risk level of the endpoint.
    The SentinelOne Endpoint Detection and Response (EDR) agent monitors device activity and behavior. By specifying the attributes you want the agent to collect, you can identify at-risk device endpoints.
    The bidirectional integration between Prisma® Access and SentinelOne helps ensure your Zero Trust Security policy by continuously receiving device information and risk signals from SentinelOne and automatically enforcing access restrictions, such as quarantining the device.
    Saas Security Behavioral Threats monitors user activity across your SaaS and cloud applications and evaluates behavior against built-in behavioral threat ML and static policies. User’s anomalous behavior is captured via built in policies — such as a bulk data download, a spike in application usage, or access at unusual hours — and whenever it breaches the policies Saas Security Behavioral Threats assigns a risk score from Low to Critical. You can optionally also add users to watchlist on Saas Security Behavioral threats. The Cloud Identity Engine ingests this data automatically every five minutes and uses it to update Cloud Dynamic User Group membership.
    You can also use the Strata Cloud Manager to view the list of devices currently in quarantine.
    By:
    • continuously monitoring the device security posture and risk information from SentinelOne
    • updating and enforcing quarantine lists across all devices
    • removing devices after remediation
    • configuring Security Risk for the Cloud Identity Engine helps you enforce adaptive Security policy and just-in-time access.
    1. In the Cloud Identity Engine, select Security RiskRisk Sources.
    2. Click Add Risk Source.
    3. Select the type of risk source you want to configure.
      You can configure up to one Azure Active Directory source and up to one SentinelOne source.
      The Cloud Identity Engine uses the risk source you configure to obtain risk information.

    Configure Entra ID as a Risk Connection

    1. View and optionally edit the dynamic risky user groups.
      1. In the Cloud Identity Engine, select Security RiskCloud Dynamic Groups.
      2. Select the Risky User Group tab to view the groups that the Cloud Identity Engine creates to isolate users who it identifies as risky. You can optionally click the Details icon to view more information about the specific group.
      3. (Optional) Search the groups by entering a search query then click Apply Search.
        You can specify a Text Search or a Substring Search.
      4. (Optional) To include additional context and attributes for the cloud dynamic risky user group, select ActionsEdit, add the additional context and attributes, and Submit the changes.
      5. (Optional) To delete a group, select ActionsRemove and click Yes to confirm removal of the group.
    2. (Optional) Create a new cloud dynamic risky user group.
      1. Click Create New Risky User Group.
      2. Select Risky User as the Category.
      3. Enter the Common Name you want to use for the dynamic risky user group.
      4. (Optional) Enter a Group Email a Description for the group.
      5. Select the context and attributes to use for the dynamic risky user group.
      6. (Optional) To include additional context and attributes, click Add OR and optionally Add AND and select the context and attributes to use for the dynamic risky user group.
      7. Submit the configuration.

    Configure SentinelOne as a Risk Connection

    1. To configure SentinelOne as a risk source for Security Risk, collect the necessary information from your SentinelOne configuration.
      1. Before logging in to SentinelOne, copy the URL without the /login part of the address and save it in a secure location.
      2. Log in to SentinelOne and select SettingsUsersService Users.
      3. Click ActionsCreate New Service User.
      4. Enter a Name for the service user account and select the Expiration Date then click Next.
      5. Select Scope of Access and click Create User.
      6. Enter the Two-Factor Authentication Code within the 30-minute duration and click Confirm Action.
      7. Click Copy API Token to copy the API token and save it in a secure location. Because the API token only displays once, ensure you copy the token before clicking the Close button.
      8. (Optional but recommended) Click the Site button to confirm the creation of the site.
    2. Configure SentinelOne as a risk source in the Cloud Identity Engine.
      1. Enter the SentinelOne Source Name.
        The source name must use lowercase.
      2. Paste the Endpoint URL you copied from SentinelOne in step 1.a.
      3. Paste the Authorization Method API token you copied in step 1.7 and paste it in your SentinelOne configuration.
      4. Click Test Connection to verify that the Cloud Identity Engine can communicate with your SentinelOne configuration.
      5. After confirming that the Cloud Identity Engine can successfully communicate with your provider using your SentinelOne configuration, Submit the SentinelOne configuration.
    3. View or edit the dynamic risky endpoint groups.
      1. In the Cloud Identity Engine, select Security RiskCloud Dynamic Groups.
      2. Select the Risky Endpoint Group tab to view the groups that the Cloud Identity Engine creates to isolate endpoints that it identifies as risky. You can optionally click the Details icon to view more information about the specific endpoint group.
        The Cloud Identity Engine creates a default group without any attributes; you must specify the attributes you want to use for the group (see step 3.4).
      3. (Optional) Search the groups by entering a search query then click Apply Search.
        You can specify a Text Search or a Substring Search.
      4. Specify the context and attributes for the cloud dynamic risky endpoint group by selecting ActionsEdit, adding the context and attributes, and clicking Submit to confirm the changes.
      5. (Optional) To delete a group, select ActionsRemove and click Yes to confirm removal of the group.
        The Cloud Identity Engine does not currently support creation of a dynamic risky endpoint group if there is an existing group.
    4. Use Strata Cloud Manager to view the devices that have been quarantined.
      The Cloud Identity Engine places devices in quarantine using device security posture information and risk signals from SentinelOne. It removes devices from the quarantine list only when the device no longer meets any of the match criteria in the Cloud Identity Engine configuration. If a device is in quarantine due to SentinelOne information, Palo Alto Networks does not recommend manually removing the device from the quarantine list using Strata Cloud Manager or Panorama.
      1. Log in to Strata Cloud Manager.
      2. Select Manage ConfigurationNGFW and Prisma Access.
      3. Select Prisma Access as the Configuration Scope.
      4. Select ObjectsQuarantined Device List.
      5. Review the devices in the quarantine list to determine what remediation actions to take.

    Configure Cortex as a Risk Connection

    Complete the following steps to configure Cortex as a risk connection for Security Risk in the Cloud Identity Engine. For more information, refer to the Cortex documentation.
    1. If you have not done so already, configure Cortex to Customize Risk Scoring.
    2. Select the Cortex Directory you want to use as a risk connection for the Cloud Identity Engine.
    3. Click Continue.
    4. Manage your Cortex risk connection:
      • To synchronize all Cortex data, select ActionsFull Sync.
        A full sync typically takes longer to complete than a delta sync.
      • To synchronize only the data that has changed since the last sync, select ActionsDelta Sync.
      • To remove the Cortex risk connection, select Actions Delete and confirm the deletion.

    Configure Behavioral Threats as a Risk Connection

    Prerequisites:
    1. Connect SaaS Security Behavioral Threats as a risk source.
      1. In the Cloud Identity Engine, select Security Risk Risk Sources.
      2. Click Add.
      3. On the Palo Alto Networks UEBA tile, click Connect.
        The Cloud Identity Engine uses your existing tenant credentials to establish the connection automatically — no additional configuration is required. The tile shows Connecting while the connection is being established and Connected when the connection is successful.
    2. Create a Cloud Dynamic User Group based on Behavioral Threats data.
      1. In the Cloud Identity Engine, select Security Risk Cloud Dynamic Groups.
      2. Select the domain from the drop-down shown below. This must match the “Source Name” listed in the details of your PANW UEBA Risk Connection.
        More than one source can be configured to receive risk for a single directory but only ONE risk source can act as a source for Cloud Dynamic User Groups per directory/domain.
      3. On the Cloud Dynamic User Groups tab, click Create Create New Risky User Group and configure the following:
        • For Category, choose Attribute Based User Risk Group. This action opens the Context and Attributes fields.
        • Enter a Common Name.
        • Optional Enter a Group Email.
        • Optional Enter a Description.
        • In Context and Attributes, configure the filter criteria for group membership.
          • For Risk Level, choose the threshold that triggers group membership: Low, Medium, or High.
          • For Risk Reason, choose the specific behavioral policy that triggers membership from the drop-down of values.
    3. Click Submit. Group membership updates automatically as Behavioral Threats flags and clears users — no commit or manual refresh required.
      If you delete the Palo Alto Networks UEBA risk source, Cloud Dynamic User Groups created using SaaS Security Behavioral Threats signals are automatically deleted if the risk source is not reconnected within 30 days.

    Configure Risk Sharing for Shared Signals Framework Using Okta

    To learn how to configure risk sharing for the shared signals framework using Okta in the Cloud Identity Engine, see Send Cortex XDR Risk Signals to Okta.
    Next Steps:

    © 2026 Palo Alto Networks, Inc. All rights reserved.