Manage user scope - Learn about Scope-Based Access Control (SBAC) and how to assign users to specific scoping areas in your organization. - Administrator Guide - Cortex XSIAM - Cortex

Manage user scope - Learn about Scope-Based Access Control (SBAC) and how to assign users to specific scoping areas in your organization. - Administrator Guide - Cortex XSIAM - Cortex - Security Operations

Cortex XSIAM 3.x Documentation

Product

Cortex XSIAM

Creation date

2025-07-15

Last date published

2026-06-11

Prerequisite

Configuring user scopes in Cortex XSIAM 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, groups, and roles.
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 XSIAM are granted the required access by assigning the relevant scopes.

Review the following topics:

What is SBAC?

Cortex XSIAM 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 XSIAM, which are divided into different scoping areas. The scoping areas include Assets, Cases and Issues, Endpoints, and Datasets Rows, which can be applied as relevant to the enforcement area, entity, or dataset. 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.
Policies and playbook execution can affect items outside the user’s scope, even though scoped users can’t view them. As a result, we recommend that users who write policies be granted access to all relevant policy assets, so they can review the effects of the policies.
Some areas and features in Cortex XSIAM 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.
Respecting SBAC has some performance overhead in the following areas:
- When opening the Cases, Issues, Findings, and Assets tables, which can take more time.
- When defining a filter for access row-level scoping on raw datasets, the more complex the filter is, the greater the performance overhead. For optimal performance, we recommend using a single field in the scope definition and simple comparison operators.
In Reports, SBAC applies when a report is manually generated, not when it is accessed in any other way. Scheduled reports do not run in any user context and are not subject to SBAC.
Be aware that even with scoped access to dataset rows applied, users can still indirectly access unauthorized dataset rows through dataset views and correlation rules. You can prevent this by ensuring that users don't have access to these dataset views and are unable to write correlation rules based on these datasets by enabling dataset access management for the relevant user roles and limiting access to the applicable datasets. You may also want to consider not allowing these dataset-scoped users to write correlation rules, which we recommend as a best practice. For more information on how to set dataset access permissions, see Manage user roles.
For users who upgraded from a previous version of Cortex XSIAM to the current version, see the What's New in Cortex XSIAM 3.x Guide 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.
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.
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.
Datasets Rows: Enables row-level scoping on raw datasets. This granular control directly affects product areas accessing these rows, such as Cortex Query Language (XQL) dataset queries and custom dashboard widgets. The datasets listed are a subset of datasets, determined by your assigned role, where you can configure row-level access for users. To grant access to specific dataset rows, you must configure a filter to explicitly define the allowable rows. When configuring this filter, you can encounter different scenarios. For more information, see Scenarios related to Datasets Rows scoping.

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, issues, findings, and asset_inventory datasets respect only the Assets scoping area configurations.
Scoping of Datasets Rows is performed in addition to user permissions to access the dataset.
Row-level scoping is only supported on raw datasets. This granular scoping directly affects product areas accessing these rows, including XQL dataset queries and custom dashboard widgets.
When a user's SBAC permissions change for a given dataset by updating the filter, queries executed before the change will retain and display their original results in the Query Center.
Note
Whenever a user's SBAC permissions are changed, Cortex XSIAM logs this event in the audit logs (Settings → Management Audit Logs). These monitored activity events are found on the Management Audit Logs table by filtering the Type column by Permissions and Subtype column by Scope Edit.
While users with row-level dataset scoping can view other users' queries in the Query Center, they are prevented from viewing the corresponding query results.

Functional areas that respect and don't respect SBAC

It is important to review both the functional areas and features in Cortex XSIAM that are respected and not fully respected so you can decide what actions to take in your tenant.

Scope-Based Access Control (SBAC) applies to the following functional areas in Cortex XSIAM:

Important

Some areas and features in Cortex XSIAM do not respect SBAC. In these cases, use RBAC permissions to restrict access.

