ZPA Overview
A zero trust project is easy to start and hard to measure. The console tells you what each segment and each rule says, one at a time; it does not tell you how much of your ZPA is still exposed through wildcards and wide ranges, how much traffic still flows that way, or how many of your ALLOW rules actually say who they are for.
The Overview answers those four questions on one page, from the configuration ZHERO has already read and the activity the ZPA console keeps for the last 14 days.
It is for whoever reports on the ZTNA project, and for whoever has to make the numbers move.
When to use it
- Reporting progress: four numbers that read the same way every time, with their definitions next to them.
- Choosing what to narrow next: the broad segments that still carry the most traffic are the ones worth splitting first.
- Cleaning up access policy: the ALLOW rules without identity, and the rules written on named users instead of groups, listed and one click from their detail.
Where to find it in the UI
Hover the ZHERO icon, click Dashboards, and select the ZPA tab. When the Overview is enabled, it is the first sub-tab and the one the ZPA tab opens on, followed by Map, Topology and Fleet status (described in the ZPA Infrastructure Dashboard). The ZPA tab carries a BETA badge. The Overview appears on ZPA and Experience Center tenants.
The header says when the configuration was read and that the usage window is the last 14 days, which is how far back the ZPA console keeps activity. Three buttons sit next to it: Definitions, Refresh and Export.
How the page fills in
The page has two kinds of numbers, and they arrive at different moments.
- Configuration KPIs (KPI 1, KPI 3, KPI 4 and the policy shape) are computed from the segments and rules ZHERO has already loaded for the tenant. They appear without waiting for the console. If ZHERO is still reading the tenant, a loading state is shown, never a stale number.
- Activity tiles (KPI 2 and the usage tiles) come from the ZPA console, one short request per tile. Each fills in on its own as the console answers.
When a tile cannot be measured, it says why instead of showing a number: the console session expired, the service did not answer, your role cannot read ZPA activity, or the tenant does not offer that data. A Retry button sits next to every reason that a retry can change. The configuration KPIs stay visible either way.
Refresh reads everything again, configuration and tiles together, so the numbers on the page always come from the same moment.
What is exposed and how much it is used
KPI 1. Broad-scope segments
The share of enabled application segments whose domains or ranges reach more than a known set of applications. Each enabled segment falls into one class:
| Class | What puts a segment there |
|---|---|
| Critical | Two or more first-level wildcards (such as *.company.com, or a bare wildcard), or an address range of /16 or wider |
| High | One first-level wildcard, an address range wider than /24, or several narrower wildcards or ranges together |
| Medium | A deeper wildcard (such as *.app.company.com) or a range of /24 or narrower |
| Specific | Host names and single addresses only |
Critical, High and Medium together are the broad-scope segments. The headline is their share of all enabled segments, with a bar per class underneath and a count of domain entries by kind: first-level wildcards, deeper wildcards, large ranges, small ranges, host names and addresses.
These are the same classes the broad scope finding uses in Posture Insights, so the number of broad segments here matches the number of broad scope findings for the same tenant.
Open the broad segments lists them with their class (and their bytes, once KPI 2 has answered). Click a name to open the segment’s drawer.
KPI 2. Traffic through broad segments
The share of ZPA bytes in the last 14 days that went through broad-scope segments. A bar splits the total into the largest broad segment, the other broad segments and the specific ones, with the largest broad segment named.
- Segments with no bytes in the window count as zero traffic.
- When more segments carried traffic than one console answer can hold (500), the value is computed on the segments returned and the card says it is partial.
- With no traffic at all in the window, the card says No traffic recorded rather than 0%.
KPI 2 is the one to watch while you narrow segments: a broad segment that nobody uses is a cleanup, a broad segment that carries a third of your traffic is a project.
Investigate traffic
Next to each broad segment in KPI 1, and next to the largest broad segment in KPI 2, an Investigate traffic button opens ZPA Diagnostics on that segment, over the last 14 days, with the Domains + Ports drilldown already started. The hosts and ports really used come up without configuring anything: they are what a narrower segment would have to contain.
The button appears only when ZPA Diagnostics is available on your tenant. Opening diagnostics from anywhere else keeps its usual behaviour: the filter is applied and nothing starts on its own.
Who can reach it
KPI 3. ALLOW rules written on groups
The share of enabled ALLOW access rules for people whose identity criteria are groups, meaning SCIM groups or SAML attributes. Every rule in the population falls into one band, so the bands add up to 100%:
| Band | Counts as written on groups |
|---|---|
| Groups only | Yes |
| Groups and a few named users | Yes |
| Groups and many named users | Yes |
| A few named users only | No |
| Many named users only | No |
| Identity provider only | No |
| Without identity, including Browser Access unauthenticated | No |
A few named users means 3 or fewer. A rule with an identity criterion is a rule for people even when it also has a machine group or a client type criterion.
Some rules are not for people at all, and they are shown apart instead of being counted:
- Machine: no identity criterion and a Machine Group, or only the machine tunnel client type.
- Infrastructure: no identity criterion and only ZIA Service Edge, Cloud Connector, Branch Connector or log streaming client types.
KPI 4. ALLOW rules without identity
The number of enabled ALLOW access rules with no user, SCIM group, SAML attribute or identity provider criterion. The target is zero, and the card turns red when it is above it.
- Browser Access unauthenticated rules are counted: they let anyone in.
- A client type is not an identity. A rule limited to Client Connector or to ZIA Inspection, with nothing saying who, is counted.
- Identity provider only rules are shown apart as authenticated, not scoped: someone has to log in, but anyone who can log in is allowed. They are not counted here, and they appear as their own band in KPI 3.
- Machine and infrastructure rules are shown apart, as in KPI 3.
Open the rules lists the rules behind the count, and each apart line has its own list. Click a name to open the rule’s drawer.
What is never counted
In every KPI, two kinds of object are left out and shown on their own line:
- Disabled segments and rules (Disabled, not counted).
- Objects managed by Zscaler, such as the ones Deception creates (Zscaler-managed, not counted). ZHERO recognises them by their state in the configuration, never by their name.
BLOCK rules are not part of KPIs 3 and 4.
Policy shape
Four numbers on how the enabled ALLOW access rules are written:
| Value | What it counts |
|---|---|
| Enabled ALLOW rules | The rules the shape is computed on |
| Segments per rule (average) | Segments a rule names directly |
| Rules on whole segment groups | Rules that name a segment group rather than individual segments |
| Rules with a posture criterion | Share of the rules that also check device posture |
Usage in the last 14 days
Five tiles, each with its unit and the 14-day window:
| Tile | What it shows |
|---|---|
| Transactions | Every ZPA transaction |
| Error rate | Transactions that ended with an error, over all transactions |
| Active users | Distinct users with at least one ZPA connection |
| Discovered applications | Applications reached through ZPA, as the console counts them |
| Segments without traffic | Enabled segments with no bytes, out of all enabled segments |
ZHERO reads only these totals. Where the console answer carries a list of users next to the active users total, only the total is kept: no user name is read into a report or stored. When the traffic answer is partial (see KPI 2), Segments without traffic reads Unknown, because a segment missing from a partial answer may simply not have fitted in it.
Definitions
Every KPI card has an info icon with its definition, its target and the one thing to watch for. The Definitions button opens the full version above the cards: for each KPI, what is counted, what is excluded, the thresholds and the known caveats. Today those caveats are:
- IPv6 ranges are not classified yet and count as specific in KPI 1.
- SCIM attribute conditions (for example on department) count as named users in KPI 3, until ZHERO can read the attribute name.
- The window is 14 days, the activity the ZPA console keeps. It is never offered longer.
The definitions carry a version number. It changes only when the meaning of a KPI changes, not with every ZHERO release.
Export to Excel
Export builds a workbook following the same formatting as every other ZHERO export, with the credits. It holds the KPIs (each displayed value with the number behind it, so the sheet sorts and charts), the broad segments, the rules behind KPIs 3 and 4, the usage tiles with the time each was measured, and the definitions. Segment and rule names are resolved as the file is built.
The button stays disabled until the configuration is loaded: a file with the usage tiles alone would look like a complete Overview with empty KPIs.
The page shows current values only. It does not keep a history of the KPIs yet, so the workbook’s trend sheet carries a note instead of data points.
Limits and notes
- Coming soon: the Overview is being enabled progressively and may not be on your tenant yet.
- Your role decides what you see. If your admin role cannot read ZPA application segments or access rules, the configuration KPIs say so instead of showing a zero; KPI 2 needs the segments too. If it cannot read ZPA activity, the usage tiles and KPI 2 say so, and the configuration KPIs still appear.
- Microtenants: the KPIs are computed on what your admin scope returns.
- This is a read surface. Nothing on the page changes the configuration. Segments and rules are edited in the Zscaler console, and the entity drawers take you to them.
- During the trial, the KPIs, the policy shape, the usage tiles and the definitions stay open: they are the verdict. The export drawer opens and can be configured, and the download opens the upgrade prompt, as described in Trial and licence.
FAQ
Why does a rule limited to Client Connector count as a rule without identity? Because a client type says how someone connects, not who they are. Any user with Client Connector matches it. The rules that really are not for people, machine tunnels and infrastructure, are shown apart.
Why is a rule scoped only by identity provider not in KPI 4? Someone has to authenticate, so it is not open to anyone. It is not scoped either: anyone the identity provider accepts gets in. That is why it has its own line in KPI 4 and its own band in KPI 3, which keeps it out of the groups share.
KPI 1 and the broad scope findings disagree. They use the same classes and skip the same disabled and Zscaler-managed segments, so they should match. If they do not, refresh the Overview and re-run the analysis, so both read the same moment.
Why only 14 days? That is how long the ZPA console keeps activity. ZHERO does not invent a longer window.
Does the Overview start a report or a long job in the console? No. Each tile is a single request, with no paging and no report generation.
Related pages
- ZPA Infrastructure Dashboard: the other sub-tabs of the ZPA tab, connector health and the delivery chain
- ZPA Diagnostics Engine: where Investigate traffic lands
- Security Posture Dashboard: the broad scope findings and the ZPA score
- Analysis Templates catalog: the ZPA checks behind the findings
Next steps
- Read KPI 1 and KPI 2 side by side: the broad segments with the most traffic are your first candidates
- Press Investigate traffic on the largest one and note the hosts and ports really used
- Open KPI 4 and give every rule without identity an owner and a group
- Export the workbook and keep it with the project report, so the next one has a baseline