The Zscaler (ZTE) is easiest to understand by what it is not: it is not a perimeter moved to the cloud. It is a globally distributed switchboard - a proxy architecture in which every connection terminates at a Zscaler enforcement point, gets identified and inspected, and is then completed onward as a fresh connection. Sources connect to the Exchange; the Exchange connects to destinations. Nothing traverses; everything is brokered. Hold onto that sentence and the rest of the platform stops being a product list and starts being consequences.

The enforcement point: the Public Service Edge

The worker in the architecture is the - Zscaler's current name for the enforcement nodes deployed in its data centers worldwide (older material says ZEN, Zscaler Enforcement Node; the rename matters when reading documentation). A Service Edge terminates the user's or location's session, applies identity, applies policy, and originates the onward connection. Zscaler's documentation is specific about the operational posture: packet data is held in memory for inspection and either forwarded or dropped by policy - Service Edges never store payload data to disk - while transaction logs are compressed, tokenized, and streamed out over TLS to the logging infrastructure. The same "Service Edge" concept also exists in private form: single-tenant instances an organization hosts in its own site or cloud while Zscaler manages them - the same enforcement, brought closer.

Proxy, not router - and what that buys

Because every session is terminated rather than routed through, the Exchange sees complete application transactions instead of packets in flight. That is what makes TLS interception a first-class feature rather than a bolt-on: the Service Edge stands as a by design, decrypting where policy says so, inspecting the plaintext once, and applying every enabled engine to that single decrypted stream - URL filtering, malware analysis, data protection - before re-encrypting onward. One termination, one inspection, many verdicts. It is also what makes the platform's scale model horizontal: sessions are stateless per node, so capacity is added by adding edges, and users are simply steered to the nearest healthy one.

The proxy stance has a second consequence that shapes designs: the Exchange is reached by forwarding, not by routing tables. Traffic must be sent to it deliberately - by an agent on the device, by a tunnel from a location, by a proxy setting - which is exactly why the forwarding-methods decision is the first real design conversation in any deployment.

Three services, one switchboard

The product names are seats at the same exchange. Zscaler Internet Access () is the outbound seat: users and locations connect to the Exchange, and the Exchange connects to the internet and SaaS on their behalf, applying the secure web gateway, firewall, and data-protection engines in the path. Zscaler Private Access () is the inbound-without-inbound seat: private applications are never exposed; instead App Connectors alongside the applications dial out to the Exchange, users dial in, and the Exchange stitches the two outbound connections together per application, per session. Zscaler Digital Experience () is the measurement seat: with the data path brokered through the Exchange, the same vantage points measure the experience - device, network, and application health - end to end.

The claim lives in ZPA's connection model more than anywhere else: a user is connected to an application they are authorized for, never placed on a network. There is no flat inside to move laterally across, because there is no inside - only brokered, per-session threads. A VPN (virtual private network) extends the network to the user; the Exchange inverts that, extending nothing and brokering everything.

Reading the architecture like an operator

Three habits follow. First, identity is the routing table: policy hangs off who and what connected, so the identity integration is infrastructure, not an accessory. Second, the Service Edge is the vantage point: when troubleshooting, think in two legs - source to Edge, Edge to destination - because that is literally how the connection exists. Third, encryption boundaries are policy decisions: what the Exchange may decrypt it can inspect; what it must not decrypt it can only pass judgment on from the outside. Every later article in this series is one of these consequences examined closely.

This series, in order

This article opens the series The Zscaler Zero Trust Exchange. It places ZIA, ZPA and ZDX on one switchboard; the parts follow the platform from the outside in and back out: how traffic gets there, how the endpoint decides and how to troubleshoot it, what the device's state contributes, the SaaS view, the experience score, the logs and who changed what, the reports leadership reads, and three scenarios that bring it together: an exfiltration alert, a platform that changes itself, and a merger.

  1. Zscaler Tunnel Types: Z-Tunnel, GRE, and IPsec, With the Numbers. for devices, and for sites: three tunnels that are not interchangeable, with the numbers.
  2. Client Connector Profiles: Where the Endpoint Decides How to Forward. Two documents deep: the decides how traffic leaves the device in each network state.
  3. Troubleshooting Client Connector: The Diagnostics Menu and the First Four Checks. The connection states, the exported logs and the first four checks when a user cannot get online.
  4. Posture and Device Trust: Letting the Device's State Vote. Identity says who is asking; posture says from what: device conditions voting in access decisions.
  5. CASB in the Exchange: Inline, Out-of-Band, and the Posture of SaaS Itself. The cloud access security broker as two vantage points: inline over data in motion, out of band over data at rest.
  6. The ZDX Score: What the Probes Measure and How the Number Is Made. How a score from 1 to 100 is made: what the web probes and the path probes measure.
  7. Nanolog, NSS, Cloud NSS, and LSS: Getting the Logs Out. The cloud-side log store and the three delivery paths that bring the logs home.
  8. The Administrator Audit Log: Who Changed What, From Where, With What Outcome. Every administrative action, from the console or the API, as a record of who changed what, from where, with what outcome.
  9. Reports and Executive Summaries: Turning the Nanolog Into Sentences Leadership Reads. The reporting layer between the raw log stream and the board slide.
  10. The Exfiltration Alert: A Walkthrough From Signal to Posture Answer. A suspected exfiltration alert walked from the signal to the posture answer: the series converging on one scenario.
  11. Updates and Change Management: Running Change on a Platform That Also Changes Itself. Three change streams (the 's cloud, your agent fleet, your policy) and only two of them yours to schedule.
  12. Mergers and Acquisitions on the Exchange: Day-One Access Without Merging Networks. Day-one access for an acquired company's people without merging the networks.