Identity before connectivity: how ZPA differs from a VPN
A VPN puts the user on the network and then filters. Zscaler Private Access checks who is asking first, and only then joins two outbound connections for one application.
A traditional VPN works in two steps. The user connects to a gateway that listens on the internet, and is placed on the internal network. Firewalls then decide what that user can reach. The gateway is exposed to anyone who can find it, and a user who gets in has a network address that can be used to look around.
Zscaler Private Access reverses the order. Nothing is connected until policy has said yes, and what gets connected is one application, not a network.
The three parts
| Part | Where it runs | What it does |
|---|---|---|
| Client Connector | The user's device | Signs the user in, reports device posture, and opens an outbound tunnel |
| ZPA Service Edge | Zscaler's cloud | Checks identity and policy, then joins the two tunnels |
| App Connector | Next to the application | Opens an outbound tunnel to Zscaler and reaches the app locally |
Why "inside-out" matters
Both the user and the App Connector connect outwards to Zscaler. Neither accepts incoming connections. The data centre firewall needs no inbound rule, and the application has no address on the internet to scan or attack. An application nobody can find is hard to attack.
What policy looks at
- Who: the user and their groups, sent from the identity provider.
- What device: posture checks such as a company certificate or an endpoint protection score.
- Which application: an application segment, defined by names and ports.
If no rule allows the request, it is denied. The user never learns whether the application exists.
Least privilege lives in the segment
A segment as wide as *.corp.local on every port is a VPN with extra steps. It is useful for a short time, to discover which applications people actually use. After that it should be replaced by narrow segments, grouped so that one rule can cover each team's set of applications.
The same idea elsewhere
The principle is not unique to one product. Any service that checks identity at its edge before passing a request to the application follows it. The private study planner linked to this blog works that way: a visitor is asked to prove who they are before a single request reaches the app, and people who are not on the list never see it.