Managing multiple Zscaler tenants from a single interface

MSPs, system integrators, and enterprise IT rarely operate just one Zscaler tenant. Anyone managing multiple tenants struggles with many logins, constant context switching, and a lack of a unified view. Here is how to bundle operations into a single interface without giving up hard tenant separation.

The problem: many tenants, many logins, no shared view

Zscaler scales excellently per tenant. But as soon as you manage multiple tenants, for example as an MSP with a portfolio of customer environments or as an enterprise with separate tenants per subsidiary or region, the friction shifts from the product into operations. Each tenant has its own admin portal, its own credentials, and its own context.

In everyday work, this means: a help desk agent takes a ticket but first has to find out which tenant the affected user belongs to, log in there separately, orient themselves in the right area, and document the process. With the next ticket, the game starts over, often in a different tenant. These context switches cost time, increase the error rate, and make clean, cross-tenant reporting laborious.

On top of this comes the rights question. To make the help desk operational at all, it often gets broader access than the individual process requires. With a single tenant, that is already delicate. Across an entire portfolio, it becomes a real governance issue: who was allowed to see or change what in which tenant, and when?

The solution: a cross-tenant cockpit based on the Zscaler OneAPI

CentaurNexus is a single pane of glass for supported Zscaler workflows, with production operation for EU customers entirely on STACKIT in the EU and documented privacy and data paths. It builds on the official Zscaler OneAPI and adds an operating and governance layer for multiple managed tenants. The Zscaler platform remains the source of truth.

Instead of five, ten, or more separate admin portals, your team works in one interface. Switching between tenants becomes a filter, not a new login. Search, findings, and requested changes run through the same operating logic, no matter which tenant is currently affected.

360-degree search across tenants

The core for the help desk is the 360-degree user picture. User Support Center and Unified Support Center bundle a user's status across ZIA, ZPA, and ZDX into one view: policy assignment, access paths, experience quality, and anomalies at a glance. The decisive point for multi-tenant operations is that this search works across the authorized tenants. The agent searches for a user and lands in the right context, without having to know beforehand which tenant to search in.

Important here: this picture works read-only, without granting real Zscaler admin rights. The help desk gets visibility for its work, not the keys to the entire configuration.

RBAC domain scoping: everyone sees only their area

So that centralization does not soften the separation, RBAC domain scoping applies. Every user is limited to exactly the tenants and areas they are authorized for. A help desk team that supports only a specific customer sees only that customer's data. MSP roles can work across multiple customers in a controlled way, if the mandate provides for it.

This boundary is technically enforced and not merely hidden visually. Tenant separation is a hard isolation at the data level, so a user cannot reach data they are not authorized for via detours or direct queries. Central operation and clean separation are thus not mutually exclusive; they are enforced together.

Four-eyes approvals and complete auditability

Visibility alone is not enough in operations; at some point changes have to happen. To keep this manageable across multiple tenants, write actions are modeled as requestable processes. An agent submits a request, an authorized role approves it. This approval process defined by the tenant policy can be made mandatory where changes are sensitive.

Every write action is auditable. Who requested, approved, or executed what, when, and in which tenant is documented in a traceable way. For regulated environments and for cooperation between MSP and customer, this audit trail is often the difference between a viable operating model and a constant justification discussion.

What the help desk process looks like in practice

The effect is immediate: faster processing through fewer context switches, clearly limited visibility per role, and a clean log across all tenants. The help desk becomes capable of acting without anyone becoming a blanket admin over other tenants.

Analysis for cross-tenant operations

Beyond the help desk, the cockpit provides tenant-specific analysis of orphaned or conflicting rules. Proposed corrections include context and impact and follow the approval path defined by each tenant policy. Every change remains traceable.

Tenant context before every action

A shared operator view must not blur tenant boundaries. Every read, ticket, export and write needs an unambiguous managed-customer context. Roles and row-level controls limit access to tenants that are actually assigned to the MSP.

Saved filters, recently opened tasks and notifications also remain tenant-bound. Changing customer context visibly resets the active selection. A decision cannot silently travel into another tenant.

Repeatable workflows with customer-specific responsibility

MSPs benefit from shared operating patterns for onboarding, help desk, approvals, reports and reviews. A template standardizes the workflow within the customer tenant policy. Responsible role, approval boundary, data sources and contract scope remain customer-specific.

Acceptance uses at least two separated test tenants with different roles and sources. Reads, writes, exports, ITSM assignment and audit must preserve separation in success and failure paths.