> 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-xdr-5.x/onboard-cortex-xdr/post-deployment-steps/manage-user-roles-and-access-management/manage-user-scope.md). # Manage user scope {% hint style="warning" %} ### Prerequisite * Configuring user scopes in Cortex XDR Access Management requires **View/Edit** RBAC permissions for **Access Management** (under **Configurations**). Account Admin and Instance Administrator roles are granted this permission by default. For more information, see *Predefined user roles* in [Set up users and roles](/cortex-xdr-5.x/onboard-cortex-xdr/deployment-steps/set-up-users-and-roles.md). * By default, **Enable Scope Based Access Control** is disabled in Settings → Configurations → General → **Server Settings**, and granular scoping is not enforced. Before enabling SBAC, we recommend that you first ensure that the users, user groups, and API Keys defined in Cortex XDR are granted the required access by assigning the relevant scopes. {% endhint %} Review the following topics: * [Set up users and roles](/cortex-xdr-5.x/onboard-cortex-xdr/deployment-steps/set-up-users-and-roles.md) * [User group management](/cortex-xdr-5.x/onboard-cortex-xdr/deployment-steps/set-up-users-and-roles.md#UUID-c6567cfd-f3f7-da7e-e266-557f3946ec41) * [Assign user roles and groups](/cortex-xdr-5.x/onboard-cortex-xdr/deployment-steps/set-up-users-and-roles.md#UUID-61ea0230-3be4-e77f-9899-950d47d74fd8) * [Manage user roles and access management](/cortex-xdr-5.x/onboard-cortex-xdr/post-deployment-steps/manage-user-roles-and-access-management.md)
What is SBAC? Cortex XDR enables you to use Scope-Based Access Control (SBAC) in combination with Role-Based Access Control (RBAC) to define precise access controls according to your organization's security policies. While RBAC defines what a role can access and the actions that can be performed, SBAC determines the specific data and content displayed when accessing these areas and performing those actions. Users with **Access Management** permission apply scopes to limit the data and content that users can be granted access to in Cortex XDR, which are divided into different scoping areas. The scoping areas include Assets, Cases and Issues, and Endpoints, which can be applied as relevant to the enforcement area or entity. For example, an Investigator role might have access to asset information based on the RBAC permissions, but the SBAC granular scoping configuration could limit that investigator's view and control to only assets within a particular scoping area. This hybrid approach ensures scalability and granular control, significantly strengthening system security by ensuring only authorized users are granted access to the relevant data that the user requires for their designated role. Granular scoping for all scoping areas is configured in users, user groups, or API Keys according to the designated user role. Users are granted granular scoping access based on the user role assigned to them either in a user group or directly.
Things to consider before configuring SBAC Before you begin setting Scope-Based Access Control (SBAC) granular scoping, consider the following information: * SBAC is disabled by default, which means that users have access to all content and data in the areas they have access to according to the RBAC permissions defined in their role. * To best address Cases that span across all scopes, we recommend that there always be designated users with full access to all cases, issues, assets, and findings. * Some areas and features in Cortex XDR do not comply with SBAC. In these cases, use RBAC permissions to restrict access. For more information, see [Functional areas that respect and don't respect SBAC](#functional-areas-that-respect-and-dont-respect-sbac). * Respecting SBAC has some performance overhead when opening the Cases, Issues, Findings, and Assets tables, which can take more time. * In Reports, SBAC applies when a report is manually generated. Scheduled reports run in the scope of the user who created or last updated the report template. Be aware that once a report is generated, it can be shared with others; exercise caution when distributing reports, as recipients might not be authorized to view the data they contain. * For users who upgraded from a previous version of Cortex XDR to the current version, see the [What's New in Cortex XDR 5.x Guide](/upgrade-to-cortex-xdr-5/whats-new-in-cortex-xdr-5.md) for specific changes that you should know about.
Understand scoping **Scoping areas** User Groups, Users, and API Keys can be scoped according to the following scoping areas: * **Assets**: Provides access to the assets associated with asset groups, and enables you to access their related cases, issues, and findings. When using asset groups, you can limit access based only on this list of attributes: Asset Class, Category, Provider, Region, Organization, Account Name, Realm, Business Application Names, Kubernetes Cluster, Kubernetes Namespace, Code Repository, and Asset Tags.

