ZPA Part Three: A Resource Nobody Declared Does Not Exist

ZPA Part Three • Segments and Groups • Field Notes

Segments, groups, and the conversation with the hosting team that nobody puts on the project plan.

Why this one exists

This is the first of a series that has been overdue for a while.

For years this material lived on my laptop with no structure at all, except the structure I carried in my head. Change records. Tickets. Long support threads that eventually produced an answer worth keeping. Documentation read at the point where documentation stops being enough. Exam preparation, which has the useful side effect of forcing you to be precise about things you thought you already understood.

None of it was written down in a way anybody else could use, including future me. So this series is the attempt to organise it: what actually happens in production, why, and what I would tell someone starting the same project tomorrow.

It continues ZPA Part Two, which ended on a deliberate cliff: reachability is not authorization. The App Connector can reach hundreds of private servers. That fact grants nobody anything.

This article is the other half. How you describe an application to ZPA, how the three objects that describe it relate to each other, how they match traffic, and what changes for the people who build the applications in the first place.

Note on the examples: everything here is generalised. Domains, segment names and hostnames are placeholders, and any figures used to illustrate a pattern are illustrative rather than measured.

Part one

The model, and the people it surprises

1. A resource nobody declared does not exist

ZPA operates on default deny. Access to an application segment is denied until an access policy explicitly allows it. That sentence is easy to nod along to and much harder to live with, because of what it implies for everything upstream of the security team.

In the network model, a new server is reachable the moment it exists. Nobody decided that. It is the default, and the default is generous. The hosting team provisions, configures, hands over a hostname, and reachability arrives for free because everything on the network reaches everything else unless something is deliberately in the way.

In a declared model, the same server is invisible. Not protected, not restricted — absent. It becomes reachable when somebody states what it is, which ports it uses, and who is allowed in.

Two models side by side: in the network model a new server is reachable by everyone the moment it exists, in the declared model it is invisible until somebody states what it is and who may use it — Figure 1. The same new server in two worlds. On the left, everybody, immediately, and nobody wrote it down. On the right, only who a policy names, which means somebody had to decide. Original diagram — Zero Trust Navigator.

This is the actual content of zero trust, and it is worth being blunt about it. Zero trust does not mean the hosting team builds a server, everybody reaches it, and a product protects it afterwards. It means the resource is mapped, with the correct permissions, before anyone reaches it at all.

No implicit access, and a real effort to define a perimeter that is clear rather than assumed.

2. The objection you will hear in week two

“So now, to publish an application, I have to open a ticket with the ZPA team?”

Yes. And the person asking is not being obstructive. From where they sit, something real has been taken away.

Until yesterday, building a server was a self-contained act. Provision it, configure it, hand over the hostname, done. It was reachable because everything on the network is reachable. Today the same person is told to declare the application, document which ports it actually needs, and name who should be allowed in. Three things that used to be somebody else’s problem, or nobody’s.

It feels like lost autonomy. It also feels slow, and in week two it usually is.

But look closely at what is being asked, because none of it is new work. Somebody always needed to know which ports that application uses. Somebody always needed to know who was supposed to reach it. Those questions existed the whole time. They were simply never asked, because the network answered them by default and answered them generously.

The declaration requirement does not create the effort. It makes visible an effort that was always owed and never paid.

The proof is already on your file servers

If that sounds abstract, look at the access model the organization already has, because that is where new ZPA permissions usually get copied from.

Access to private applications is very often conceived the way file share permissions were conceived: a group per folder, created years ago, inherited, nested, never reviewed. Nobody removes anyone from a group. Removing people breaks things, and breaking things gets noticed in a way that over-granting does not.

One employee moving through four roles over a long career, accumulating access groups at every move and losing none, ending with an entitlement far larger than what they use — Figure 2. Four moves, groups added at every one, nothing ever removed, and a small fraction of it actually used. An illustrative pattern rather than measured data — but one most people recognise immediately. Original diagram — Zero Trust Navigator.

The predictable result is the long-serving employee. Many years in the company, several departments, every move adding a group and none ever taking one away. They end up holding an access footprint that would make the Eye of Sauron feel under-provisioned, and they use a small fraction of it.

Ask what that looks like to an auditor examining segregation of duties. It looks like one person with visibility across functions that are supposed to be separated, with no documented justification, because the justification was “they used to work there”.

That is indefensible, and it was indefensible before ZPA existed. ZPA does not create the problem. It makes the problem writeable down, which is uncomfortable precisely because it is the first step to fixing it.

