What is a ZPA microtenant?
A ZPA microtenant is a bounded administrative area within a Zscaler Private Access tenant. It is defined through an authentication domain and delegated to admins, typically per country, department or subsidiary. The microtenant admin manages the app segments, connectors and policies of their area independently, and sees dashboards and logs only for their own users. By default, the resources of different microtenants stay separated from one another; individual app segments can be shared deliberately. Microtenants solve an organisational problem this way: decentralised responsibility, without having to run separate Zscaler tenants for it.
ZPA microtenant in detail
The boundaries of responsibility are drawn clearly. Within their area, the delegated admin manages, according to Zscaler documentation, app segments and segment groups, servers and server groups, App Connectors including their groups, and the policies for their own users. Central foundations stay reserved for the default microtenant: IdP configuration, SAML attributes, enrolment certificates, and the administration of the microtenants themselves; for delegated admins, these areas are read-only.
The feature is activated through Zscaler Support. The documented limits include: no support when the disaster recovery feature is active, individual features such as AppProtection reserved for regular tenants only, and deleting a microtenant also removes its log receivers. For access across the boundaries of different areas, the admin shares app segments explicitly; separation stays the default case.
Why microtenants matter in Zscaler operations
Microtenants answer a question that keeps coming up at large groups and service providers alike: how does every unit get responsibility for its own area, without anyone losing the overview of the whole? Delegated administration shortens the path, because the subsidiary maintains its own app segments instead of requesting every change centrally. At the same time, the area boundary limits the damage from mistakes and the visibility of logs to that unit alone.
The price is coordination effort: who manages what, which segments are shared, which foundations sit centrally? Without a documented answer, tickets start bouncing back and forth between central IT and the area admins. And anyone who also runs several genuine tenants, for example as a service provider for many customers, needs one level on top of that: a consolidated view across every tenant and its microtenants.
Common sources of error
- Mistaking a microtenant for a tenant: expectations around contract, licence or data separation belong at the tenant level, not at the administrative boundary.
- Unclear responsibilities: the default microtenant is responsible for IdP, SAML attributes and certificates; otherwise, area admins wait for rights they will never get.
- Shared app segments with no inventory: after reorganisations, nobody knows any more which area shares which segments with whom.
- Disaster recovery planning without checking the documentation: the combination with microtenants is not supported according to Zscaler, and belongs in the architecture review early on.
Microtenants in practice: what CentaurNexus contributes
CentaurNexus manages several ZPA microtenants multi-tenantly from a single interface: the Microtenants feature shows the areas side by side, while the structural separation stays intact. Combined with RBAC domain scoping, every team sees only its own area of responsibility, from the group-wide helpdesk down to the subsidiary's area admin, with no Zscaler admin account needed. For service providers, there is also the cross-tenant view, which makes several customer tenants operable under one roof. What this looks like in practice is shown in the article Managing multiple Zscaler tenants from a single interface.
Related terms
Frequently asked questions about the ZPA microtenant
The tenant is the top-level instance of a company within the Zscaler service, with its own configuration and its own contract. A microtenant is an administrative area within a ZPA tenant: it is bounded through an authentication domain and delegated to admins, for example per country, department or subsidiary. No second tenant is created; instead, a boundary of responsibility is drawn within the existing one.
According to Zscaler documentation, they manage the configuration of their area independently: app segments and segment groups, servers and server groups, App Connectors including their groups, and the policies for their own users. Dashboards and logs show only their own area. App segments can be shared with other microtenants when needed.
Only the admin of the default microtenant manages the central foundations: IdP configuration, SAML attributes, enrolment certificates, and creating the microtenants themselves. For custom microtenant admins, these areas are read-only. This division of labour stops delegated areas from changing the tenant's shared authentication base.
Not by default: users reach the resources of their own microtenant and those of the global area, but not those of other microtenants. Where access is intended, the admin shares individual app segments deliberately with other microtenants. That way, separation stays the default, and sharing stays the documented exception.
According to the documentation, the feature is unlocked for the organisation through Zscaler Support. The documented limits are worth watching for: microtenants are not supported once the disaster recovery feature is active, individual features such as AppProtection stay reserved for regular tenants, and deleting a microtenant also removes its log receivers.
- Zscaler Help Portal: About Microtenants - help.zscaler.com
- Zscaler Help Portal: Configuring Microtenants - help.zscaler.com
Note: CentaurNexus is an independent product of SourcingBlox GmbH and not an offering of Zscaler, Inc. Product and brand names belong to their respective owners.