Microtenants divide a ZPA environment into separate areas, for example by subsidiary, region or business unit. Functionally that is right: each area manages what belongs to it. Operationally it raises the question of how a central function keeps an overview without softening the separation. ZPA Microtenant Control manages several microtenants from one interface while the structural separation remains intact.
Why environments get divided
A group with several subsidiaries rarely has a single IT responsibility. Each company has its own applications, its own responsible people and often its own legal framework. Microtenants map that structure into the ZPA environment.
That is not a technical nicety but a reflection of reality. Whoever is responsible for a subsidiary should be able to manage its access without accidentally reaching into someone else's area.
The operational problem this creates
The intended separation has a consequence you only notice in operation. Anyone who has to answer a cross-cutting question suddenly faces several separate environments.
Such questions are more frequent than they first appear. How many external access rights exist across the group? Is a particular application reachable in several areas? Where does a rule apply that should apply everywhere? Each of these questions has so far required the same sequence: log in one after another, look, note, add up.
What ZPA Microtenant Control does
ZPA Microtenant Control enables the management of several microtenants from one interface. The overview arises at the interface, not by merging the areas.
That is the decisive point. The structural separation remains fully intact. What changes is not the boundary but the route to surveying it.
Overview without mixing
The legitimate objection to any cross-cutting view is: does it not soften exactly the separation you built? The answer depends on where the separation is enforced.
If it is enforced only through separate logins, then yes. If it is enforced underneath, through roles and through data handling, then no: each person sees exactly the areas they are entitled to, and the shared interface is merely how they reach them.
Who benefits most
The difference is most noticeable where a small central team looks after many areas: in groups with a lean central IT function, and in system integrators responsible for several customers.
There, switching between environments is not an inconvenience but a noticeable share of working time that benefits nobody.
A shared interface is not shared data handling. What matters is that the boundary is enforced beneath the interface, through roles and data handling, not through separate logins.
Frequently asked questions
What is a ZPA microtenant?
A subdivision within a ZPA environment that separates areas of responsibility, for example by subsidiary, region or business unit.
What does ZPA Microtenant Control do?
It enables the management of several microtenants from one interface, while the structural separation between the areas remains intact.
Does a shared interface soften the separation?
Not if the boundary is enforced beneath the interface, through roles and data handling. Each person then sees exactly the areas they are entitled to.
Who benefits most from this?
Organisations where a small central team looks after many areas: groups with lean central IT, and system integrators with several customers.
Which questions does it make answerable?
Cross-cutting questions that previously required several logins: how many external access rights exist group-wide, where a particular application is reachable, whether a rule applies everywhere.
Sources
See the workflow in context
Pick the matching role in the demo launcher. The demo uses prepared sample data.
Open demo launcher