Functional Area	Description	Related scoping area
Cases, Issues, Findings, and Assets tables	View and manage cases, issues, findings, and assets, and take actions in these tables.	Assets Cases and Issues Endpoints
Dashboard and Reports	Scoping takes place only on the following: XQL-related widgets based on XQL queries that use the `cases`, `issues`, `findings`, and `asset_inventory` datasets, and respect only the Assets scoping area configurations. Agent-related widgets. Note XQL-based dashboard widgets may require a few hours to initially reflect changes to the list or definitions of asset groups used for scoping. To view the most current data immediately, refresh the dashboard or its XQL widgets.	Assets Cases and Issues Endpoints
Public APIs	Public APIs that access Cases, Issues, Findings, and Assets information respect Scope-Based Access Control (SBAC).	Assets Cases and Issues
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 when accessing these datasets, including when using XQL queries and XQL widgets. XQL queries that use these datasets, respect only the Assets scoping area configurations. Note For Cases and Issues domains, a workaround is to create a Dataset View for each required combination of domains, and allow the relevant entity access only to this Dataset View, not to the underlying `cases` and `issues` datasets.	Assets
Endpoint Administration table	View endpoints and take actions on endpoints.	Endpoints
Policy Management	Create and edit Prevention policies and profiles, Extension policies and profiles, and global and device Exceptions that are within the scope of the user.	Endpoints
Action Center	View and take actions only on endpoints that are within the scope of the user.	Endpoints
Identity Security	View and manage identity assets, permissions, and issues that are within the scope of the user. For more information, see Manage RBAC and SBAC in Cortex Cloud Identity Security.	Assets Cases and Issues
Cloud Workload Policies	View Cloud Workload Policies when user access is scoped to any of the available options: All assets, No assets, or Select asset groups. When no SBAC restriction is applied, the user’s access is determined solely by their RBAC permissions. For more information, see Cloud Workload Policies and Rules.	Assets
Graph Search	Safely explore your environment in Graph Search with precise permission management. Assign users to User Groups and Asset Groups, ensuring they only see authorized graph nodes and relationships.	Assets
Access to datasets	Row-level scoping is only supported on raw datasets. This granular scoping directly affects product areas accessing these rows, including XQL dataset queries and custom dashboard widgets.	Datasets Rows

Ensure that you review the points below that explain the main functional areas with limitations with respecting SBAC, so you can decide how to handle this in your tenant. A suggested action is provided when applicable.

Access to datasets:
- Access to the alerts and incidents datasets does 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 enable access to cases and issues datasets that respect SBAC.
- Row-level scoping is only supported on raw datasets and no other dataset types, including in XQL queries and custom dashboard widgets. For these datasets that are not in the scope, all rows are available.
- When defining the filter for row-level scoping on raw datasets, queries based on the Cortex Data Model (XDM) aren't supported. XDM queries return specific rows only when All rows are accessible is selected when no filter is defined in the Datasets Rows scoping area. Otherwise, no rows are returned.
Dataset Views: Be aware that even with scoped access to dataset rows applied, users can still indirectly access unauthorized dataset rows through dataset views. You can prevent this by ensuring that users don't have access to these dataset views by enabling dataset access management for the relevant user roles and limiting access to the applicable datasets. For more information on how to set dataset access permissions, see Manage user roles.
Correlation Rules: Be aware that even with scoped access to dataset rows applied, users can still indirectly access unauthorized dataset rows through correlation rules. You can prevent this by ensuring that users are unable to write correlation rules based on these datasets by enabling dataset access management for the relevant user roles, and limiting access to the applicable datasets. You may also want to consider not allowing these dataset-scoped users to write correlation rules, which we recommend as a best practice. For more information on how to set dataset access permissions, see Manage user roles.
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 XSIAM, 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.
KSPM dashboard: Users can access all information on the dashboard when their user access is scoped to view All assets or assigned to the Instance Administrator role. Otherwise, users with granular scoping set to No assets or Select asset groups will have limited access to the dashboard. For more information on the KSPM dashboard, see Predefined dashboards.
Note
This feature is included with a Cortex XSIAM Premium, Enterprise, and NG-SIEM licenses.
Cloud Workload Policies: Users with SBAC granular scoping (in addition to the RBAC permissions required for Cloud Workload Policies) can only view Cloud Workload Policies when their access is scoped to any of the available options: All assets, No assets, or Select asset groups. When no SBAC restriction is applied, the user’s access is determined solely by their RBAC permissions. As a result, if you want users to be able to edit and modify Cloud Workload Policies, use the RBAC permissions. For more information on Cloud Workload Policies, see Cloud Workload Policies and Rules.

Scenarios related to Datasets Rows scoping

