Having completed a detailed evaluation of Zscaler Private Access (ZPA) for my organization's infrastructure, I feel compelled to share a nuanced finding. The platform's performance is highly dependent on your application architecture. Our benchmark results were bifurcated: stellar for modern SaaS, but problematic for legacy and private data center systems.
Our primary evaluation criteria included connection latency, throughput stability, and administrative overhead. The setup and configuration for SaaS applications (Salesforce, Workday, GitHub) was seamless. Performance here was excellent, with negligible added latency.
However, our environment retained a significant portion of on-premises and custom-hosted applications. This is where we encountered friction:
* **Non-HTTP/S TCP applications** (e.g., legacy databases, proprietary tools) required App Connectors deployed in our data center. We observed inconsistent latency spikes (150-400ms added vs. direct) despite the Connector being local to the app.
* **Throughput for large data transfers** (scientific data sets, VM images) was throttled and highly variable compared to our existing VPN concentrators.
* The **"need-to-know" access model**, while secure, created significant administrative burden for these internal apps. Defining every segment and policy for hundreds of legacy systems became a full-time project.
The configuration for a simple TCP-based internal application highlights the added complexity versus a traditional VPN:
```yaml
# Simplified ZPA Segment & Policy construct for one internal app
Application Segment:
Name: legacy-app-db
Domain: internal-db.company.local
Port: 1433
Connector Group: on-prem-connectors
Access Policy:
User Group: research-team
Application Segment: legacy-app-db
Policy Action: ALLOW
```
For a predominantly SaaS-forward company, ZPA would score highly on our benchmarks. For our hybrid reality, the cost-benefit analysis shifted. The overhead of managing the App Connector infrastructure and granular policies for legacy systems eroded the operational efficiency gains made on the SaaS side.
Ultimately, we could not justify a full migration. The tool is powerful, but its architecture is optimized for a cloud-centric world.
Benchmarks > marketing.
BenchMark
This is really helpful, thanks. Your point about latency spikes for on-prem apps even with a local App Connector is concerning.
How did that compare to a traditional VPN for those same legacy systems? Was the latency just consistently higher across the board, or were the spikes the real issue?
I'm looking at similar tools and wondering if this performance profile is specific to ZPA's architecture or more common with other ZTNA solutions.
Good question. I saw similar latency spikes in a small pilot we ran with another ZTNA vendor, Palo Alto Prisma Access. The spikes weren't constant, but they were unpredictable, happening a few times a day. A traditional VPN was slower on average, but more consistent.
Do you think this is a fundamental issue with how ZTNA brokers traffic through a cloud service, compared to a direct VPN tunnel?
Your pilot experience with Prisma Access aligns with the architectural reality. The inconsistency is indeed a core characteristic of the cloud-brokered ZTNA model. A VPN creates a deterministic, long-lived tunnel path to a specific network ingress point, even if that path is slower.
ZTNAs like ZPA and Prisma Access dynamically broker individual application sessions through their nearest cloud node. You're trading a fixed, known path for an optimized, but variable one. The spikes occur during broker handoff, cloud infrastructure hiccups, or when the App Connector's health check temporarily reroutes. It's not a defect, it's a design trade-off for granular security and user-to-app topology.
That's why we see this pattern most with stateful, latency-sensitive on-prem protocols (think databases, legacy RPC). They were designed for a stable network segment, not a path that can invisibly shift.
Mike
Exactly. You've nailed the fundamental trade-off. Calling it a "design trade-off for granular security" is accurate, but I think it undersells the operational impact for certain workloads.
My team ran into this with a mainframe terminal emulation application. The session brokerage and path variability introduced just enough packet reordering to confuse the emulator's timing logic, causing periodic screen corruption. A VPN's consistent, if slower, path was actually more reliable. The ZTNA model assumes a modern, resilient application layer, which many legacy systems simply don't have.
So the issue isn't just latency spikes, it's protocol fragility. The cloud broker becomes a new, unpredictable link in a chain that was designed for a static, on-network client.
We ran into the exact same wall with a batch processing system that used raw TCP sockets. The App Connector, even sitting in the same rack as the servers, became a bizarre bottleneck. Packet capture showed the added latency wasn't from the network hop, but from the Connector's own processing queue. It's like it's optimized for a million short-lived HTTP requests, not a few persistent, high-throughput streams. You can tune some of it away, but then you're just recreating a VPN gateway with extra steps and a monthly per-user fee.
The "stellar for modern SaaS" bit is the real giveaway. It's a product designed for a world where everything you need is already in someone else's cloud. The moment you have something that's yours, on your hardware, you're trying to fit a square peg into a very profitable round hole. The performance profile you saw isn't a bug, it's the cost of using a global SaaS proxy to reach the server in the next room. The whole model assumes the hard stuff is outsourced.
prove it to me
Your point about the "profitable round hole" is astute, and it gets at the vendor's economic incentives. They architect for the statistically common case: outward-facing web traffic. The model breaks down not just for on-prem, but for any internal service with atypical flow patterns.
I'd push back slightly on the "hard stuff is outsourced" line, though. The real difficulty isn't the server location, it's the protocol semantics. We've seen this with internal gRPC services using bidirectional streaming; the App Connector's flow control and buffer management, tuned for request/response, became a bottleneck. The hard stuff they've outsourced is actually supporting stateful, long-lived connections efficiently.
So it's less about *where* the server is and more about *how* it communicates. A cloud-native microservice in your own VPC can suffer the same fate if it doesn't fit the HTTP/S mold.