ZTNA vs. VPN: Rethinking Remote Access

The problem with VPN is the trust model, not the tunnel

A VPN does one thing well: it encrypts a tunnel between a remote device and your network. The trouble is what happens once that tunnel is up. Traditional remote access authenticates a user at the front door and then drops them onto a network segment as if they were sitting in the office. From that point, connectivity is implicit. The user can reach far more than the two or three applications they actually need, and often can see swaths of internal address space, file shares, management interfaces, and legacy systems that were never meant to be exposed to a laptop on a hotel Wi-Fi.

That implicit trust is exactly what attackers exploit. Once a single set of VPN credentials is phished or a single remote endpoint is compromised, the intruder inherits the same broad network reach the legitimate user had. Lateral movement — pivoting from the initial foothold toward domain controllers, backup servers, and data stores — is the phase where a contained incident becomes an enterprise-wide breach. Verizon's Data Breach Investigations Report has for years shown stolen credentials and remote-access pathways among the most common entry points, and IBM's Cost of a Data Breach research consistently ties the highest costs to breaches that dwell and spread before detection. A flat network reached over VPN is an accelerant for both.

There are operational problems too. VPN concentrators are sized for a fraction of the workforce and became bottlenecks the moment everyone went remote. They require an inbound listener on your perimeter — a public IP and port that is continuously scanned, and that has been the subject of a steady stream of critical vulnerabilities in VPN gateway appliances. And the user experience is poor: full tunnels backhaul cloud-bound traffic through headquarters, adding latency to applications that no longer live there anyway.

How ZTNA changes the model

Zero Trust Network Access inverts the default. Instead of connecting a device to a network, ZTNA brokers access to a specific application, one request at a time, only after the user and device are verified. Nothing is implicitly reachable.

Figure: ZTNA grants access to one named application at a time — identity and device posture are checked on every session, and nothing else on the network is exposed.

The mechanics differ from a VPN in ways that matter:

• Identity is the control plane. Access decisions bind to a verified identity from your identity provider, ideally behind phishing-resistant MFA. The user is authorized for named applications — a payroll system, a Git server, an internal wiki — not for a subnet.
• Device posture is evaluated continuously. Before and during a session, the broker checks signals such as disk encryption, EDR presence, patch level, and whether the device is managed. A non-compliant laptop can be limited or denied even with valid credentials.
• No inbound exposure. ZTNA connectors make an outbound connection to the broker, so applications sit behind the broker with no open inbound port on your perimeter. Resources are effectively dark to the public internet — an attacker cannot scan or attack what does not answer.
• Least privilege by default. Because access is per-application, a compromised session reaches only what that user was explicitly granted. The blast radius shrinks from "the whole network" to "one app," which is the entire point of designing for a limited blast radius.

This is the network-layer expression of the broader Zero Trust principle: never trust based on network location, always verify with identity, device, and context on every request.

The user experience actually gets better

Security changes usually ask users to trade convenience for safety. ZTNA is one of the rare cases where the safer option is also the nicer one.

• No client-to-network setup ritual. Access to internal apps can run through the identity provider and a lightweight agent, so users authenticate the way they already do for SaaS.
• Direct-to-app routing. Traffic goes to the application over the nearest broker point of presence rather than hairpinning through a distant concentrator, so latency drops for cloud-hosted and SaaS resources.
• Consistency everywhere. The same policy applies in the office, at home, and on the road. There is no "on VPN" versus "off VPN" mode for users to remember, and no concentrator capacity ceiling on a busy Monday morning.

Fewer support tickets, faster app access, and a smaller attack surface tend to make ZTNA one of the easier security investments to justify to both users and finance.

A migration path from VPN to ZTNA

You do not rip out the VPN on a Friday. The proven approach runs ZTNA alongside the existing VPN and retires access application by application, front-loading the highest-risk exposure.

1. Inventory what VPN actually reaches. Most organizations are surprised by how much is exposed. List the applications, the user groups that need them, and the protocols involved. This inventory is the scope of your rollout.
2. Get identity and MFA in order first. ZTNA is only as strong as the identity behind it. Enforce phishing-resistant MFA and clean up identity and access management before you depend on it for authorization. This is the prerequisite, not a parallel task.
3. Start with your highest-risk applications. Move the crown jewels first — administrative interfaces, financial systems, source code, anything holding regulated data. These are the resources you least want reachable from a flat network, so they earn the most risk reduction per app migrated.
4. Run in monitor mode, then enforce. Publish each app through ZTNA and observe real access patterns before you turn on blocking. The fastest way to get a rollout cancelled is a day-one outage from a policy that was too tight.
5. Decommission VPN access per application. As each app group proves out on ZTNA, remove its VPN reachability. When the last group migrates, retire the concentrator and close the inbound port entirely — eliminating both the bottleneck and a favorite target.

Two guardrails throughout. Keep a documented rollback for each app so a broken policy is a five-minute fix, not an incident. And integrate device posture with the endpoint management tooling you already run so the compliance signals ZTNA checks are the same ones your fleet already reports.

Where ZTNA fits within SASE

ZTNA is not a standalone destination. It is one of the security services inside Secure Access Service Edge, and it is almost always the first phase organizations adopt because it delivers the most visible risk reduction on its own. Once ZTNA is carrying remote access, the same cloud-delivered edge naturally extends to secure web gateway for internet traffic, cloud access security broker for SaaS control, and firewall-as-a-service for branch inspection — all under one policy engine and one identity context.

The networking half of that convergence is SD-WAN, which provides the application-aware on-ramp that carries branch and remote traffic into the edge. Planning ZTNA as the opening move of a broader SASE strategy means each phase stands on its own while building toward a single, consistent model for connecting users to applications — regardless of where either one sits.

Retire the flat network

VPN did its job for the era of the office perimeter. That perimeter is gone, and the implicit trust it granted is now a liability that turns one stolen credential into a network-wide incident. ZTNA replaces "connect to the network, then reach everything" with "verify identity and device, then reach exactly one application" — smaller attack surface, no inbound exposure, and a better experience for the people using it.

intSignal designs and operates ZTNA and full SASE deployments end to end, from scoping the application inventory and hardening identity to sequencing the rollout so VPN retirement happens without disrupting production. If your remote access is straining the concentrator or still assumes a perimeter that no longer exists, talk to our network team for a candid read on where to start.