One caution, because this argument can be used badly. “Zero trust requires it” is not an acceptable answer to “this slows us down” if onboarding an application genuinely takes three weeks. If the process is slow, the resistance is correct and the platform team should fix the process rather than lecture about principles.

The declaration model is defensible only when it comes with a defined intake, a named owner, a realistic turnaround and a self-service path for routine cases. Ask for discipline and supply a service in return. Ask for discipline and supply a queue, and the shadow paths come back within a quarter.

3. The internet café, a model worth borrowing

There is a useful picture for what this architecture is, and it comes from somewhere unglamorous: guest wireless with client isolation.

On that network every device reaches the gateway, and no device reaches another device. Not because a firewall rule forbids it. Because there is no path. The shape of the network itself makes device-to-device traffic impossible, and no configuration mistake can accidentally enable it.

A guest wireless network with client isolation where every device talks only to the gateway and never to another device, used as a model for how ZPA brokers private application access — Figure 3. Every line goes to the gateway. There is not a single line between two devices, and that is the whole point. Original diagram — Zero Trust Navigator.

Private application access under ZPA has the same shape. The client talks to a Service Edge, public or private. The App Connector talks to a Service Edge, from beside the application. Neither talks to the other directly, and neither talks to anything else.

Client-to-client and server-to-client scenarios exist — remote assistance, RDP to an end-user device, software distribution — and they follow the same rule. The session is brokered through the platform and logged with its own access type, rather than routed between the parties.

The same logic extends to workload traffic through Cloud Connector: workloads in different networks reach each other through the exchange rather than through peering, transit gateways and the routing conflicts that come with them.

There is no lateral movement because there is no lateral path, which is a different guarantee from a rule that says no.

Part One of this series told the story of a compromised laptop that encrypted file servers across a company because the VPN gave it a network. This is the structural answer to that story. The malware did nothing clever; it used the connectivity it was handed. Here, there is none to hand.

Part two

The three objects

4. Three objects, three questions

Most segmentation designs that look correct and still do not work fail here, because the three objects get confused with each other. Each one answers exactly one question.

The three objects of a ZPA segmentation design: the application segment declares what the application is, the server group says which connectors can reach it, and the segment group is what access policy talks to — Figure 4. The application segment is the hinge. To its left, what policy is allowed to name. To its right, what can physically reach the thing. Original diagram — Zero Trust Navigator.

The application segment: what is the application?

This is the description of the thing itself. The names it answers to, as FQDNs, IP addresses, subnets or wildcards. The TCP and UDP ports it actually uses. Its bypass behaviour, its health reporting mode, and the other settings that decide how it behaves rather than who may use it.

Design these by application, not by subnet. A subnet is a fact about your network; an application is a fact about your business, and it is the second one that policy needs to talk about. If the segment is named after a VLAN, the access policy that references it will inevitably be named after a VLAN too, and nobody will be able to answer “who should have this?” in a review two years from now.

The server group: what can physically reach it?

The server group associates the application with the App Connector Groups that sit near it. This is reachability and nothing else. It grants no access, authorises no user and expresses no intent. It answers a question about topology.

This is the distinction Part Two spent an entire article on, and it is worth repeating in a different form: a connector that can reach an application has not decided anything about who may use it.

The segment group: what does policy talk to?

Access policy does not reference individual application segments. It references segment groups, which are bundles of segments. That indirection is not bureaucracy: it is what stops the policy set from growing one rule per application until nobody can read it.

Group by business meaning. “Finance applications”, “engineering tooling”, “third-party accessible”. A segment group whose name describes infrastructure rather than purpose is a segment group that will be impossible to review.

Field note: put a business meaning in the segment group, a technical boundary in the server group, and nothing vague in either. When a segment does not work, the first diagnostic question is which of the three objects you got wrong — and it is usually not the one you were looking at.

5. Port discipline: the exact ports, and never 53

Two rules that look like housekeeping and take production down when ignored.

Why port 53 should be excluded from application segments, because the connector resolves names with its own resolver, and why wide port ranges consume the connector health check budget — Figure 5. Two rules, two mechanisms, two very different failure modes. Neither of them announces itself as a port problem when it goes wrong. Original diagram — Zero Trust Navigator.

Why port 53 does not belong in a segment

Zscaler recommends excluding TCP and UDP 53 from application segment port ranges, and repeats the recommendation in the application discovery guidance, where port ranges are deliberately wide. The reason is worth understanding rather than obeying.

