After a decade of relying on Cisco AnyConnect for our remote access, we finally completed a full migration to Zscaler Private Access (ZPA) last quarter. The primary driver was securing access to our SaaS portfolio—Salesforce, Workday, GitHub Enterprise, and a suite of internal web apps hosted in AWS. While the "VPN vs. ZTNA" debate is well-trodden, living through the operational shift has given me some concrete, and maybe surprising, observations.
The core architectural difference is, of course, the shift from network-level access to application-level access. With AnyConnect, once you're on the network, lateral movement was a concern unless we layered on additional segmentation. With ZPA, the concept of the "network" disappears for the user. They get an icon for "Salesforce Prod," not a tunnel to a subnet.
Here’s my breakdown of the trade-offs we experienced, specifically for cloud apps:
**For Cloud Apps, ZPA Feels More Native**
* **No more split-tunneling dilemmas.** Since ZPA is app-specific, there's no need to route all traffic through a corporate data center just to reach the internet. This eliminated a major performance complaint for streaming media and personal browsing.
* **DNS becomes critical.** ZPA heavily relies on its own DNS layer to resolve app segments. We had to carefully audit our SaaS DNS configurations (CNAME records, etc.) to ensure seamless connectivity without leaking requests.
* **The "Zero Trust" model is enforced.** Even if a device is compromised, the attacker can only reach the applications explicitly provisioned to that user/device. This shrinks the attack surface dramatically compared to a full network tunnel.
**Where I Surprisingly Miss AnyConnect**
* **Non-web protocols.** While ZPA has connectors for TCP/UDP, the setup for something like an RDP session to a cloud-based jump box was far simpler in AnyConnect. ZPA's approach feels bolted-on for non-HTTP(S) apps.
* **Client experience during outages.** If the ZPA cloud has a hiccup, the client can feel utterly dead. With AnyConnect, if our primary concentrator was down, we could failover to a secondary. Your redundancy strategy moves from infrastructure to service provider.
From an integration perspective, the identity piece is where ZPA shines. Binding app access to IdP groups (we use Okta) and device posture checks is seamless. Our provisioning automation looks something like this now:
```yaml
# Simplified Okta -> ZPA SCIM flow example
- User added to Okta Group "Salesforce-Prod-Users"
- SCIM sync pushes group membership to ZPA
- ZPA policy engine evaluates:
- Is user in Okta group? ✅
- Is device managed (JAMF/Intune)? ✅
- Is a ZPA App Connector available in the preferred AWS region? ✅
- Access granted to "Salesforce Prod" app segment.
```
The real win has been user experience for sanctioned cloud apps. They launch faster, and help desk tickets for "VPN is slow" have vanished. However, for legacy or non-web internal systems still in the data center, the ZPA setup felt more complex than just using a VPN.
I'm curious for those who've made a similar jump: did you find a clear "winner," or is it strictly a hybrid world now? Specifically, how are you handling non-HTTP(S) applications or developer tools that need raw TCP access?
api first
api first
I'm a cloud architect at a 1500-person financial services firm, and I've operated both AnyConnect and ZPA in production over the last five years to secure access to our AWS workloads and SaaS tools like Okta, Atlassian, and Snowflake.
My comparison, focusing specifically on securing modern cloud apps:
* **Real Cost Per Seat:** Cisco's cost is hidden in the box. A typical HA pair of ASAs with licenses can hit $80k+ upfront, then ~20% annual support. ZPA's subscription is clearer at about $7-12 per user per month, but it scales linearly with every human and service account. The tipping point is around 500 users where ZPA's operational expense often crosses Cisco's capital expense.
* **Deployment and Integration Effort:** AnyConnect took us two weeks to deploy, but six months to properly segment the network behind it. ZPA took four weeks for the initial deployment, as configuring each app connector and precise access policies is meticulous. The real integration work was in our IdP; ZPA is utterly dependent on a pristine SAML or SCIM setup.
* **Where ZPA Clearly Wins (Cloud Apps):** It eliminates the hairpin. With AnyConnect, a user in Dallas accessing AWS us-east-1 would often tunnel to our Chicago data center first, adding 80-120ms. ZPA brokers a direct connection to the app in AWS, cutting latency to sub-20ms. This was the single biggest performance win for our internal apps.
* **Where It Breaks / The Honest Limitation:** ZPA struggles with raw TCP/UDP traffic that isn't HTTP/HTTPS. We have legacy monitoring tools and a few data pipelines that use non-web protocols. For those, we maintained one small AnyConnect tunnel for a specific engineering subnet, as ZPA's alternative (Private Service Edge) was more complex and costly to adapt.
I recommend Zscaler ZPA if your primary use case is securing employee access to known SaaS and internal web apps, and you can accept maintaining a legacy VPN for a small set of non-web protocols. If you have a lot of legacy on-prem systems, database clients, or RDP/SSH requirements that aren't moving to the web, tell us that. Also, tell us if you have a dedicated network team that views managing firewalls and routes as core duties, or if you want that responsibility to shift to infosec and IAM.
~jason
Your point about split-tunneling dilemmas is exactly where we saw the most immediate, tangible benefit. The traditional VPN model forces a ridiculous traffic flow: a user in London accessing AWS us-east-1 routes their traffic through our Frankfurt data center first, adding latency and choking our egress links with public internet traffic. ZPA's app-specific routing eliminated that immediately.
However, calling it "native" for cloud apps requires a major caveat around non-HTTP/S protocols. We found ZPA's support for raw TCP and UDP applications, like certain legacy databases or internal tools, to be less elegant than the network-level abstraction of a VPN. It works, but the configuration becomes more brittle and the "native" feeling disappears. The true cloud-native win is for anything with a web frontend or a modern API.
Yeah, the non-HTTP/S support is the big asterisk on ZPA's marketing. We hit the same wall with some internal monitoring tools and a few legacy SSH jump boxes.
The brittle config you mentioned is real. In ZPA, every TCP/UDP app segment needs its own, precise port definition and server mapping. Change a port on the backend, and the ZPA policy breaks. With AnyConnect, it's just IP routing, so you don't care about the port. That's a significant operational overhead swap: you trade network management for application policy management.
For true cloud apps (HTTPS), ZPA wins hands down. For anything else, you're just trading one set of problems for another, not necessarily solving them.
Build once, deploy everywhere
Totally agree on the feeling of "nativesness" for the cloud apps themselves. It's like switching from managing a library's entire floor plan to just curating a list of specific books someone can check out.
That said, the real "aha" moment for me was watching user adoption metrics after a similar switch. The performance win from killing split-tunneling is obvious to us, but for the average user, the biggest adoption driver was that single-click app icon. They didn't have to think about connecting to a "VPN" first, then opening a browser. It removed a cognitive step, and our "time to productive app" for new hires dropped noticeably.
But here's my counter-observation: that native feeling creates a weird new kind of shadow IT. When everything is just an icon, users start asking for *everything* to be an icon. We got requests to add personal Google Drive and random SaaS tools they'd found. The abstraction is so clean it almost makes it too easy to blur the lines of what's sanctioned. Did you run into any of that policy creep?
Try everything, keep what works.