Multi-Tenant Overview - EoL - Multi-Tenant Guide - 6.11 - Cortex XSOAR - Cortex - Security Operations

Cortex XSOAR Multi-Tenant Guide

Cortex XSOAR
Creation date
Last date published
End of Life > EoL
Multi-Tenant Guide

Cortex XSOAR multi-tenant deployments for Managed Security Service Provider (MSSPs) and enterprises that require data segregation between tenant accounts.

Cortex XSOAR multi-tenant deployments are designed for MSSPs (managed security service providers) and enterprises that require strict data segregation, but also need the flexibility to share and manage critical security practices across tenant accounts.

Multi-tenancy enables you to manage multiple tenants from a single console. From the main account, you have a bird’s-eye view of all incidents and indicators across all tenants. You can create integrations and scripts for use across multiple tenant accounts, run commands across multiple tenant accounts, and switch easily between tenant environments.

Cortex XSOAR provides complete data segregation between customers in a multi-tenant deployment, and no incident data is stored on the main account. Each tenant runs as a separate process, 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 account level and pushed to tenants or is created within individual tenant accounts. Marketplace content packs are always installed on the main account and pushed to tenant accounts. You can define propagation labels per tenant, which allow you to selectively push content to one or more tenants. With a Threat Intel Management license and Elasticsearch, indicators can be shared across tenant accounts, saving investigation time and making it easy to block bad actors across your MSSP or enterprise.

Multi-Tenant for MSSPs

A multi-tenant deployment enables MSSPs to manage multiple accounts and maintain complete data separation if needed. You can centrally manage resources and reporting from the main account, push custom content to one or more tenants, search across incidents, and run commands across multiple 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 master and the tenant level. Each customer is a tenant, and the data for each tenant account is stored separately. This MSSP’s customers require keeping all data on-prem, so their deployment has only one tenant per host. Content specific to individual tenants is created on the tenant level, and content common to multiple tenants is pushed from the main account. The MSSP can provide customers with direct access to their tenant account, on a read only or read/write basis. The MSSP uses a Threat Intel Management license and Elasticsearch to share indicator information across multiple tenant accounts.

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 Cortex XSOAR product managers and the customer success team to discuss your business use case.

When using Cortex XSOAR multi-tenancy in an enterprise setting there are several limitations:

  • Data is not easily shared between tenants. For example, collaborating on an incident requires extra steps (such as mirroring between tenants). The exception is indicator data which can be shared if you have a Cortex XSOAR Threat Intel Management license and have a multi-tenant deployment with Elasticsearch.

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

  • Multi-tenancy architecture is more complex than Cortex XSOAR Enterprise server architecture and requires greater IT and computing resources. Also, server maintenance is more complex, since all accounts on a server may be affected when maintenance is performed on the server.

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.

Hosted Service

Cortex XSOAR offers a hosted service for multi-tenant deployments. Multi-tenant hosted accounts are only available for Enterprise, and are not available for MSSPs (managed security service providers). The Cortex XSOAR hosted service 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.Multi-Tenant for Enterprise

Multi-Tenancy Architecture

Multi-tenancy architecture is based on the platform’s ability to run multiple instances (processes and data) of Cortex XSOAR on a single server. Each deployment consists of a main server and tenant accounts. All tenant accounts can reside on the same (main) server or you can choose to run tenants on additional hosts. While tenant incidents can be searched from the main account, no incident data is stored on the main account.

Multi-tenant can be deployed with the Bolt database or Elasticsearch (which offers the option of High Availability, using multiple app servers).

BoltDB Architecture


Elasticsearch Architecture


High Availability Architecture

From Cortex XSOAR 6.1 and later, you can implement a multi-tenant high availability deployment. High availability keeps your system running even if one component of the system fails. To enable high availability (HA) in Cortex XSOAR, you must install Cortex XSOAR with Elasticsearch with multiple app servers or migrate to Elasticsearch with multiple app servers.Migrate Objects to Elasticsearch for Multi-Tenant


Main Account

The main account is used to access and administer your environment. Analysts can use the main account UI to access any tenant they have permissions for, and content configured in the main instance can be shared with some or all tenants. The main account and the hosts communicate over a secure SSL channel.


A tenant, also known as an account, is an instance of Cortex XSOAR which serves a customer and can be located either on the main host or other hosts. Each tenant must meet the hardware requirements of CPU, memory, and storage for Cortex XSOAR. Tenants have their own database partitions on the host. For Elasticsearch, each tenant has its own index in the cluster.

Each tenant has customer-specific data such as indicators, incidents, layouts, etc. stored separately (for Bolt deployment, different partitions, for ES different indexes).


Hosts are proxy servers that host tenants, and that allow the main server access to the tenant accounts. Hosts are physical Cortex XSOAR instances located across your deployment. You should use hosts for horizontal scaling and distributed architecture.

Tenants are deployed across hosts for several reasons.

  • Scalability: Full horizontal scalability - when a server or host is maxed out due to an excess of tenants on the same host, multi-tenant deployments can add another host on which to run tenants. You can move tenants between hosts.

  • Geography: You may have customers or corporate divisions in multiple countries or even continents. To increase responsiveness, you may choose to locate a host or multiple hosts in each location.

  • Compliance: In some cases, for regulatory reasons, you might be required to run the tenant within the country where an office is located or even within a client or division’s internal network. For the latter, Cortex XSOAR supports installing a single host running a single tenant that can be installed on premises.


Cortex XSOAR Engines are installed in a remote network and act as proxies, which enable you to access remote networks. They enable communication between third-party integrations, which might sit in a different part of the network or be blocked through firewalls, and the main host. 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 customer’s local network. Therefore, the engines are installed within the customer’s networks (normally on a local VM 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.).

Each tenant has its own public key which the engines use to connect directly to the tenants.


The system supports two basic types of users: local users that are created and managed within the system, and network-account users that are authenticated against a mapped user-group membership within an external directory service or other user management system by means of a configured integration.

Comprehensive RBAC (Role Based Access Control) for analysts and customer accounts enables different levels of access for MSSP and customer admins. RBAC is used at both the master level and the host level to ensure the correct access.Roles in Cortex XSOAR

Roles can be defined at the master or tenant level. If a role is used by multiple tenants, it is defined at the master level. If there is specific role behavior per tenant, the role is defined at the tenant level. For example, if an analyst on tenant A needs different permissions than an analyst on tenant B, those roles are created at the tenant level.