> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/cortex-xdr-5.x/onboard-cortex-xdr/multi-tenant/what-is-cortex-xdr-multi-tenant.md).

# What is Cortex XDR multi-tenant?

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

Cortex XDR multi-tenant is designed for managed security service providers (MSSPs) and enterprises that require strict data segregation, but also need the flexibility to share and manage critical security practices across tenants. In Cortex XDR, MSSPs and enterprises can benefit from central licensing management and have access to a variety of configuration options for their child tenants. These options include defining which Cortex add-ons to include and configuring the number of endpoints and gigabytes per tenant. This flexibility allows multi-tenants to tailor security operations to meet the specific needs of each child tenant.

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

In the main account, you can see all alerts across all child tenants.

**Multi-tenant architecture**

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

| Component    | Description                                                                                                                                                                                                            |
| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Main tenant  | The main tenant, also referred to as the parent tenant, is used to access and administer your environment.                                                                                                             |
| Child tenant | A child tenant is an instance of Cortex XDR that serves an end customer, such as the customer of an MSSP, and is associated with the main tenant. Each tenant has customer-specific data, which are stored separately. |

{% hint style="info" %}

### Note

By default, multi-tenant licenses include one child tenant.
{% endhint %}

**MSSP multi-tenant**

Cortex XDR supports pairing multiple Cortex XDR environments with a single main account enabling MSSPs to easily manage security on behalf of their clients.

The following license options are available for MSSP multi-tenants:

| Option                       | Description                                                                                                                                                                                                                                                                                                                                                                                       |
| ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Central licensing management | The MSSP acquires a license for the main tenant (parent account) with resource allocations of total endpoints and/or GB for child tenants. From the main tenant, the administrator can then dynamically create child tenants and allocate the resources among its child tenants. All child tenants are automatically paired to the main tenant and the licenses are all owned by the main tenant. |
| Customer-owned license       | The MSSP acquires a license for its parent tenant. All end customers must acquire their own licenses in a separate contract. The child tenants must be manually paired to the main tenant.                                                                                                                                                                                                        |

**Enterprise multi-tenant**

In addition to multi-tenant for MSSPs, enterprises can use multi-tenancy to segregate data across subdivisions while allowing for co-management of environments with potentially diverse security stacks. With enterprise multi-tenant, there is central visibility of threats from the main account while providing varying levels of independence to the child tenants. Central licensing management and dynamic allocation of resources from the main account allow for flexibility according to changing needs.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://cortex-docs.paloaltonetworks.com/cortex-xdr-5.x/onboard-cortex-xdr/multi-tenant/what-is-cortex-xdr-multi-tenant.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