Note

Use the existing Realm attribute whenever you need to scope based on the Account ID.

* When you create or edit an Asset Group, the changes are applied immediately to new assets and to existing assets that have been updated. Yet, it can take a few hours for the changes to appear on existing assets that have not been updated. For more information, see [Asset groups](/cortex-xdr-5.x/detect-investigate-and-respond-to-threats/asset-management/asset-groups.md). * **Cases and Issues**: Provides access to domains to view their related cases and issues. * **Endpoints**: Applies scoping on an endpoint as an entity and provides access to **Endpoint Groups** and **Endpoint Tags** to view their related agent management and enterprise policies. {% hint style="info" %} ### Note This configuration can impact the visibility of the related **Security** domain in the **Cases and Issues** scope area, but with not affect asset visibility. {% endhint %} {% hint style="info" %} **Note** Access to the `asset_groups` dataset is managed through **Dataset Access Management** permissions within the user role. {% endhint %} **Scoping Behaviors** * When applicable, all conditions must be met to apply the scope configuration. For example, an issue with an affected asset is accessible only if the asset is in scope and the issue's domain is in scope. Similarly, a Case with multiple issues, where some have affected assets and others have affected endpoints, will be inaccessible if the Endpoint condition is set to 'No Endpoints,' even if the affected assets satisfy the Assets condition. * If only a subset of affected assets, endpoints, or issue domains are within a user's scope, the user can still view the full list of all items within a Case they have access to. While items outside of their scope remain visible in the list, the user cannot access further details or open the specific cards for those out-of-scope assets, endpoints, or issues. * Cases and Issues of deleted assets do not have affected assets and so are not affected by asset-led SBAC or Endpoints. * The behavior of cases and issues with affected endpoints depends on the **Endpoint Scoping mode**. * XQL queries that use the `cases` and `issues` datasets respect both **Assets** and **Cases and Issues** scoping configurations.
Functional areas that respect and don't respect SBAC It is important to review both the functional areas and features in Cortex XDR that are respected and not fully respected so you can decide what actions to take in your tenant. **Functional areas respected** Scope-Based Access Control (SBAC) applies to the following functional areas in Cortex XDR: {% hint style="info" %} ### Important Some areas and features in Cortex XDR do not respect SBAC. In these cases, use RBAC permissions to restrict access. {% endhint %} * **Cases, Issues, Findings, and Assets tables**: View and manage cases, issues, findings, and assets. SBAC applies to Assets, Cases and Issues, and Endpoints. * **Dashboard and Reports**: SBAC applies to XQL widgets using `cases`, `issues`, `findings`, and `asset_inventory` datasets, plus agent-related widgets. XQL widgets respect only the **Assets** scope. Refresh widgets to immediately reflect Asset Group changes. * **Public APIs**: APIs accessing Cases, Issues, Findings, and Assets respect the **Assets** and **Cases and Issues** scopes. * **Cortex Query Language (XQL)**: When using XQL with `cases`, `issues`, `findings`, and `asset_inventory` datasets, keep in the mind the following: * XQL respects asset-led SBAC and the **Cases and Issues** scoping configuration. * These scoping controls are enforced across all XQL-based features, including XQL queries and dashboard widgets. SBAC applies to the **Assets** scope. {% hint style="info" %} **Note** XQL queries for cases and issues do not respect the **Endpoints** scoping area configurations. {% endhint %} * **Endpoint Administration table**, **Policy Management**, and **Action Center**: SBAC applies to the **Endpoints** scope. * **Identity Security**: SBAC applies to the **Assets** and **Cases and Issues** scopes. * **Cloud Workload Policies** and **Graph Search**: SBAC applies to the **Assets** scope. **SBAC not fully respected functional areas** Review these limitations before configuring access: * Access to datasets: * Access to the `alerts` and `incidents` datasets do not support SBAC. As a result, consider limiting users from accessing these datasets by excluding access to the datasets mentioned above using Dataset Views, and only enabling access to `cases` and `issues` datasets that respect SBAC. * Access to the endpoints dataset via XQL does not respect endpoint-led SBAC. In this case, use RBAC permissions to restrict access to the endpoints dataset and permit access only to users who can see information for all agents. * Automation Rules: Automation rules are executed using the full system scope. Users authorized to edit or run automation rules can configure the system to run scripts or playbooks that can interact with data across the entire system. It is recommended to allow users with full access to all assets to create and edit automation rules. * Command Centers: Aggregate numbers in Command Centers can also sum up data that is not in the user scope. When pivoting from Command Centers to the Cases, Issues, Findings, and Assets tables, these tables do respect SBAC. We recommend limiting the users who access Command Centers, and these users should be granted a broader scope. For all other users, disable access in RBAC settings (Dashboards & Reports → Command Center Dashboards). * Host Inventory We recommend disabling access in RBAC settings (Investigation & Response → Search → Host Insights). * Timeline widget As a workaround, you can disable access through RBAC permissions by disabling Dashboards (Dashboards & Reports → Dashboards). * Notification Center * Agent Installation widget: This widget is not available for scoped users. * Drop-downs of cases and issues domains: Drop-downs of these domains display all domains. * Asset Group visibility in filters: Similar to domains, all Asset Groups are available for selection in filters across Cortex XDR, regardless of which specific Asset Groups are used for scoping a user. While SBAC limits the data (assets) a user can view, it does not restrict the visibility of the names of the Asset Groups themselves in filter drop-down menus.
How to configure granular scoping Granular scoping is configured in users, user groups, or API keys, and applied to the user roles assigned. Users are then granted granular scoping access according to the user roles assigned to them in a user group or directly. The instructions below explain how to configure granular scoping according to Palo Alto Networks best practices. Granular scoping is disabled and not enforced in Cortex XDR by default. Before enabling SBAC, we recommend that an administrator or a user with **Access Management** permissions first ensure that the users, user groups, and API Keys defined in Cortex XDR are granted the required access by assigning the relevant scopes. This user can then assign a scoping area to a Cortex XDR user (non-administrator), so the non-administrator user can manage only the specific scoping areas that are predefined within that scope. Any changes made to the granular scoping of a user, user group, or API key are recorded on the **Management Audit Logs** page (**Settings** → **Management Audit Logs**). These events are categorized with the **Type** set to **Permissions** and the **Subtype** set to **Scope Edit**. {% hint style="info" %} ### Note Make sure to assign the required default granular scoping for users. This depends on the structure and divisions within your organization and the particular purpose of each organizational unit to which scoped users belong. {% endhint %} 1. Ensure that you have the necessary administrator-level permissions. 2. Verify that the users, user groups, and API keys defined in Cortex XDR are assigned the relevant scopes. * To verify the granular scoping of a user, select **Settings** → **Configurations** → **Access Management** → **Users**, right-click the user name, and select **Edit User Permissions**. * To verify the granular scoping of a user group, select **Settings** → **Configurations** → **Access Management** → **User Groups**, right-click the user group, and select **Edit Group**. * To verify the granular scoping of an API key, select **Settings** → **Configurations** → **Integrations** → **API Keys**, right-click the API key, and select **Edit**. 3. In the **Scope** tab, expand each scoping area and review its configuration. * **Assets**: Select **No assets**, **All assets**, or **Select asset groups**. Asset scopes also affect cases, issues, and findings. * **Cases and Issues**: Select **No cases and issues**, **All cases and issues**, or **Select domains**. You can grant access to cases and issues without known assets or endpoints. * **Endpoints**: Select **No endpoints**, **All endpoints**, or specific **Endpoint Groups** or **Endpoint Tags**. 4. Click **Save**. 5. Repeat steps 2–4 for all users, user groups, and API keys. 6. Enable granular scoping in Cortex XDR. 1. Select **Settings** → **Configurations** → **General** → **Server Settings**, and select **Enable Scope Based Access Control**. 2. Optionally select the **Endpoint Scoping Mode**: * **Permissive**: Users with at least one scope tag can access an entity with that tag. * **Restrictive**: Users must have every scope tag assigned to the entity. 3. Click **Save**. Afterwards, users can access Cortex XDR only within their assigned granular scopes.
--- # 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-xdr-5.x/onboard-cortex-xdr/post-deployment-steps/manage-user-roles-and-access-management/manage-user-scope.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.