7.1 ZPA Zero Trust Network Access Architecture
Key Takeaways
- Zscaler Private Access (ZPA) replaces legacy network-centric VPNs with application-centric Zero Trust Network Access (ZTNA), granting authorized users access strictly to designated internal applications rather than the underlying corporate network.
- Inside-out TLS micro-tunnels originate outbound on TCP port 443 from both Zscaler Client Connector and App Connectors to the ZPA Service Edge, eliminating inbound listening firewall ports and rendering internal infrastructure completely dark to the public internet.
- The ZPA Central Authority (CA) serves exclusively as the control plane broker—authenticating users, verifying device posture, evaluating SCIM access policies, and issuing ephemeral session certificates without ever handling user payload or application data.
- Public and Private Service Edges function as the distributed data plane, stitching ephemeral, end-to-end encrypted user-to-connector sessions dynamically in memory using public-key cryptography and double-blind brokering.
- ZPA eliminates network routing table expansion, IP subnet overlap conflicts, and lateral attack movement by avoiding Layer 3 network bridging entirely.
7.1 ZPA Zero Trust Network Access Architecture
Core Principle: Traditional remote access relies on perimeter-based Virtual Private Networks (VPNs) that extend Layer 3 network connectivity to remote endpoints. Once authenticated, a VPN client is placed directly on the internal network, granting broad IP reachability and exposing enterprise infrastructure to lateral threat movement, reconnaissance, and unauthorized exploitation. Zscaler Private Access (ZPA) fundamentally inverts this model through Zero Trust Network Access (ZTNA): it connects authenticated users directly to specific, authorized private applications without ever placing the user on the enterprise network or exposing internal servers to the public internet.
1. Traditional VPNs vs. ZPA Zero Trust Network Access
To understand the ZPA architecture, network security engineers must analyze how legacy remote access architectures fail modern enterprise security and cloud agility requirements.
+-----------------------------------------------------------------------------------+
| TRADITIONAL VPN (NETWORK EXTENSION) VS. ZPA (ZERO TRUST) |
+-----------------------------------------------------------------------------------+
TRADITIONAL VPN MODEL (Layer 3 Network Bridging):
[ Remote User ] ──( Inbound IPsec / SSL VPN Tunnel )──>
│
▼
[ Concentrator / Ingress FW ]
( Open Ports: UDP 500/4500, TCP 443 )
│
▼
[ Full Enterprise Network (10.0.0.0/8) ]
* Broad IP reachability
* Lateral attack movement
* Subnet collision in M&A / Multi-Cloud
ZPA ZERO TRUST MODEL (Application-Centric Micro-Segmentation):
[ Remote User ] ──( Outbound TLS 443 )──>
│
▼
[ ZPA Service Edge ] <──( Outbound TLS 443 )── [ App Connector ]
( Ephemeral Stitch ) │
▲ ▼
│ [ Target App Only ]
[ ZPA Central Authority ] (jira.corp.internal:443)
( Control Plane Broker ) * Zero inbound ports
* Dark infrastructure
* No network bridging
Detailed Comparison Matrix
| Architectural Dimension | Traditional Hardware VPN | Zscaler Private Access (ZPA) |
|---|---|---|
| Access Granularity | Network-level access (User placed directly on subnet) | Application-level access (User connected only to specific app/port) |
| Inbound Firewall Ports | Requires open public listening ports (UDP 500/4500, TCP 443) | Zero open inbound ports (0 inbound); all tunnels are outbound-only |
| Infrastructure Visibility | Publicly discoverable via port scanning (Shodan, Nmap) | Dark infrastructure: Internal apps and servers are invisible to internet |
| Network Routing & Subnets | Requires complex routing, IPsec mesh, and NAT for overlapping subnets | No routing tables or bridging: Uses Synthetic IPs and double-blind brokering |
| Lateral Movement | High risk; compromised endpoint can scan and attack adjacent hosts | Completely prevented: User has zero network visibility beyond authorized app |
| Control vs. Data Plane | Monolithic appliance handles both control and data processing | Decoupled: Central Authority (Control) is separated from Service Edge (Data) |
2. Core Architecture Components & Plane Separation
ZPA separates the administrative and policy Control Plane from the high-throughput, latency-optimized Data Plane. This separation ensures scalability, prevents data leakage, and guarantees that user payload data is never exposed to the control infrastructure.
+-----------------------------------------------------------------------------------+
| ZPA COMPONENT ARCHITECTURE |
+-----------------------------------------------------------------------------------+
+--------------------------------------------------+
| ZPA CENTRAL AUTHORITY (CA) |
| * Policy Orchestration * SAML/SCIM Identity |
| * Ephemeral PKI Issuance * Health Orchestration |
+------------------------+-------------------------+
│ (Control Channels: TLS 1.2/1.3)
┌───────────────────┴───────────────────┐
▼ ▼
+-----------------------------------+ +-----------------------------------+
| ZPA PUBLIC SERVICE EDGE | | ZPA PRIVATE SERVICE EDGE |
| (Zscaler Global Cloud Data Center)| | (Customer On-Premises / Private) |
| * In-Memory Session Stitching | | * Local Low-Latency Processing |
| * End-to-End Encrypted Broker | | * In-Country / Sovereign Comply |
+-----------------+-----------------+ +-----------------+-----------------+
▲ ▲
(Z-Tunnel 2.0) │ (Outbound TLS 443) (Outbound 443) │ (Z-Tunnel 2.0)
│ │
+-----------------+-----------------+ +-----------------+-----------------+
| ZSCALER CLIENT CONNECTOR | | ZPA APP CONNECTOR |
| (Endpoint Agent on User Device) | | (Lightweight Linux Appliance in |
| * Synthetic IP DNS Interception | | Customer VPC / On-Prem DC) |
| * Device Posture Evaluation | | * Outbound Micro-Tunnel to Edge |
+-----------------------------------+ | * Local DNS & TCP/UDP Proxy |
+-----------------+-----------------+
│ (Internal TCP/UDP)
▼
[ Enterprise App Servers ]
1. ZPA Central Authority (CA)
- Role: The brain of the control plane. It coordinates policy distribution, validates identity assertions (SAML 2.0 / SCIM), assesses device posture signals forwarded by Zscaler Client Connector, and orchestrates connection handshakes between Client Connectors, Service Edges, and App Connectors.
- Security Isolation: The Central Authority never sits in the data path, never sees application payloads, and does not terminate user data traffic.
- Cryptographic Authority: Acts as an internal Public Key Infrastructure (PKI) root/intermediate authority that generates and distributes short-lived, ephemeral session certificates used to mutually authenticate and encrypt communication between clients, Service Edges, and App Connectors.
2. ZPA Service Edge (Public & Private)
- Role: The distributed data plane workhorse. Service Edges are deployed globally across Zscaler data centers (Public Service Edge) or within customer on-premises data centers and private cloud VPCs (Private Service Edge).
- Session Stitching: Receives outbound TLS micro-tunnels from both the user's Client Connector and the internal App Connector, authenticates both endpoints using ephemeral certificates issued by the CA, and dynamically stitches the two tunnels together in memory.
- Double-Blind Brokering: The Service Edge forwards encrypted application payload between the two micro-tunnels without decrypting the payload (unless configured for inspection) and without bridging the underlying IP networks.
3. ZPA App Connector
- Role: A lightweight software appliance deployed in customer private subnets (VMware, AWS, Azure, GCP, KVM) close to enterprise applications.
- Inside-Out Micro-Tunnels: Establishes persistent outbound TLS control connections to the Central Authority and dynamic outbound TLS data micro-tunnels to Service Edges on TCP port 443.
- Local Proxying: Resolves internal DNS hostnames for requested applications and establishes local TCP/UDP connections to backend enterprise servers on behalf of authenticated remote users.
4. Zscaler Client Connector (ZCC)
- Role: Lightweight endpoint software running on user devices (Windows, macOS, Linux, iOS, Android).
- Traffic Interception: Intercepts DNS queries for internal enterprise domains, returns a local Synthetic IP, encapsulates application traffic in Z-Tunnel 2.0 (DTLS or TLS), and forwards it to the optimal ZPA Service Edge.
3. Dark Infrastructure & Inside-Out Micro-Tunnels
A foundational security tenet of ZPA is the concept of Dark Infrastructure.
+-----------------------------------------------------------------------------------+
| DARK INFRASTRUCTURE & ZERO LISTENING PORTS |
+-----------------------------------------------------------------------------------+
PUBLIC INTERNET (Adversary View):
┌───────────────────────┐
│ Threat Actor / Shodan │ ──( Inbound Port Scan: TCP 80, 443, 3389, 500/4500 )──>
└───────────────────────┘ │
▼
[ Enterprise Edge Firewall ]
( All Inbound Ports: CLOSED )
[ RESULT: 100% DROP / SILENT ]
INTERNAL OUTBOUND TUNNELING (ZPA Architecture):
[ App Connector ] ──( 1. Outbound TLS 443 Connection )──>
(Private Subnet) │
▼
[ ZPA Public Service Edge ]
( Global Zero Trust Exchange )
▲
[ Client Device ] ──( 2. Outbound TLS 443 Connection )──┘
Operational Advantages of Dark Infrastructure:
- Zero Open Inbound Ports: Traditional firewalls require opening ports (e.g., TCP 443 or UDP 500) to accept incoming VPN connections, exposing VPN concentrators to remote code execution (RCE) zero-day vulnerabilities. ZPA requires zero open inbound ports on edge firewalls. App Connectors only initiate outbound connections to the ZPA cloud.
- Invisibility to Internet Scanners: Because internal enterprise applications have no public IP addresses and no inbound listener endpoints, automated reconnaissance tools (such as Shodan, Censys, and Nmap) cannot detect their existence.
- DDoS Immunity: Volumetric Distributed Denial of Service (DDoS) attacks targeting corporate data center firewalls are rendered ineffective because there are no public ingress endpoints to target.
4. Ephemeral Session Stitching & Double-Blind Brokering
When an authorized user requests access to an internal application, ZPA establishes the connection using a deterministic, multi-step Session Stitching sequence.
+-----------------------------------------------------------------------------------+
| STEP-BY-STEP ZPA SESSION STITCHING WORKFLOW |
+-----------------------------------------------------------------------------------+
Client Device ZPA Central Authority ZPA Service Edge App Connector App Server
(ZCC Agent) (CA) (PSE) (Customer DC) (Internal)
│ │ │ │ │
[ 1. User requests: │ │ │ │
jira.corp.internal ] │ │ │ │
│ │ │ │ │
├──( 2. DNS Intercept: Returns Synthetic IP 100.64.0.15 ) │ │
│ │ │ │ │
├──( 3. Control Request: Authorize Access? )───────>│ │ │
│ (SAML Identity + Posture Token) │ │ │
│ │ │ │ │
│ ├──[ 4. Policy Engine Evaluates SCIM, │ │
│ │ Posture & Trust Criteria ] │ │
│ │ │ │ │
│ ├──( 5. Dispatch Session Token & Dispatch )───>│ │
│ │ (Selects Optimal Service Edge & Connector) │ │
│ │ │ │ │
│<─( 6. Issue Client Token & Edge Referral )────────┤ │ │
│ │ │ │ │
├──( 7. Outbound TLS Data Micro-Tunnel )───────────>│ │ │
│ │ │<──( 8. Outbound TLS Micro-Tunnel )──┤
│ │ │ │ │
│ │ [ 9. SERVICE EDGE │ │
│ │ STITCHES TUNNELS │ │
│ │ IN-MEMORY DUAL-ENCRYPTED ] │ │
│ │ │ │ │
│ │ │ ├──( 10. TCP 443 Proxy )─>
│ │ │ │ (App Connector IP) │
│ │ │ │<──( 11. App Response )─┤
│<═════════════════════════╪════════════════════════╪═════════════════════╡<═══════════════════════╡
│ End-to-End Encrypted User-to-Application Data Session (Stitched) │ │
The Double-Blind Broker Mechanism
ZPA enforces complete privacy between the user endpoint, the Zscaler cloud, and the backend server:
- The Server is Blind to the Client: The backend enterprise server never sees the user's real public IP, private home IP, or endpoint hostname. The server only sees the local private IP address of the App Connector initiating the local TCP/UDP connection.
- The Client is Blind to the Server: The user's device never learns the real internal IP address of the destination server; it communicates exclusively with a local Synthetic IP assigned by Client Connector.
- The Service Edge is Blind to the Payload: When end-to-end encryption is used, the Service Edge stitches micro-tunnels at Layer 4 and does not decrypt or inspect application payloads.
5. Public Service Edge vs. Private Service Edge
ZPA offers two deployment models for its data plane: Public Service Edge (Public SE) and Private Service Edge (Private SE).
+-----------------------------------------------------------------------------------+
| PUBLIC VS. PRIVATE SERVICE EDGE TOPOLOGY |
+-----------------------------------------------------------------------------------+
REMOTE WORKER PATH (Public Service Edge): ON-PREMISES / HQ PATH (Private Service Edge):
[ Remote Laptop ] [ On-Prem User ]
│ │
▼ (Outbound TLS over Internet) ▼ (Outbound TLS over LAN)
[ ZPA Public Service Edge ] [ ZPA Private Service Edge ]
(Zscaler Global PoP) (Customer Datacenter Virtual Appliance)
▲ ▲
│ (Outbound TLS over Internet) │ (Outbound TLS over LAN)
[ App Connector (AWS/Azure) ] [ App Connector (Local DC) ]
│ │
▼ ▼
[ Cloud Workload ] [ Local Workload (Sub-millisecond) ]
Comparison & Use Cases
| Feature / Attribute | ZPA Public Service Edge | ZPA Private Service Edge (PSE) |
|---|---|---|
| Hosting Location | Managed multi-tenant Zscaler global cloud data centers (150+ PoPs) | Customer-hosted virtual appliance (VMware ESXi, KVM, AWS, Azure) |
| Primary Use Case | Remote workers, mobile users, branch offices accessing multi-cloud apps | On-premises users accessing local datacenter apps without internet hairpinning |
| Traffic Path | Hairpins out to nearest Zscaler Public PoP and back | Local LAN / WAN switching directly within customer perimeter |
| Latency Profile | Optimized internet routing via Zscaler global backbone | Ultra-low local network latency (< 1-2 ms) |
| Compliance Scope | Global data centers adhering to SOC2, ISO27001, FedRAMP | Strict data residency; payload never traverses the public internet |
| High Availability | Cloud-native multi-zone redundancy managed by Zscaler | Clustered in customer environment; automatic failover to Public SE if offline |
[!NOTE] Automatic Fallback: If an on-premises user cannot reach a local Private Service Edge (due to local server maintenance or network disruption), Zscaler Client Connector automatically falls back to connecting via the nearest Zscaler Public Service Edge, ensuring zero user disruption.
6. Practical Configuration & Diagnostic Workflow
Step-by-Step Diagnostic Verification:
- Verify Control Plane Registration: In the ZPA Admin Portal, navigate to Configuration > App Connectors and confirm that all connectors exhibit an Active/Healthy control tunnel status to the Central Authority.
- Inspect User Session Stitching: Navigate to Diagnostics > User Activity to view real-time connection logs. Verify the following transaction attributes:
- Connection Type: Client Connector
- Policy Action: Allow
- Service Edge: Selected PoP (e.g.,
sjc1-pseorash1-pse) - App Connector: Designated connector processing the backend proxy connection
- Internal Server IP / Port: Real server IP resolved by App Connector
- Client Private IP: Synthetic IP (
100.64.x.x) used on the local endpoint
7. Exam Tips & High-Frequency Traps
[!IMPORTANT] Exam Key Point (Inbound Ports = Zero): On the ZDTA exam, any answer choice suggesting that firewalls in front of App Connectors or internal applications require open inbound listening ports (such as TCP 443 or UDP 500) is incorrect. ZPA operates exclusively on outbound connections initiated from the inside out.
[!WARNING] Exam Trap (Central Authority vs. Data Plane): A classic exam question asks which component inspects or routes user data packets. Remember: the Central Authority NEVER processes user data payloads. Data plane forwarding and session stitching are performed strictly by Service Edges.
[!TIP] Operational Best Practice (Source IP Visibility): Internal application servers logging incoming connections will observe the source IP address of the App Connector, not the client's public or private IP. If applications require client identity tracking, administrators must rely on SAML/SCIM identity headers or X-Forwarded-For headers inserted by reverse proxies.
How does Zscaler Private Access (ZPA) achieve 'dark infrastructure' for enterprise applications hosted within a private corporate datacenter?
What is the specific architectural role of the ZPA Central Authority (CA) during a user session request?
In which enterprise deployment scenario is deploying a ZPA Private Service Edge (PSE) specifically recommended over relying exclusively on ZPA Public Service Edges?
When a remote user connects to an internal web server through ZPA, what source IP address is recorded in the server's incoming connection logs?