What distinguishes ZTNA from a classic VPN?
A classic remote access VPN extends network access to the end device. ZTNA evaluates access to a specific resource based on identity, device context, and policy. This can reduce the achievable attack surface. However, ZTNA is not an automatic complete replacement for every VPN and must be adapted to applications and operating procedures.
The specific problem: After logging in, too much network is visible
In many environments, a VPN authenticates the user at the gateway and then assigns an internal address and network routes. Which applications are actually needed is often only limited by downstream firewall rules. Over the years, this results in broad access groups, routing dependencies that are difficult to understand, and a great deal of checking for changes.
This is particularly visible in external service providers, administrative access, acquired business units and applications in several clouds. A single access path must then master identity, device, network, DNS, firewall, application and support process at the same time.
An external service provider needs access to two internal web applications. However, the existing VPN connects to a larger network segment. Additional firewalls limit access, but responsibilities and error analysis are spread across multiple teams. ZTNA can align access directly to the two applications – if the identity, application segmentation, and connector path are properly prepared.
ZTNA and VPN in technical comparison
| Decision field | Classic VPN | ZTNA |
|---|---|---|
| Goal of access | Network or network segment | Defined application or resource |
| Policy Context | Often identity plus network and group rules | Identity, device, application, and other contextual signals |
| Accessibility | Internal address spaces are routed to the end device | Application becomes accessible via a controlled mediation path |
| Lateral movement | Must be limited by segmentation and firewalls | Can be reduced by application-related access paths |
| Legacy Protocols | Often broadly compatible | Must be tested per protocol and product function |
| The establishment | Gateway, capacity, patches, routing and firewall rules | Identities, App Segments, Connector, Policies, and Telemetry |
When is ZTNA the better next step?
- External and privileged access: Service providers or administrators should only reach defined resources.
- Hybrid applications: Applications reside in the data center, in multiple clouds, or in separate business units.
- Reduced attack surface: Private applications should not be exposed as generally accessible network services.
- Fine-grained policies: Identity, device and application should converge in a comprehensible access decision.
- VPN operating expenses: Gateways, capacity, routing and recurring disruptions tie up a disproportionate amount of resources.
When does a VPN make sense for the time being?
A VPN may still be required if applications or administration tools require real network access, use unsupported protocols, or lack the required identity and device view. Emergency, machine and special access also often require a separate migration or coexistence path.
Important demarcation: Not every VPN is inherently insecure, and not every ZTNA adoption is automatically Zero Trust. The actual policy scope, the resources that can be reached, the quality of identities and device information, and ongoing operations are decisive.
The five architectural questions before a replacement
- What applications? Capture FQDN, ports, protocols, dependencies, server groups, and dataflows.
- What identities? Separate employees, externals, service accounts, and privileged roles.
- Which devices? Differentiate between managed, BYOD, server, mobile devices and their posture signals.
- What access policy? Set application needs, least privilege, session duration, risk, and exceptions.
- Which operating route? Define monitoring, helpdesk, escalation, change, fallback and responsibilities.
What a migration with Zscaler ZPA can look like
Discovery & Architecture
Capture VPN user groups, applications, logs, dependencies, and special cases. Result: Migration groups instead of uncontrolled Big Bang.
Representative Pilot
Test a suitable application with real identities, end devices, app connectors and policies. Measurably test user experience, security and support.
Waves and operation
Migrate applications according to risk and complexity, deliberately limit coexistence, and hand over runbooks, monitoring, and fallback paths.
How SourcingBlox helps
SourcingBlox combines the architecture decision with the practical implementation. We create the application and access model, plan ZPA components and policies, structure the pilot and migration waves, and prepare for subsequent operation. If desired, we then support changes, troubleshooting and governance as a clearly defined managed service.
Frequently Asked Questions
Can ZTNA completely replace a VPN?
In many application-related access scenarios, yes. Whether a complete replacement makes sense depends on protocols, applications, special access and emergency routes. The result can also be a temporary coexistence.
Is Zscaler ZPA a VPN?
ZPA is a Zero Trust Network Access service. Access is aligned with applications and policies, not blanket network access. The specific suitability must be checked for each application.
What happens to legacy applications?
They are not automatically excluded. First, protocols, name resolution, dependencies, and access patterns are tested. Applications that are not suitable are given their own modernization or transition path.
What is a sensible pilot?
A business-relevant, but manageable application with a clear user group and representative device and identity conditions. A pure laboratory test shows too little about operation and support.
Translating a VPN access into a resilient ZTNA pilot.
Together we choose a representative access path and clarify applications, identities, devices, policies, connector and operational requirements.
Related Content
Technical Primary Sources
- NIST SP 800-207: Zero Trust Architecture
- NIST SP 1800-35: Implementing a Zero Trust Architecture
- CISA: Modern Approaches to Network Access Security
Audit date: July 25, 2026. Specific product, protocol and license support must be checked against the current Zscaler documentation and the respective tenant before implementation.