When configuring row-level scoping on raw datasets, you can encounter different scenarios. It's important to understand how best to handle these scenarios and what are the recommended best practices.

When integrating data from multiple sources, as a best practice, name each data source instance using a descriptive and consistent convention. This naming should clearly reflect the teams/groups that require access to the data through that specific instance, and the same naming value should be maintained across different sources when applicable. For example, use names like business_unit_x or subsidiary_y. Adopting this convention across all data sources simplifies the process of writing filters for each _raw dataset using the _collector_name field.

Sometimes, when trying to configure a filter to define the specific subset of rows a user is allowed to access in each raw dataset, the supported fields don't provide the necessary segmentation that you are looking for. In this case, define a _scope field in an [INGEST] section of the Parsing Rules for the applicable dataset ingesting data. The _scope field is added to the dataset columns, so that each row is imprinted during ingestion or parsing time with the _scope value. You can then use this _scope field in the filter. For more information on the fields supported, see Supported syntax in Step 3 of How to configure granular scoping of the table for Datasets Rows.

Consider this scenario for scoped users with Access Management permission:

When a user (non-administrator) with Access Management permission (User A) attempts to define row-level scoping for another user (User B), an issue can arise. User A can only see and configure SBAC filters for datasets that both User A and User B currently have access permissions (RBAC) to. Any datasets that User B can access, but User A cannot, will not appear for User A when defining access for User B.

To avoid these possible scenarios, we recommend users with access management permissions are granted full RBAC permissions to the complete superset of datasets for the other users who they're meant to apply row-level scoping. This ensures that users setting row-level scoping see the complete list of datasets they are authorized to scope.

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 XSIAM 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 XSIAM are granted the required access by assigning the relevant scopes. This user can then assign a scoping area to a Cortex XSIAM 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.

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.

Ensure that you have the necessary administrator-level permissions.
Verify that the users, user groups, and API keys defined in Cortex XSIAM 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.

In the Scope tab, expand the scoping areas to review the current granular scoping definitions by clicking the chevron icon (>) beside the scoping area title, and make any changes required. The following table explains the options available to configure:

Important

Before configuring, ensure that you review the Understand scoping section.

