Why ZPA Is Not Just a VPN Replacement

Zero Trust Foundations • ZPA • VPN Replacement • Field Notes

From flat remote network access to application-specific connectivity, with less infrastructure gravity and a much smaller blast radius.

1. Business value first: private access is a business risk conversation

The business does not usually ask for “a VPN replacement”. The business asks for something much simpler: people must work from anywhere, private applications must remain available, contractors must access only what they need, ransomware must not move freely across the internal network, and IT must reduce complexity instead of adding another fragile infrastructure layer.

Traditional point-to-site VPNs solved an important problem for many years: connecting remote users to corporate resources. But the way they solve that problem is also their weakness. A VPN often places the remote endpoint inside a corporate network context. Once the user is “inside”, the organization has to rely on segmentation, firewall rules, ACLs, endpoint controls and a lot of operational discipline to make sure the user can reach only what is needed.

That sounds reasonable in a design document. In real life, it is often less beautiful.

Rules grow over time.
Temporary exceptions become permanent.
VPN profiles multiply.
Concentrators are deployed per region.
Certificates expire.
Clients must be installed and documented.
Users need guides, and then new guides when the old guide stops matching the client version.
Help desks inherit troubleshooting.
Network teams maintain routing.
Security teams hope segmentation is still aligned with reality.

Core message: VPN connects users to a network. ZPA connects users to applications.

That difference matters because the business risk is not only “can the user connect?”. The real question is: once connected, what can that endpoint see and reach?

2. Field lesson: when one remote client becomes everyone’s problem

Some lessons are learned from documentation. Others arrive as a flood of tickets.

About twelve years ago, when I was working at the Service Desk, a normal working day suddenly became something else. Tickets started arriving all at once. Users could not open files. Not one department. Not one file share. Not one file server. Nobody could open anything anywhere.

The entire IT team went into full incident mode. Infrastructure, networking, systems, support, everyone was involved. The kind of situation where, if you are junior, you mostly try to understand where to stand without becoming another problem.

After a lot of analysis, the root cause became clear: ransomware had entered from the client of a user working from home. Through the VPN, that compromised endpoint had network reachability to corporate file servers. The ransomware used the available access path and encrypted company file servers.

Backups existed. Some data was recovered. Some files were lost anyway.

Field note: remote access is not just a connectivity problem. Remote access is a blast-radius problem.

The attacker did not need a dramatic movie-style attack sequence. The compromised client simply used the connectivity model that had been provided to it. The VPN did its job: it connected the user to the network. Unfortunately, that was exactly the problem.

3. Traditional VPNs: the access point is part of the attack surface

A traditional point-to-site VPN usually requires a public-facing access point: a VPN gateway, firewall, concentrator, or remote access appliance. That component must be reachable from the internet because remote users need to land somewhere.

A traditional remote access VPN with a public facing gateway, the endpoint receiving an address inside the network, and the sixteen operational items that have to be kept alive around it — Figure 1. The tunnel is the small part. Everything underneath it is the operating model that comes with a public endpoint, and the last item on that list is the exception somebody added years ago that nobody dares remove. Original diagram — Zero Trust Navigator.

That requirement creates a simple but uncomfortable truth:

If it has a public IP, it is reachable. If it is reachable, it must be defended. If it must be defended, it must be patched, monitored, upgraded, tested and operated.

CISA describes edge devices such as routers, firewalls and VPN gateways as devices located at network boundaries and accessible from public or external systems. CISA also warns that threat actors exploit vulnerabilities, weak settings and misconfigurations in those devices to gain initial access, move laterally and maintain persistence. Source: CISA Edge Device Security.

NSA and CISA also describe remote access VPN servers as entry points into protected networks and therefore attractive targets for adversaries. Source: NSA/CISA Selecting and Hardening Remote Access VPN Solutions.

This is why VPN risk is not only about the tunnel. It is about the entire operating model around it: public endpoints, certificate lifecycle, client deployment packages, endpoint compatibility, MFA integration, identity mapping, regional concentrators, capacity planning, routing, split or full tunnel decisions, firewall rules, patching, emergency vulnerability response, user documentation and service desk troubleshooting.

Business translation: with VPN, much of the effort is spent keeping the access infrastructure alive. With ZPA, the effort shifts toward defining who should access which application, under which conditions.

4. Public incidents: when VPN access becomes business impact

We do not need theoretical fear to explain remote access risk. There are enough public examples.

Colonial Pipeline

In the Colonial Pipeline ransomware incident, public reporting on Senate testimony stated that attackers exploited a legacy VPN profile that was not intended to be in use. Reporting also stated that this legacy VPN profile did not have multifactor authentication. Source: Cybersecurity Dive. Additional source: Dark Reading.

Travelex and Pulse Secure

Travelex was hit by Sodinokibi/REvil ransomware at the end of 2019. Public reporting linked the attack to unpatched Pulse Secure VPN vulnerabilities, and the disruption forced systems offline and affected business operations. Source: Threatpost. Additional source: Dark Reading.

Akira ransomware and VPNs without MFA

