Learn how to set up users and roles in Cortex XDR.
Cortex XDR uses both Role-Based Access Control (RBAC) and Scope-Based Access Control (SBAC) to manage roles with specific permissions for controlling user access.
RBAC helps manage access to Cortex XDR components and Cortex Query Language (XQL) datasets, so that users, based on their roles, are granted minimal access required to accomplish their tasks.
SBAC refines the RBAC permissions by granting access only to the relevant data that the user requires for their designated role. Users with Access Management permission can 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 more information on user scopes, see Manage user scope.
Cortex Gateway and the tenant have different options and requirements.
Location | Details |
|---|---|
Cortex Gateway | A centralized portal for managing roles, user groups, and users for all tenants. Any roles and user groups created in Cortex Gateway are available for all tenants. In Cortex Gateway, on the Permissions page, you can manage users that have been added to your Customer Support Portal account or view users that have been created in the tenant using SSO (you cannot edit SSO users in Cortex Gateway). All users must have at least one role or belong to at least one user group to be saved in the Cortex Gateway. You can exclude different tenants or different Cortex products. For more information, see Cortex Gateway Administrator Guide. Only users with the Account Admin role can manage roles, tenants, and user groups in Cortex Gateway. |
Cortex XDR tenant | (Recommended) All permissions and roles are specific to the tenant and exist only at the tenant level. Advanced settings, such as SBAC and Dataset access management, can be defined at the tenant level. Managing users, roles, scopes, user groups, and authentication settings in Cortex XDR 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 Manage user roles. |
Predefined user roles
Cortex XDR utilizes Role-Based Access Control (RBAC) to manage user permissions across all tenants and services. This framework ensures a secure separation of duties by granting users only the specific access required for their functional or regional responsibilities. Key features include:
Predefined Roles: Cortex XDR provides default roles with set permissions. While these cannot be edited directly, they can be copied and customized to meet your organization's specific security requirements. To view the predefined permissions for each default role, go to Settings → Configurations → Access Management → Roles.
Centralized Management: Roles can be configured globally within the Cortex Gateway or at the individual tenant level.
Visibility logic: Users may not see a specific feature if the feature is not supported by the license type or if they do not have access based on their assigned role or scope.
Tip
To quickly see exactly which pages and actions a role allows, click on the role name, which opens a read-only view of all checked permissions.
Role | Description | Recommended use |
|---|---|---|
Account Admin | A super user role that is assigned directly to the user in Cortex Gateway or a tenant and has full access to all Cortex products in your account, including all tenants added in the future. In Cortex Gateway, the Account Admin can assign roles to Cortex instances and activate product-specific Cortex tenants. This user has the same view/edit permissions in the tenant as the Instance Administrator. NoteThe user who activated the Cortex product is assigned the Account Admin role. You cannot create additional Account Admin roles in the Cortex XDR tenant. If you do not want the user to have Account Admin permission, you must remove the Account Admin role in Cortex Gateway. | Assign to the primary platform administrator, typically the security operations director, or designated platform owner. This role should be limited to a very small number of trusted users. |
Instance Administrator | View and edit permissions for all components and access all pages in the Cortex XDR tenant. The Instance Administrator can also make other users an Instance Administrator for the tenant. If the tenant has predefined or custom roles, the Instance Administrator can assign those roles with scopes to other users. | Assign to instance-level administrators who need full control over a specific tenant, but should not automatically gain access to other instances in the account. Common scenarios include multi-tenant deployments, MSSP environments, and delegated admins (for example, a team lead gets full admin on their team's instance without access to other teams' instances). |
Deployment Admin | Manage and control endpoints, installations, and configure Broker VMs. The Deployment Admin is a focused infrastructure role for teams responsible for rolling out and maintaining Cortex XDR Agents. It provides full control over agent installations, endpoint groups, and broker configuration, but excludes security operations capabilities like issue triage, case response, and detection rule management. | Assign to IT operations staff who need to deploy agents across the organization, manage agent groups and installations, configure broker VMs, and set up integrations. |
IT Admin | Manage and control endpoints and installations, configure Broker VMs, view endpoint profiles and policies, and view issues. The IT Admin extends the Deployment Admin with cases and issue visibility, host insights, and general configuration access. | Assign to IT administrators who need security awareness but without security authority. They need to see issues and policies (troubleshooting, understanding endpoint behavior), but cannot configure or respond to cases. |
Privileged IT Admin | Manage and control endpoints and installations, configure Broker VMs, create profiles and policies, view issues, and initiate Live Terminal. This permission is significantly more extensive than the standard IT Admin. It includes response actions, script execution, detection rule editing, cloud security policies, compliance management, and Live Terminal access. This role is closer to a Security Admin than a typical IT Admin. | Assign to senior IT administrators or IT security leads who need full endpoint management capabilities plus the ability to respond to cases, edit detection rules, manage policies/profiles, and access cloud security features. |
Scoped Agent Admin | Can only access product areas that support endpoint Scoped-Based Access Control (SBAC) - Agent Administration, Action Center, Response, Dashboards, and Reports. Scoped Agent Admin is designed for SBAC. All permissions are limited to the endpoint scope assigned to the user. The role focuses on response actions and agent management within that scope, with no access to investigation, detections, settings, or cloud security features. | Assign to regional IT admins, site-specific endpoint managers, or MSSP analysts who should only manage and respond to endpoints within a specific scope (for example, a geographic region, business unit, or customer). SBAC ensures they cannot see or act on endpoints outside their assigned scope. |
Role | Description | Recommended use |
|---|---|---|
Investigator | The base investigation role. Provides case/issue triage (edit) with investigation tools (such as query center and Query Library (edit), but no response actions and no detection rule management, host insights, or configuration access. | Assign to SOC Tier-1 analysts who triage incoming issues, update case status, and escalate to senior analysts. They can investigate using queries and view forensics data, but cannot isolate endpoints, run scripts, or modify detection rules. |
Privileged Investigator | Extends Investigator role with rules visibility, threat intel, and action center. Can view and triage issues, cases, and rules, and view profiles and policies, with Analytics management. No response actions, detection rule editing, endpoint, or configuration access. While a standard Investigator focuses on viewing and triaging issues, the Privileged Investigator is granted deeper View/Edit access to the investigation logic itself. | Assign to senior SOC analysts or threat hunters who need to understand detection rules, edit threat intel indicators, manage playbooks/scripts, and have visibility into endpoint policies, but who do not need to perform response actions like isolating endpoints or running Live Terminal. |
Responder | Adds response actions to the Investigator base. Can view and triage issues, and access all response capabilities (isolate, terminate, quarantine), but no Live Terminal, rule editing, or configuration access. | Assign to SOC Tier-2 analysts who need to take immediate containment actions (isolate, terminate, quarantine) when responding to confirmed threats, plus the ability to edit detection rules and manage threat intel. |
Privileged Responder | Can view and triage cases and issues, and combines full response (including Live Terminal), rule editing, endpoint policy management, and playbook/script editing. No access management, alert notifications, broker management, or data sources management. A Privileged Responder is primarily about advanced remediation and administrative control. | Assign to SOC Tier-3 analysts or senior case responders who handle complex cases end-to-end, from deep investigation through containment, remediation, and rule tuning. They need Live Terminal for hands-on endpoint investigation, script execution for custom response actions, and the ability to update detection rules based on findings. |
Investigation Admin | View and triage issues and cases, configure rules, view endpoint profiles and policies, and manage analytics. A senior investigation role focused on rule configuration, full investigation, response actions (action center, device control, host firewall), but no Live Terminal and no agent management. | Assign to detection engineers, SOC leads, or threat intelligence managers who focus on tuning detection rules, managing playbooks, and overseeing investigation workflows, but who delegate hands-on response actions to Responder roles. This role is about building and maintaining the detection and investigation infrastructure rather than performing case response. |
Security Admin | Can triage and investigate issues and cases, respond (excluding Live Terminal), and edit profiles and policies. A comprehensive security role with response actions (excluding Live Terminal), rule editing, policy/profile editing, agent management, and configuration access. A Security Admin maintains integrations, log flow, and system health. | Assign to security engineers or SOC managers who need to manage the security posture end-to-end, configuring detection/prevention rules, managing endpoint policies and profiles, setting up data sources and integrations, and responding to incidents with basic containment actions. |
Privileged Security Admin | Triage and investigate issues and cases, and respond to and edit profiles and policies. The most powerful security role. Everything Security Admin has, plus Live Terminal, file operations, script execution, playbook editing, device control editing, host firewall editing, audit, alert notifications, broker management, etc. | Assign to senior security administrators or CISO-designated security leads who need unrestricted security operations capabilities. They handle the most critical incidents requiring Live Terminal access, manage the full detection and response stack, configure broker infrastructure, and oversee audit trails. The only capabilities reserved above this role are user/role management (Access Management) and application hub management, which require Account/Instance Administrator. |
Viewer | Provides broad read-only access across almost all areas, such as dashboards, policies, endpoints, configurations, and audit, but has no edit permissions, including edit, respond, or configure. | Assign to stakeholders, managers, auditors, or compliance officers who need visibility into the security posture and operations but should never modify anything. Also useful for new SOC team members during onboarding who need to observe before being granted active permissions. |
Role | Description | Recommended use |
|---|---|---|
Developer | Read-only Cloud Application Security role designed for developers who need to see scan results and security findings but not modify security policies or rules. Users can view AppSec detection rules, policies, issues, and all scan types (periodic, CI/CD, PR scans), as well as cloud security dashboards and policies. They also have view access to dashboards, reports, issues, asset management, compliance, and edit access for the CLI tool. | Developers need to see the security issues found in their code, scan results, detection rule details, and policy violations, so they can fix them. This gives developers the visibility to remediate issues while keeping security governance in the hands of the AppSec Admin. |
AppSec Admin | Full permissions for all Cloud Application Security-related activities. Create and modify detection rules within the Code/Build domain, track progress, and adjust enforcement as needed. Additionally, triage and investigate findings, issues, and cases spanning from code to cloud. The role also includes complete visibility into all cloud assets. However, there are no response actions, no agent management, and no general configuration. | Assign to an application security team lead or AppSec engineer who manages the entire AppSec program. They configure what gets scanned, define detection rules for code vulnerabilities, set enforcement policies, triage AppSec findings, and manage the integration pipeline between code repositories and the security platform. |
DevSecOps | Provides complete visibility on all Cloud Application Security assets, findings, issues, and scans, plus edit permissions on Scan management pages. It sits between the Developer (view-only) and AppSec Admin (full edit) roles. DevSecOps users can view all AppSec data like the Developer, but additionally can track, investigate code scans, and rescan failed scans. They cannot modify detection rules, enforcement policies, or issue status. | Assign to DevSecOps engineers within development teams who need to actively manage the scanning pipeline, monitor scan progress, investigate scan failures, and trigger rescans, while leaving policy and rule management to the AppSec Admin. This role bridges development and security by giving DevSecOps practitioners hands-on scan management without the ability to weaken security policies. |
Compliance Administrator | View/Edit access to Compliance Catalog Assessment Profiles and Compliance Reports. Broad view access across the tenant, including cases/issues, forensics, host insights, detection rules, endpoints, configurations, and audit. No edit permissions on anything except compliance features. For more information about compliance permissions, see Compliance - Cloud permissions.Compliance - Cloud permissions | Assign to compliance officers or audit managers who need to manage the organization's compliance posture. Having read-only visibility into the broader security operations helps to understand context. |
AI Security Viewer | Provides read-only access to the AI Security module plus broad view access to related security areas. The role can view AI security findings, issues, and the AI security inventory. It also has view access to dashboards, cloud security dashboards, reports (with edit), issues, query center, compliance (view), cloud security rules/policies, CWP policies, asset management, and asset groups. | Assign to stakeholders, analysts, or team members who need to monitor AI security posture. See what AI models, applications, and data pipelines exist in the organization and what security issues have been identified, without the ability to modify AI security configurations. Useful for AI/ML team leads who want visibility into how their AI assets are being secured, or for SOC analysts who need to see AI-related findings during investigations. |
AI Security Administrator | View/Edit access to the AI Security module plus extensive capabilities, including issue triage, full response actions, playbook/script editing, compliance management, cloud security rule/policy editing, CWP policy editing, asset management, and data sources management. It is a powerful role that combines AI security management with broad security operations capabilities. | Assign to the AI security program owner or AI Security engineer who manages the organization's AI security posture end-to-end. They configure AI security policies, manage AI asset inventory, respond to AI-related security incidents, and ensure compliance of AI systems. The extensive response and investigation capabilities allow them to handle AI security cases directly, from detection through containment and remediation, without needing a separate security operations role. |
Data Security Viewer | Read-only access to the Cloud Data Security for monitoring the organization's cloud data security posture. It can view data security findings, data objects, data patterns, and classification results. It also has view access to dashboards (including cloud security dashboards), reports (edit), issues, query center, compliance, cloud security rules/policies, CWP policies, asset management, and DLP-related features, such as data-in-motion rules and endpoint applications. | Assign to Data privacy officers, DLP analysts, compliance team members, or data governance stakeholders who need to monitor the organization's data security posture, without the ability to modify any Data Security configurations, data classification policies, or DLP settings. |
Data Security Administrator | View/Edit access to the Data Security module plus extensive capabilities including issue triage, full response actions, playbook/script editing, compliance management, cloud security rule/policy editing, CWP policy editing, DLP management, and asset management editing. | Assign to the data security program owner or the Data Security engineer who manages the organization's data security posture. They configure data classification policies, manage data security findings, respond to data-related security cases, and ensure compliance with data handling practices. |
Identity Security Runtime Viewer | Read-only access to the baseline Identity Analytics and Identity Runtime Detection Rules. Users with this role can view identity-based analytics alerts, user and host risk scores, behavioral analytics profiles, and raw directory data queries. They cannot modify detection rules, analytics configurations, or any system settings. NoteRelevant for Behavioral Analytics & Identity Threat Detection and Response (ITDR). | SOC Tier-1 analysts, Tier-1 responders, or auditors who need to investigate identity-related analytics alerts and review user/host risk profiles without the ability to change detection rules or system configurations. This role provides sufficient access for issue triage, initial investigation, and escalation workflows. |
Identity Security Runtime Administrator | Full administrative (View/Edit) access to the baseline Identity Analytics and Identity Runtime Detection Rules. Users can view, create, modify, and manage identity-based analytics detection rules, configure the Identity Analytics module, and take response actions on identity-related findings. They have full control over the runtime identity analytics pipeline. NoteRelevant for Behavioral Analytics & Identity Threat Detection and Response (ITDR). | Senior SOC analysts (Tier-2/3), detection engineers, or security architects responsible for deploying, tuning, and maintaining identity-based analytics detection rules. This role is appropriate for team members who build and optimize the identity analytics detection pipeline, manage automated response playbooks, and need to take direct action on identity-related findings. |
Identity Security Viewer | Read-only access to the full Identity Security module, including both the baseline Identity Analytics capabilities and the advanced Identity Threat Detection and Response (ITDR) features. Users can view the Identity Security dashboards (Identity Overview, Risk Overview), browse the complete identity asset inventory across cloud, SaaS, and on-premises environments, review identity posture and threat issues, view detection rules, and monitor conditional access policies and audit logs. They cannot modify any configurations, rules, or policies. NoteRelevant for Identity Posture & Cloud Infrastructure Entitlements (CIEM). | Risk analysts, compliance officers, or SOC analysts (Tier-1/2) who need deep, comprehensive visibility into the organization's overall identity risk posture, spanning cloud entitlements, behavioral analytics, user/host risk profiles, and high-value asset exposure. This role is ideal for personnel who need to investigate identity-related findings across all data sources, generate reports for stakeholders, and monitor the effectiveness of identity security controls without the ability to modify them. |
Identity Security Administrator | Full administrative (View/Edit) access to the complete Identity Security module, including both the baseline Identity Analytics capabilities and all advanced Identity Threat Detection and Response (ITDR) features. Users have unrestricted control over the entire identity security posture. They can manage identity asset inventories, create and tune posture and threat detection rules, configure conditional access policies, manage data source connections, configure asset role classifications for risk scoring, and execute the full range of response actions. NoteRelevant for Identity Posture & Cloud Infrastructure Entitlements (CIEM). | Identity security engineers, IAM administrators, or risk managers who are actively responsible for the organization's identity security posture. This role is appropriate for personnel who configure behavioral analytics, build and tune detection rules across both posture and threat domains, manage conditional access policies, configure identity data source integrations, tune asset role classifications for risk scoring, and oversee the overall identity risk management program. This is the most privileged identity security role and should be assigned sparingly, following the principle of least privilege. |
Predefined roles designed for non-human, machine-to-machine authentication within the tenant.
Role | Description | Recommended Use |
|---|---|---|
Generic Collector | Generic Collector is a machine-only service account role with the minimum permissions required by the 3rd-party scanners. Its sole purpose is to authenticate API calls from external AppSec scanners (for example, Snyk, SonarQube, Checkmarx) that send their findings to the collector endpoint It is not intended for users. It follows the principle of least privilege; the API key can only ingest scan data. | Admins can see what role is assigned to collector API keys and understand the permission scope. |