Scoping Area	Granular Scoping Configurations
Assets	Set the Scope by selecting one of the following: No assets: No asset is accessible. All assets: Defines access to all assets. Select asset groups: Defines access to the specific assets associated with the Asset Groups selected, and to view all their related cases, issues, and findings for these specific assets and Asset Groups. Under Select asset groups, define the specific asset groups that you want to grant access. Only Asset Groups relevant for scoping are listed, which are asset groups that are using only the asset attributes listed in Manage user scope (under Understand scoping → Scoping Areas → Assets). The scoping of assets also affects the scoping of cases, issues, and findings. Note Visibility of Security domain Issues that refer to assets with agents is controlled by the Endpoints scoping configuration.
Cases and Issues	Set the Scope by selecting one of the following: No cases and issues: Defines access to no cases and issues. All cases and issues: Defines access to all cases and issues. Users can view cases or issues referencing assets within their scope. Use the Assets section to define which assets are in scope. Select domains: Defines access to the domains selected to view their related cases and issues. Under Select domains, define the specific domains that you want to grant access. Users can only view cases or issues referencing assets and endpoints within their scope. Use the Assets section to define which assets are in scope. When selecting All cases and issues or Select domains, you can separately configure access to issues and cases that lack an asset reference or where the referenced asset is not in All Assets and All Endpoints inventories. To provide access, select the Allow access to cases and issues that are not referencing known assets or endpoints checkbox. Once selected, you can specifically control which users have access to issues and cases that lack Affected Assets (as seen in the issue’s panel) and Assets (as seen in the case's panel), or where the listed assets are not part of the Asset or Endpoint inventories. When the assets listed are not part of the inventories, the asset string is typically non-clickable. In some cases, such as for identity-related issues, assets may open a dedicated User Risk View, which differs from the standard inventories panels. In the Issues and Cases tables, such items can be identified by empty values in the following columns: Asset IDs, Target Agent Identifier, and Source Agent Identifier.
Endpoints	Set the Scope by selecting one of the following: No endpoints: Defines access to no endpoints with no ability to view their related agent management and enterprise policies. All endpoints: Defines access to all endpoints with the ability to view their related agent management and enterprise policies. This configuration can impact the visibility of related Security domain Cases and Issues, but will not affect asset visibility. Select specific (at least one required): Defines specific access to all endpoint groups by selecting Endpoint Groups or all endpoint tags by selecting Endpoint Tags to view their related agent management and enterprise policies. This configuration can impact the visibility of related Security domain Cases and Issues, but will not affect asset visibility.
Datasets Rows	Configure a `filter` to define the specific subset of rows a user is allowed to access in each raw dataset. A raw dataset is every dataset where Palo Alto Networks data is ingested out-of-the-box or third-party data is ingested using a configured dedicated collector, also called a data source. This filter configuration does not impact the visibility of cases and issues. Follow these steps to configure a `filter`: For datasets where no `filter` is defined, determine how to set the When no filter is defined option as either: No rows are accessible (default): Without a configured `filter`, no rows are accessible. Users can query the datasets in Cortex Query Language (XQL) as they have access, but the results will be empty. All rows are accessible: Without a configured `filter`, all rows are accessible. Users can query the datasets in Cortex Query Language (XQL) as they have access, and view all results. Note When defining a filter for row-level scoping on raw datasets, queries based on the Cortex Data Model (XDM) are not supported. XDM queries return specific rows only when All rows are accessible is selected and no filter is defined in the Datasets Rows scoping area. Otherwise, no rows are returned. Define any filters for the applicable datasets listed in the table: Scroll down the list of datasets to the dataset you want to apply a `filter` on, and click the Edit Scope icon. In the Define what rows are accessible window, continue to write the query for the `filter` in the query box (where the syntax is a limited subset of XQL) to limit the data rows for the selected dataset according to the access permissions you want the user to have. The beginning of the query is already defined before the query box, and there is no need to include this in your query. Important For optimal performance, we recommend using a single field in the `filter` definition and simple comparison operators. Supported syntax Fields You can define the rest of the `filter` in the query box, where only the following system fields are supported: `_broker_device_id`, `_broker_device_ip`, `_broker_device_name`, `_collector_id`, `_collector_ip`, `_collector_name`, `_collector_type`, `_device_id`, `_final_reporting_device_ip`, `_final_reporting_device_name`, `_log_type`, `_product`, `_scope`, `_reporting_device_ip`, `_reporting_device_name`, and `_vendor`. For more information on these fields, see the table that describes all the fields in the `metrics_source` dataset and `metrics_view` preset in Overview of data ingestion metrics. For more information on the `_scope` field (relevant when `_scope` is defined in the Parsing Rule), see [Scenario 3: Supported fields don't provide the necessary segmentation] in Scenarios related to Datasets Rows scoping.Manage user scope Comparison operators The following comparison operators are supported: Exact matches (`=`, `!=`) Comparing numerical values (`>`, `<`, `>=`, `<=`) Checking membership in lists (`in`) Querying arrays (`array_contains`) Partial matches (`contains`, `starts_with`): Using this operator has additional performance overhead, and we recommend avoiding its use. Example 14. If you only want a user to be able to access rows in the `pan_dds_raw` dataset, when the `_collector_name` is `bu2_collector` , you'd have to define the `filter` in the query box as: _collector_name = “bu2_collector” (Optional) Set the Time frame for the query. The default is Last 1 day. (Optional) You can preview the query results displayed based on your defined query by clicking Preview. You can edit your query until you're satisfied with the output. By default, the query results are limited to 1000 records. When you are finished, click Done. The Scope field for the dataset that you added the filter on is updated with the query. Example 15. In the above example, the Scope field displays `_collector_name = “bu2_collector”`.

Click Save.
Repeat steps 2 to 4 until you have configured all users, user groups, and API keys with the correct granular scoping access.
Enable granular scoping in Cortex XSIAM.
1. Select Settings → Configurations → General → Server Settings, and select the Enable Scope Based Access Control toggle.
2. (Optional) You can select the Endpoint Scoping Mode, which is defined per tenant:
  - Permissive: Enables users with at least one scope tag to access the relevant entity with that same tag.
  - Restrictive: Users must have all the scoped tags that are tagged within the relevant entity of the system.
3. Click Save.
When you are finished, all the users in Cortex XSIAM are now able to use Cortex XSIAM only within the granular scoping granted according to their assigned user roles.