In ZPA, the client never resolves the private application. The Client Connector captures the FQDN, the broker matches it against the configured segments, and the actual name resolution happens on the App Connector, using the resolvers configured on that connector.

So the endpoint has no reason to reach an internal DNS server through ZPA. Publish port 53 in a segment and client DNS queries start being brokered instead, which interferes with the interception ZPA already performs to hand back a synthetic address. The practical outcome reported in the field is broken resolution, with a symptom that looks like anything except a port range somebody configured.

This is also the mechanism behind a class of tickets that begin “it works by IP but not by name”. The client’s DNS is almost never the problem. The connector’s is.

Why 0–65535 is not a shortcut

Every port you declare is a port the connector probes for health. Directionally, the volume grows with the number of FQDNs, multiplied by the addresses each name resolves to, multiplied by the TCP and UDP ports declared. A single FQDN on two ports is a handful of checks per cycle. A wildcard with wide ranges multiplies that by every address returned, for every name in the domain.

A segment defined as “all ports except 53” asks each connector to probe over sixty-five thousand ports per address. Connector capacity is finite, and the failure mode is not a clean error — it is a connector busy doing something nobody asked for.

State the ports the application actually uses. If nobody knows them, that is the finding, not an argument for opening all of them.

Part three

How segments actually match

6. Specificity does not create priority. Subtraction does

Sooner or later a wildcard segment and a more specific segment will cover the same name. Everybody assumes they know what happens next, and the assumption is subtly wrong in a way that costs an afternoon.

Say the tenant contains *.example.com, and later somebody adds app.example.com as its own segment. The instinctive model is that the more precise segment outranks the broader one, the way a longer prefix wins in a routing table.

That is not the mechanism. By default, the destination is removed from the wildcard application segment. The name is subtracted from the wildcard’s scope, so the wildcard is no longer a candidate for it at all.

Two set diagrams showing that without multimatch a specific segment is subtracted from the wildcard that would otherwise contain it, while with multimatch both segments continue to match the same name — Figure 6. On the left the name is carved out of the wildcard. On the right, with multimatch enabled on both, it belongs to both segments at once and neither of them wins. Original diagram — Zero Trust Navigator.

The difference between “outranks” and “is subtracted from” sounds academic until you look at ports. If the specific segment declares only 443, and the wildcard declares every port, traffic to that name on 8443 is not caught by the wildcard as a safety net. The wildcard does not cover that name any more. The traffic is dropped.

What multimatch actually does

Multimatch changes the subtraction. With it enabled, the name stays in both segments and both continue to match. That is its entire purpose: to allow a request to match multiple application segments, covering ports and names the specific segment does not declare, so access does not fail for a reason nobody anticipated.

What it does not do is introduce a ranking. Two segments matching the same request are both valid candidates, and ZPA does not pick the more specific one. The decision moves somewhere else entirely.

Multimatch exists to prevent access failure, not to rank segments. When two segments match, the access policy order decides — top down, first match wins.

This has a practical consequence that is easy to miss during troubleshooting, and it is worth stating carefully because it inverts the instinct. If the wrong segment appears to be handling a request, the problem is very often not the segment definition at all. It is the order of the access policy rules, which is a completely different place to look.

A matrix of four multimatch combinations between a wildcard segment and a more specific segment, showing which segments become candidates on a declared port and on an undeclared port — Figure 7. Four combinations. Only the top row leaves two candidates standing, and that is the row where policy order does the deciding. Everywhere else the matching itself has already reduced the field to one, or to none. Original diagram — Zero Trust Navigator.

Two rows deserve highlighting. Setting multimatch on one segment and not on an overlapping one is not a valid configuration — the console refuses it, because segments sharing a name have to agree. And the default state, multimatch off everywhere, is the row where the undeclared port is silently dropped despite a wildcard that appears to cover everything.

Field note: enable multimatch across every segment in the chain, or across none of them. Matching stops at the first segment that does not support it, so a chain is only as permissive as its least permissive link.

Part four

Getting from nothing to a design

7. Discovery, and the effort that pays twice

All of the above assumes you know what your applications are. In most environments, nobody does.

Not through negligence. The VPN worked because it was broad, and over the years the organization stopped asking questions that the network was already answering. Which FQDNs are still alive. Which ports a given application really needs. Which internal tool is used only during month-end closing. Which “temporary” server quietly became production some time around 2019.