Cisco reported that Akira ransomware actors were targeting Cisco VPN environments not configured with MFA. Cisco described observed cases where threat actors focused on exposed services, missing MFA and VPN software vulnerabilities as part of the initial access phase. Source: Cisco. CISA also published an Akira ransomware advisory that recommends phishing-resistant MFA and remediation of known exploited vulnerabilities. Source: CISA Akira Advisory.

Ivanti Connect Secure and Policy Secure

CISA documented active exploitation of vulnerabilities in Ivanti Connect Secure and Ivanti Policy Secure gateways, including issues that could allow authentication bypass and arbitrary command execution with elevated privileges. Source: CISA Advisory AA24-060B.

Important nuance: the lesson is not “VPN always fails”. The lesson is that internet-facing remote access infrastructure becomes business-critical attack surface and must be operated like one.

5. Field lesson: personal PCs, VPN clients and the certificate illusion

Another field lesson came from users who installed the corporate VPN client on personal PCs.

The first objection from the customer was reasonable: “But we use Microsoft CAs, so certificates are in place.”

That is good. But that is not the end of the conversation.

Are certificates issued only to the right devices?
Are unmanaged devices excluded?
Is certificate enrollment controlled?
Is device identity reliable?
Is the identity model strong enough?
Are user and device trust evaluated together?
What happens if a user installs the VPN client on a personal laptop that nobody manages?

Field note: a certificate authority is not magic. A certificate proves something only if the issuing process, device lifecycle, identity model and policy enforcement are solid.

In a VPN model, if that personal device successfully connects, the next question becomes: what can it reach?

In a ZPA model, the better question is: which application is this specific user, from this specific device posture, allowed to access?

6. Why “just segment the VPN” is harder than it sounds

A common objection is: “We can keep the VPN and just segment the network properly.”

Technically, yes. Operationally, this can become extremely complex.

To make a VPN behave like an application-specific access model, an organization has to design and maintain segmentation across network zones, firewalls, ACLs, routing tables, identity groups, jump hosts, server-side controls and application permissions. Every new application, acquisition, third-party requirement, cloud migration or temporary exception can create another rule, another path, another dependency.

The Zscaler Reference Architecture for ZPA explains that VPNs assign a user an IP address and place that user on the network, while ZPA enables users to connect only to allowed applications, with no access to adjacent applications or systems. Source: Zscaler Reference Architecture Guide for ZPA.

With VPN: Segmentation is something you add after the user is on the network. With ZPA: Application-specific access is the model from the beginning.

7. What ZPA is

Zscaler Private Access, or ZPA, is a cloud-delivered Zero Trust Network Access service designed to provide secure access to private applications without placing the user on the corporate network.

ZPA does not simply replace the VPN tunnel with another tunnel. The important change is that users are not granted broad network reachability. ZPA brokers access to specific applications based on identity, device posture, policy and context.

Zscaler describes ZPA as a service that gives users access to applications without requiring users to share a network context with those applications. Source: Zscaler Help, What Is Zscaler Private Access?.

VPN: User -> Network -> Application ZPA: User -> Policy -> Authorized application

The difference looks small in a diagram. In a ransomware incident, the difference can be enormous.

8. How ZPA works at a high level

At high level, ZPA uses several core components: Zscaler Client Connector, ZPA Service Edge, App Connectors, identity provider integration, application segments and access policies.

The seven steps by which a ZPA session is brokered across the user side, the policy layer and the application side, with the App Connector dialling outbound — Figure 2. Seven steps across three lanes. The one that matters most is step five: the App Connector has already dialled out from beside the application, which is why nothing on the private side needs to be published to the internet. Original diagram — Zero Trust Navigator.

The user tries to reach a private application.
The Client Connector recognizes the application as protected by ZPA.
Identity and context are evaluated.
Policy determines whether access is allowed.
App Connectors provide outbound connectivity from the application environment.
If allowed, ZPA brokers a session between the user and the application.
The user reaches the application, not the network.

The App Connector is especially important. App Connectors sit close to private applications and establish outbound connectivity to the ZPA cloud. This avoids exposing inbound application access to the internet. Source: Zscaler Help, Understanding Private Access Architecture.

The App Connector is the component that makes all of this possible, and it deserves more than a paragraph. It is the subject of the next article in this series: ZPA Part Two: How App Connectors Reach Private Applications.

9. The customer needs time and information to change the paradigm

A customer cannot move from a flat VPN model to a mature Zero Trust access model overnight. And honestly, expecting that to happen is not architecture. It is optimism with a project plan attached.

The customer needs time, information and discovery. In many environments, the painful truth is that nobody has a perfect inventory of what users actually access. The VPN works because it is broad. Users connect, applications respond, and over the years the organization stops asking too many questions because asking those questions would reveal how many dependencies are undocumented.

Key point: ZPA does not only enforce policy. It helps the organization learn what policy should be.

The ZPA Reference Architecture explains that organizations can start with broader access patterns, such as wildcard discovery, then use observed user activity and discovered applications to progressively refine application segments and policies. Source: Zscaler Reference Architecture Guide for ZPA.

