Introduction to Cortex XSOAR Multi-Tenant - Multi-Tenant Guide - 8 - Cortex XSOAR - Cortex - Security Operations

Cortex XSOAR Multi-Tenant Guide

Cortex XSOAR
Creation date
Last date published
Multi-Tenant Guide

Learn about Cortex XSOAR Multi-Tenant deployments that provide data segregation while enabling you to manage multiple tenants from a single console.

Cortex XSOAR in the Cloud enables you to use Cortex XSOAR for security orchestration, incident management, and investigation, without the infrastructure required for a multi-tenant on-premise deployment. Palo Alto Networks provides the service infrastructure layer, and you manage only the Cortex XSOAR application.

Cortex XSOAR Multi-Tenant is designed for managed security service providers and enterprises that require strict data segregation, but also need the flexibility to share and manage critical security practices across tenants.

Multi-tenancy enables you to manage multiple tenants from a single console. For a multi-tenant deployment, you create and manage the main tenant and child tenants from the Cortex Gateway.

In the main tenant (main account), you can see all incidents and indicators across all child tenants. You can create integrations and scripts for use across multiple child tenants, run commands across multiple child tenants, and switch easily between tenant environments.

Cortex XSOAR provides complete data segregation between customers in a multi-tenant deployment, and no incident or indicator data is stored on the main tenant. Each child tenant runs separately, and the data separation meets data privacy standards and compliance requirements.

In a multi-tenant deployment, content is either created or modified at the main tenant level and pushed to tenants or is created within individual child tenants. Content packs are always installed on the main tenant and pushed to child tenants. You can define propagation labels per child tenant, which allows you to selectively push content to the required child tenants.

The following options are available for multi-tenant:

  • Multi-Tenant for MSSPs

    A multi-tenant deployment enables MSSPs to manage multiple tenants and maintain complete data separation if needed. You can centrally manage resources and reporting from the main tenant, push custom content to one or more tenants, search across incidents from multiple child tenants, and run commands across multiple child tenants, without exposing any data across tenants.

    Example Use Case

    An MSSP has a pool of analysts in a central SOC. The analysts operate at the main and child tenants. Each customer is a tenant, and the data for each child tenant is stored separately. Content specific to individual tenants is created on the tenant level, and content common to multiple tenants is pushed from the main tenant. The MSSP can provide customers with direct access to their child tenant, on a read-only or read/write basis.

  • Multi-Tenant for Enterprise

    For most large enterprises, we recommend Cortex XSOAR Enterprise with RBAC implementation since this deployment can accomplish the majority of data segregation requirements. In some cases, however, a large enterprise with multiple divisions but with one centralized SOC managing those divisions may want to consider a multi-tenant deployment. We encourage you to consult with the Cortex XSOAR Customer Success team to discuss your business use case.


    When using Cortex XSOAR multi-tenant for enterprise:

    • Data is not easily shared between tenants. For example, collaborating on an incident requires extra steps (such as mirroring between tenants).

    • Tenants cannot change definitions that were set by the main tenant (e.g., playbooks, etc.).

    Example Use Case

    A large enterprise has acquired multiple business divisions in different geographic regions. Each division has a separate database, but the enterprise maintains one centralized SOC to manage all incidents.

Multi-Tenancy Architecture

Multi-tenancy architecture is based on the platform’s ability to run separate instances (processes and data) of Cortex XSOAR, linking each child tenant to a Cortex XSOAR main tenant. Each deployment consists of a main tenant and child tenants. All child tenants are associated with the main tenant. While tenant incidents can be searched from the main tenant, no incident data is stored on the main tenant.

Main Tenant

The main tenant is used to access and administer your environment. Analysts with permissions can view and edit child tenant data directly from the main tenant or can easily switch to work directly in the child tenant. Content configured in the main instance can be shared with some or all tenants, using propagation labels. The main tenant communicates over a secure SSL channel.

Child Tenant

A child tenant is an instance of Cortex XSOAR which serves an end customer, such as the customer of an MSSP, and is associated with the main tenant. Each tenant has customer-specific data such as indicators, incidents, layouts, etc. stored separately.


Multi-tenant licenses include one child tenant, by default.


Cortex XSOAR engines are installed on a remote network and act as proxies, which enable you to access remote networks. They enable communication between the main tenant and third-party integrations, which might sit in a different part of the network or be blocked through firewalls. Engines can be installed on their own or as part of an engine group, which distributes the load from an integration, or several integrations, between multiple engines.

In multi-tenant deployments, engines are often used to enable the network connectivity between an MSSP’s network and the end customer’s local network. The engines are installed within the customer’s networks (normally on a local virtual machine situated either in the customer’s DMZ or the security management network) and are programmed to communicate directly to the Cortex XSOAR account. Once the communication starts, a bi-directional tunnel is created between the MSSP and the customer’s network, allowing the MSSP to connect to the customer’s relevant resources (e.g. AD, mail server, firewall management server, etc.).

Role Based Access Control (RBAC)

Comprehensive RBAC for analysts and customer accounts enables different levels of access for MSSP and customer admins. RBAC is used at the main tenant level and the child tenant level to ensure the correct access.

In Cortex XSOAR, you create roles and then assign the roles to user groups.

There are two options for managing roles and user groups.

  • Roles and user groups created in the Cortex Gateway are automatically propagated to the main tenant and child tenants. Roles and user groups created in the Cortex Gateway cannot be edited directly on the tenants.

  • Roles and user groups are created at the main tenant and/or child tenant level. In this case, there is no propagation of roles and user groups from the main tenant to the child tenants. Roles and user groups must be defined separately on each tenant.

If you are using single sign-on, the mapping between your SSO provider and Cortex XSOAR is done via user groups.