Discovery is how that inventory gets built. ZPA supports it directly: a segment with a broad domain or subnet and wide port ranges, a policy permissive enough that people keep working, and passive observation of what users actually request. It is observation, not scanning — an application is discovered when somebody asks for it.

Two practical notes from the guidance worth having before you start. Keep TCP and UDP 53 out of those wide ranges, for the reasons in section five. And if an identity provider domain overlaps the domain you are discovering, bypass it explicitly in ZPA, or you will be debugging reauthentication failures instead of collecting data.

On the AI-powered recommendations

ZPA can analyse the access logs discovery produces and generate recommended application segments, grouped by similarity: IP addresses, user access behaviour, domain name patterns, applications that keep appearing together. Recommendations can be merged into existing segments, adopted as new ones, or ignored.

It is a genuinely useful accelerant, and it is worth being clear about one thing before it appears in a project plan: this capability is tied to the Segmentation add-on licence, and how often recommendations can be regenerated depends on the subscription. It is not simply present in every tenant.

Plan the discovery phase so that it works without the recommendations, and treat them as an accelerator if they are licensed. A discovery plan that assumes them and then discovers a commercial conversation loses more time than the feature saves.

The effort pays twice

Zero trust is not visibility recovered cheaply. The work of finding out what people actually use is real, it takes months rather than weeks, and it is tedious in a way that no diagram conveys.

But it produces two results, not one.

The discovery effort producing two results: a controlled access model, and separately the application inventory the organization never had — Figure 8. Nobody would fund the right-hand column on its own. Everybody needs it, and this is the only project that ever produces it. Original diagram — Zero Trust Navigator.

The first is the one the project was approved for: a controlled access model where every application is declared, every port stated deliberately, and every access traceable to a decision somebody made.

The second is the one nobody would ever have funded separately: an accurate picture of what exists, what is used, by whom, and what is not used by anyone. Applications with no owner. Servers that were supposed to be decommissioned. Dependencies that only surface at quarter end.

The discovery work is not overhead on the security project. It is a second deliverable, and for many organizations it is the more valuable of the two.

8. The wildcard: a good instrument and a bad destination

Discovery needs a wildcard. A segment covering a broad domain with wide ports, and a policy permissive enough that people keep working while you learn. That is the correct configuration for that phase, and it is deliberate.

Months later, nothing about the configuration has changed. The phase has.

The same wildcard segment seen in two phases: a legitimate discovery instrument early on, and an unintended catch-all once the environment is mapped — Figure 9. Nothing in the configuration changes between these two pictures. Only the phase of the project does, and only one of the two is still deliberate. Original diagram — Zero Trust Navigator.

The same wildcard is now a catch-all. Everything ending in that domain matches it, including hosts that were never meant to be published through ZPA, and including names that should still be resolved by corporate DNS and reached the way they always were. The health check budget pays for all of it. And because nothing forces a wildcard to be removed, it stays.

A wildcard is a question, not an answer. It is there to find out what you do not know. Once you know, every extra week it remains is a week of unintended scope.

There is a second consequence, and it is larger than it looks. A broad wildcard does not only affect who can reach what — it affects which traffic ZPA considers its own in the first place, before any policy is evaluated at all.

That is the subject of the next article, and it is the part that surprised me most when Zscaler support confirmed it.

Final thoughts

Application segments look like a configuration task and are actually a description exercise. What is this application, where does it live, who needs it, on which ports. Four questions, none of them technical in any interesting way, and all of them unanswered in most organizations because nothing ever forced the answer.

The three objects exist to keep those answers separate. The segment describes the application. The server group describes reachability. The segment group describes what policy is allowed to name. Confuse any two of them and the design will work in testing and fail in a way nobody can explain.

Default deny is not a product setting. It is the decision that a resource nobody declared does not exist, and that somebody is now accountable for declaring it.

That decision is uncomfortable for the teams who used to get reachability for free. It is also the only version of this that survives an audit, a departure, a reorganisation, or the fifteenth year of somebody’s career.

The next article covers what happens when a request arrives: how the DNS match works and why it is not an authorisation control, how access policy and client forwarding policy interact, the evaluation order end to end, and the difference between the user tunnel and the machine tunnel.

Sources and references

Segment matching and multimatch behaviour described here follows Zscaler’s published documentation on application segments, tested in real environments. Product behaviour changes; verify against current documentation before relying on any of it in a design.