You open your laptop at home, connect to the company network, and almost immediately a login prompt appears asking you to authenticate — again. Or a website you could access at the office is suddenly blocked. Or your IT team says "it goes through Zscaler" when you ask why something is slow. Zscaler is one of those pieces of infrastructure that affects every developer every day, but almost nobody understands how it actually works.
This post explains the architecture behind Zscaler — what it is, what its components do, how traffic flows through it, and why your organisation uses it instead of a traditional VPN.
The core idea: move security to the cloud
Traditional corporate network security worked like a castle and moat. All your important resources (applications, servers, data) lived inside the castle. The moat was a perimeter firewall. If you were inside the network, you were trusted. If you were outside, you weren't. A VPN was a drawbridge — it let remote workers get inside the moat.
This model breaks down badly in a world where applications are in SaaS clouds, developers work from home, and data doesn't live in a single data centre. The moat is no longer meaningful because there's no single perimeter to defend.
Zscaler's answer is to stop thinking about network perimeters entirely and instead make every connection a zero-trust decision: verify who you are, verify the device you're on, check policy, then grant access to that specific application — not the whole network. Security moves from a box in your data centre to a cloud service that sits on every connection, everywhere.
Zscaler calls this platform the Zero Trust Exchange (ZTE). It is essentially a global cloud of security inspection points that all your traffic passes through, regardless of where you are.
The two main products: ZIA and ZPA
Zscaler has two core services that serve different purposes. They share the same underlying cloud infrastructure but handle different types of traffic.
Zscaler Internet Access (ZIA)
ZIA is a cloud-native Secure Web Gateway. It sits between your device and the internet — handling all traffic to websites, SaaS apps (Google Workspace, Office 365, Salesforce), and anything external. It inspects that traffic inline, including TLS/SSL encrypted traffic, and enforces your organisation's policies: URL filtering, malware blocking, data loss prevention (DLP), cloud firewall, and sandboxing of suspicious files.
When Zscaler "blocks a website," that is ZIA enforcing a URL filtering policy. When Zscaler decrypts and inspects your HTTPS traffic, that is ZIA performing SSL inspection — it acts as a man-in-the-middle using a corporate certificate installed on your device.
Zscaler Private Access (ZPA)
ZPA replaces the traditional VPN for accessing internal applications. Instead of putting you on the corporate network, ZPA gives you access to specific applications only — nothing else. The underlying network is never exposed. You can't ping other servers, scan subnets, or reach anything you haven't been explicitly granted access to. This eliminates the lateral movement risk that makes VPN breaches so devastating.
When your organisation says "authenticate with Zscaler to access the internal tools," they almost certainly mean ZPA. The SSO prompt you see when connecting from home is ZPA verifying your identity before brokering a connection to the application.
A key architectural point: ZIA and ZPA are separate services. Traffic from ZPA does not pass through ZIA. ZIA handles internet-bound traffic; ZPA handles private application traffic. They are often deployed together on the same endpoint agent, but their traffic paths through the Zscaler cloud are distinct.
The Zero Trust Exchange: three planes
The Zscaler cloud platform is built around three functional layers, which Zscaler calls planes.
Control plane — Central Authority (CA)
The Central Authority is the brain of the Zscaler cloud. It manages all policies, user credentials, and configuration for your organisation's Zscaler tenant. When you log in to the Zscaler admin portal and create a URL filtering policy, you're configuring the Central Authority. It pushes policies to the data plane (Public Service Edges) in real time.
The CA does not handle your actual traffic. It only handles management and policy distribution. This separation means a management plane outage doesn't interrupt traffic inspection — the data plane continues enforcing cached policies independently.
Data plane — Public Service Edge (PSE)
The Public Service Edge (previously called the Zscaler Enforcement Node, or ZEN) is where your traffic actually gets inspected and policies enforced. PSEs are deployed in Zscaler-owned data centres across 150+ points of presence worldwide. Your Client Connector automatically connects you to the nearest PSE.
PSEs are stateless by design. They hold no data on disk. Packet data is held in memory for inspection and then forwarded or dropped. This is what allows Zscaler to scale horizontally without the session affinity problems that plagued traditional proxy appliances.
Zscaler's Single Scan, Multi-Action (SSMA) technology runs all inspection engines — antivirus, DLP, sandboxing, URL filtering — in a single pass through the traffic rather than chaining separate inspection engines sequentially. This is how it achieves inline inspection without introducing significant latency.
Statistics plane — Nanolog
Nanolog is Zscaler's log aggregation system. Every transaction through a PSE generates a log record. Nanolog compresses and tokenises these records in real time and ships them to regional log storage according to your organisation's data residency configuration. This is what powers the Zscaler admin dashboard — real-time visibility into every connection made by every user in your organisation.
The Zscaler Client Connector (ZCC)
The Zscaler Client Connector (ZCC) is the lightweight agent installed on your device — laptop, phone, or tablet. This is the thing that pops up asking you to authenticate when you connect from home. It runs on Windows, macOS, Linux, iOS, and Android.
ZCC has three jobs running simultaneously:
- Route internet traffic through ZIA — all traffic destined for external sites and SaaS apps is tunnelled to the nearest PSE for inspection.
- Broker private app access through ZPA — when you try to reach an internal application, ZCC initiates the ZPA authentication and tunnel establishment flow.
- Report device posture — ZCC continuously checks the health of your device (OS version, disk encryption, antivirus status, screen lock) and reports it to the Zero Trust Exchange. This posture data influences what you're allowed to access. A device that fails posture checks can be denied access or given reduced permissions even with valid credentials.
ZCC is what makes Zscaler transparent to the user. You don't manually connect to a VPN — ZCC intercepts traffic automatically. When it's working well you don't notice it. When it isn't, everything is slow or blocked.
ZIA traffic flow: internet access
Here's what happens when you open a browser and navigate to a website while ZCC is running:
- You navigate to a URL. ZCC intercepts the request and tunnels it over TLS to the nearest PSE.
- The PSE decrypts the traffic (SSL inspection), runs it through the inline engines — URL filter, malware scanner, DLP, cloud firewall — in a single pass.
- The PSE consults the policy (pushed from the Central Authority) to determine if the destination is allowed for your user, group, and device posture.
- If allowed, traffic is forwarded to the destination. If blocked, a block page is returned to your browser.
- Every transaction is logged to Nanolog.
For unencrypted HTTP traffic this is straightforward. For HTTPS, Zscaler performs a TLS man-in-the-middle: it terminates your TLS connection at the PSE, inspects the plaintext, then opens a new TLS connection to the destination. This is why your organisation must install a Zscaler root certificate on your device — without it, your browser would reject the PSE's re-signed certificate as untrusted.
ZPA traffic flow: private application access
ZPA's architecture is fundamentally different from ZIA. Rather than inspecting traffic, it brokers connections. The goal is to connect your device to a specific application without putting you on the network that hosts the application.
ZPA has two components that work in tandem on either side of the connection:
Zscaler Client Connector (your side)
Already installed on your device. When you try to reach a private application, ZCC initiates the ZPA authentication flow and establishes an outbound TLS tunnel to the nearest ZPA Service Edge.
App Connector (application side)
The App Connector is a lightweight VM or container deployed on the same network segment as the private application — inside your AWS VPC, your on-prem data centre, or wherever the app lives. It makes only outbound connections to the ZPA Service Edge. No inbound ports are opened. The application is completely invisible to the internet because it has no publicly reachable address.
Here is the full ZPA connection flow:
- You try to access an internal application. ZCC intercepts the request and initiates a SAML authentication redirect to your organisation's identity provider (Okta, Azure AD, etc.).
- You authenticate with your IdP (this is the SSO prompt you see). The IdP issues a signed SAML assertion containing your identity and group attributes.
- ZCC presents the assertion to the ZPA Service Edge. The Service Edge verifies the signature, checks your device posture, and evaluates access policy: is this user, on this device, allowed to reach this application?
- If allowed, the Service Edge signals the App Connector near the target application to establish a data-plane tunnel. It then stitches the tunnel from ZCC to the Service Edge together with the tunnel from the App Connector to the Service Edge — creating an end-to-end micro-tunnel between your device and the application.
- Traffic flows through this micro-tunnel. The application sees the connection coming from the App Connector — your actual IP address is never exposed to the application's network. You are never placed on the network.
This is why ZPA is fundamentally safer than a VPN. A VPN grants you a network address and the ability to route to anything on that network. ZPA grants you a connection to one application, for one session, with no network-level access whatsoever. If your credentials are stolen, the attacker can reach only the applications you were authorised to access — nothing else.
SSO and identity: how authentication works
Identity is the foundation of everything in Zscaler. Every access decision — which websites you can visit, which internal apps you can reach, which security policies apply to you — is based on who you are and what groups you belong to.
Zscaler integrates with your organisation's identity provider via SAML 2.0. Zscaler acts as the Service Provider (SP); your IdP (Okta, Azure AD, Google Workspace, PingOne, etc.) acts as the Identity Provider. The flow is always SP-initiated: Zscaler redirects you to your IdP to authenticate, your IdP issues a signed assertion, Zscaler validates it.
SCIM (System for Cross-domain Identity Management) handles the lifecycle side: when a new employee joins and is added to your IdP, SCIM automatically provisions them in Zscaler. When they leave and are deprovisioned in the IdP, Zscaler access is removed simultaneously. No manual account management in the Zscaler admin portal.
SAML assertions can carry attributes beyond just identity — department, role, location, device type. Zscaler uses these attributes to apply fine-grained policies. A developer in the engineering group might have access to internal staging environments; a contractor with the same Zscaler client has access only to approved external tools.
Device posture: trust the device, not just the user
Zero trust means verifying more than just identity. Zscaler continuously assesses the posture of your device and uses that assessment as part of every access decision.
Posture checks include: OS version and patch level, disk encryption status, screen lock policy, antivirus software presence and version, firewall status, and integration with endpoint protection platforms like CrowdStrike, SentinelOne, or Defender. Some organisations use a CrowdStrike ZTA (Zero Trust Assessment) score — a numeric score reflecting the device's overall security posture — as an input to Zscaler policy.
A user with valid credentials on an unmanaged personal device may be denied access to sensitive applications even with a valid SAML assertion. Or they may be allowed limited access — read-only, or access to lower-risk applications only. The combination of who you are and what device you're on determines what you get.
Zscaler Digital Experience (ZDX)
ZDX is Zscaler's observability layer. It monitors end-to-end performance from the user's device to the application, including endpoint health, network path quality, and application responsiveness. When a developer reports that "Zscaler is making everything slow," ZDX is what IT uses to diagnose whether the problem is the device, the local network, the Zscaler PoP, or the application itself.
ZDX works by running synthetic probes from the ZCC agent on every enrolled device. This gives IT teams real visibility into the user experience rather than having to guess from server-side metrics.
The full architecture
Here's how all the pieces fit together in a typical enterprise Zscaler deployment:
Why you need to authenticate when working from home
This is the question that prompted this post. When you're in the office, your device is on a network that your IT team has pre-configured as trusted. Zscaler may authenticate you silently using your Active Directory session or a network-based trusted path. You don't notice it.
When you work from home, your device is on an untrusted network — your home broadband. Zscaler can no longer rely on network location as a trust signal. It must explicitly verify who you are before granting access to private applications. This is where the ZPA SAML authentication flow kicks in — your IdP (often Okta or Azure AD with MFA) is asked to vouch for you. Once it does, Zscaler re-establishes access for that session.
This is not a bug or poor UX — it is zero trust working exactly as designed. The alternative (trusting all home networks) would mean anyone on your home Wi-Fi, or anyone who compromises your home router, gets the same access as you.
Summary
Zscaler sits on every connection your device makes and applies security decisions based on identity, device posture, and policy — regardless of where you are. It does this through two services: ZIA for internet and SaaS traffic (a cloud proxy that inspects and filters), and ZPA for private application access (a zero-trust broker that replaces VPN). Both are served from a global cloud of Public Service Edges, managed by the Central Authority, with logs flowing through Nanolog and performance monitored via ZDX.
The authentication prompt you see when working from home is Zscaler asking your identity provider to confirm who you are before granting access to your organisation's internal applications. It's the moment zero trust becomes visible to the user — and the reason you should have MFA configured on your IdP account.