10. Discovery: often the customer does not know what users really use

One of the most underestimated parts of a ZPA project is discovery. Many customers do not know exactly which applications users access, which ports are required, which FQDNs are still alive, which file shares are business critical, which internal tools are used only during monthly closing, or which “temporary” server has quietly become production.

A discovery loop of eight steps, from starting with a controlled group through observing access and identifying applications to reducing wildcard access and retiring broad paths, then repeating — Figure 3. Eight steps and no finish line. The loop is the deliverable, because every acquisition, migration and new application puts something back into the left-hand column. Original diagram — Zero Trust Navigator.

The ZPA Reference Architecture explicitly describes this challenge and recommends combining application owner input, existing logs and ZPA application discovery capabilities. The guide also explains that ZPA discovery is passive observation of user requests and destination applications, not an intrusive scanning mechanism. Source: Zscaler Reference Architecture Guide for ZPA.

Field note: “least privilege” is easy to say and hard to implement if nobody knows what users actually use.

11. Transitioning from VPN to ZPA

ZPA does not require the organization to become perfect overnight. This is important.

Five phases from replacing the access path through discovery, segmentation and reducing broad access to retiring legacy dependencies, with what changes at each step — Figure 4. Phase one deliberately does not make anything stricter, and that is the design. Change the transport first, then refine the granularity once the picture exists. The reverse order stalls in month two. Original diagram — Zero Trust Navigator.

The ZPA Reference Architecture explains that one common driver for ZPA deployment is replacing remote access IPSec VPN. The guide also explains that an initial deployment can mirror the open-access VPN model using wildcard app segments and broad access policies, allowing the organization to change the transport first and refine access granularity over time. Source: Zscaler Reference Architecture Guide for ZPA.

Phase 1: Replace the access path

Move users from VPN-based access to ZPA-based access while avoiding business disruption.

Phase 2: Discover

Use logs, discovery, application owner input and telemetry to understand access patterns.

Phase 3: Segment

Create application segments and define policies based on users, groups, posture and business need.

Phase 4: Reduce broad access

Replace wildcard and broad policies with more precise access rules where possible.

Phase 5: Retire legacy dependencies

Reduce or remove VPN access, old firewall rules, unnecessary jump hosts and broad network paths.

12. Why ZPA reduces lateral movement

The ransomware story at the beginning of this article is really a lateral movement story. The affected endpoint did not need access to “the network” in an abstract sense. The business user probably needed access to a small set of applications or file shares. But the VPN model provided a network path wide enough for ransomware to reach file servers.

The path a compromised endpoint takes under a VPN model, through network access, discovery and lateral movement to file servers, compared with the same endpoint stopping at policy evaluation under ZPA — Figure 5. The laptop is compromised in both rows. Every step after the first in the top row was made possible by the access model rather than by the malware, which is the entire argument of this article in one picture. Original diagram — Zero Trust Navigator.

ZPA is designed to avoid broad network access by allowing access to specific applications only. The ZPA Reference Architecture states that applications are invisible unless the user is authorized to access them, and that ZPA connects users only to allowed applications with no access to adjacent applications or systems. Source: Zscaler Reference Architecture Guide for ZPA.

Important: this does not mean ransomware becomes impossible. It means the access model is designed to reduce what a compromised endpoint can see and reach.

13. Business value: from maintaining access infrastructure to using the platform

The strongest business value of ZPA is not only stronger security. It is that IT effort moves away from keeping remote access infrastructure alive and toward defining, measuring and improving secure business access.

Where the effort goes
Area	VPN operating model	ZPA operating model
Access surface	Public VPN endpoints must be exposed and defended.	Applications are brokered through ZPA and are not directly exposed to the internet.
User reachability	Remote users may receive network-level reachability.	Users receive application-specific access based on policy.
Operations	VPN gateways, certificates, clients, routing and patching must be maintained.	Effort shifts to identity, posture, application segments and access policy.
Third-party access	Contractors often require VPN profiles or network exceptions.	Contractors can receive access only to specific applications.
Ransomware blast radius	Broad network access can create dangerous paths if segmentation is weak.	Application access reduces unnecessary visibility and reachability.

Business outcome: the organization stops spending most of its energy maintaining the access road and starts focusing on who should access what, why, from where, and under which conditions.

Final thoughts

A traditional VPN was designed to solve a practical problem: connect remote users to internal resources.

ZPA solves a different problem: give users access to the private applications they are allowed to use without placing them on the network.

That difference matters because when a remote endpoint is compromised, the question is not only “did the user authenticate successfully?”. The question is also: what can that endpoint now reach?

In the old model, the answer may be: too much. In the ZPA model, the target answer is: only the applications explicitly allowed by policy.

After you have seen one compromised VPN client encrypt file servers across the company, precision stops being a nice architectural concept. It becomes a business requirement.

This article explained why access should be brokered to applications rather than networks. The next one explains how ZPA actually reaches those applications: ZPA Part Two: How App Connectors Reach Private Applications.