End-of-Life (EoL)

Multi-Tenancy Architecture

The components of a multi-tenant deployment and the architecture of how the components communicate and interact.
Multi-tenancy architecture is based on the platform’s ability to run multiple instances (processes and data) of the XSOAR server 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 an MSSP can choose to run tenants on additional hosts. 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, MSSPs can add another host on which to run tenants. MSSPs can easily move tenants between hosts.
  • Geography
    : a global MSSP may have customers in multiple countries or even continents. To increase responsiveness, the MSSP may choose to locate a host or multiple hosts in each location.
  • Compliance
    : in some cases MSSPs are asked to run the tenant within the country where the customers’ offices are located or even within the customer’s internal network. For the latter, XSOAR supports installing a single host running a single tenant that can be installed on the customer’s premises.


Main host
The main host is the main instance in the architecture, from which you access and administer tenants (accounts), and create and manage hosts.
A host is an instance of Cortex XSOAR that acts as a proxy between the main host and tenants. In a multi-tenant deployment, hosts are not required, but enable you to scale your deployment by managing a collection of tenants. Data is not stored on host machines.
A tenant is also an instance of Cortex XSOAR which serves a customer, or account, and can be located either on the main or other hosts. The tenant has customer-specific data such as indicator, incidents, layouts, etc. which is stored in the tenant’s index of the database. Tenants share indicators with the main host using a shared database index. The tenant can also inherit content, such as playbooks, indicators, incident types, etc. from the main host using propagation labels.
Engines are smaller installations of Cortex XSOAR that are used to enable communication between 3rd-party integrations, which might sit in a different part of the network or might 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.

Data Segmentation

Cortex XSOAR content, including playbooks, automation scripts, incident/indicator layouts, among others, are managed on the main host and propagated to tenants.
Indicator Sharing
Each tenant account has a dedicated shared index in Elasticsearch, which enables tenant accounts to share local indicators to a dedicated Elasticsearch index, from which other tenants can ingest those indicators (as configured on the main host). By storing local indicators on a shared index, data segregation is maintained between tenants, but they are able to benefit from the locally discovered threat intel.


The main host and hosts communicate with each other using TLS 2.1 over port 443 (this is the default port, but can be configured). In addition, all hosts working with Elasticsearch communicate with the database over port 9200.
Requests to the tenants are sent through the hosts (main or other) on port 443. The hosts forward the requests to the tenants, which listen on ports 18501 and higher.

Recommended For You