For more than twenty years, the VPN has been the standard answer to an essential question: how do you let users and remote sites access corporate infrastructure securely? But the perimeter the VPN was designed to protect has dissolved: applications spread between the datacenter and the cloud, employees working from anywhere, and attackers who have learned to exploit the model's weak point: once inside the tunnel, the whole network is within reach.
Against this backdrop, ZTNA (Zero Trust Network Access) has been gaining ground: a model that replaces access to the network with access to the application, with continuous verification of user identity and device posture. Does that mean the VPN is dead? Not at all: site-to-site tunnels between offices and the datacenter, access to management networks and non-web protocols remain its natural territory.
In this article we compare both technologies from a technical standpoint: how they work, where each one fails, and how to combine them in a realistic hybrid approach. If what you are after is the complete Zero Trust strategic model — principles, adoption phases and reference architecture — we cover it in our practical guide to Zero Trust; here we focus on the technology comparison for remote access.
How a VPN Works: Encrypted Tunnels with IPsec, WireGuard and OpenVPN
A VPN creates an encrypted tunnel between two endpoints: IP traffic is encapsulated, encrypted and travels across the internet as if both ends were plugged into the same cable. To the operating system, the remote network shows up as just another network interface, with its address range and routes. The three dominant protocols today are IPsec, OpenVPN and WireGuard.
IPsec is the IETF standard and operates at the network layer, with IKEv2 handling key negotiation. It is the default protocol on enterprise firewalls and routers, which is why it dominates site-to-site tunnels: proven interoperability between vendors, hardware acceleration and two decades of maturity. The trade-off is complex configuration, with many parameters that must match on both ends.
OpenVPN is built on TLS and runs in user space, which makes it extremely portable and able to traverse restrictive networks by encapsulating traffic over TCP/443. In exchange, its performance is the lowest of the three. WireGuard is the newcomer that changed the rules: around 4,000 lines of code (versus hundreds of thousands for OpenVPN or the IPsec stacks), modern cryptography with no negotiation (ChaCha20-Poly1305, Curve25519), integration in the Linux kernel since version 5.6 and far superior performance with a minimal, SSH-style configuration based on key pairs.
Remote Access VPN vs Site-to-Site VPN
The word "VPN" covers two very different use cases that are often confused. A remote access VPN connects an individual user to the corporate network: a client installed on the laptop brings up the tunnel against a concentrator sitting on the perimeter, and from there the employee works "as if they were in the office". It is the classic remote-work model, and the one ZTNA calls into question.
A site-to-site VPN connects entire networks to each other: the office firewall establishes a permanent tunnel — almost always IPsec — against the datacenter firewall, and machines on both networks communicate transparently, with no clients and no user involvement. It is the natural way to join the office with hosted infrastructure: the datacenter servers appear as just another company subnet. This kind of interconnection is a standard part of our network solutions for customers with dedicated servers and private cloud.
This distinction matters because the VPN vs ZTNA debate applies almost exclusively to the first case. ZTNA competes with user remote access; site-to-site tunnels between infrastructures solve a different problem that ZTNA was never designed for.
The Limitations of the Remote Access VPN Model
The structural problem of the remote access VPN is its trust model: it authenticates once and grants access to the network, not to specific applications. Unless careful internal segmentation is in place, a user who passes authentication lands on a flat network where they can reach servers, databases and services they do not need for their job.
That breadth is exactly what an attacker needs for lateral movement: once a device or a set of credentials is compromised, the VPN tunnel becomes a highway into the rest of the infrastructure. Credentials stolen through phishing are equivalent to the entire network if there is no MFA, and ransomware campaigns have been exploiting precisely this entry point for years. Internal segmentation mitigates the damage — we explain it in detail in our article on VLANs and network microsegmentation — but it does not remove the root problem.
The second front is the VPN concentrator itself. On one hand it is a bottleneck: all remote traffic flows through it, even traffic destined for SaaS applications, with the latency and sizing implications that entails. On the other, it is by definition a service exposed to the internet, and recent years have produced a long list of critical CVEs in VPN appliances from top-tier vendors, exploited at scale before a patch existed. Every public VPN appliance is a permanent attack surface.
The root problem:
The remote access VPN authenticates once and trusts forever for the duration of the session. Without additional controls, stolen credentials are the equivalent of a network cable plugged in directly inside your datacenter.
What Is ZTNA: Per-Application Access with Continuous Verification
ZTNA (Zero Trust Network Access) inverts the model: instead of connecting the user to the network, an access broker mediates every connection to every individual application. The user never "enters the network"; they request access to a specific application and the broker decides whether to grant it, based on policies that evaluate far more than a password.
That evaluation combines identity and device posture, and it is continuous: who the user is (federated with the identity provider, with MFA), which device they connect from (is the disk encrypted? is the EDR running? is it patched?), from where and at what time. If posture changes mid-session — the antivirus is disabled, the device falls out of policy — access is revoked without waiting for the next authentication.
The key architectural difference is that applications are no longer exposed to the internet: a lightweight connector next to the application establishes outbound connections to the broker, so there is no public port to scan and no appliance to exploit. And the guiding principle is least privilege by default: everything is denied except what a policy explicitly grants, application by application and user by user. Cloudflare offers a good technical introduction to ZTNA as a neutral reference. These access controls complement — they do not replace — the perimeter and internal protection measures we group under our managed security services.
Comparison Table: VPN vs ZTNA
The following table summarises the differences between the remote access VPN and ZTNA across the criteria that matter most when designing an organisation's remote access:
| Criterion | Remote access VPN | ZTNA |
|---|---|---|
| Trust model | Single authentication; trusted for the whole session | Continuous verification of identity and posture |
| Granularity | Entire network or subnet | Individual application |
| Exposed surface | Public concentrator on the internet (CVEs) | Applications not exposed; only the broker |
| User experience | VPN client; latency from traffic backhauling | Transparent; direct per-application access |
| Complexity | Low-medium (mature technology) | Medium-high (identity + posture + policies) |
| Cost | Low (appliance or open source software) | Per-user monthly subscription |
| Supported protocols | Any IP traffic | Mostly web; legacy protocols with limitations |
The honest reading of the table is that ZTNA wins on security and granularity, while the VPN wins on simplicity, cost and protocol universality. That is why the right answer is rarely "one or the other".
When VPN Is Still the Right Answer
Despite the commercial push behind ZTNA, there are scenarios where the VPN is not only still valid but the technically superior option:
- check_circle Site-to-site tunnels between office and datacenter: permanently connecting entire networks is an infrastructure problem, not a user-access one. An IPsec tunnel between firewalls remains the standard and most efficient solution.
- check_circle Access to management networks (iLO, iDRAC, IPMI): out-of-band management interfaces should never be exposed to the internet or routed through third-party brokers. A dedicated VPN into the management network, restricted to administrators, is the recommended practice.
- check_circle Non-web protocols: database replication, SMB, backup traffic, legacy client-server applications or any protocol needing bidirectional IP connectivity works naturally over a VPN and awkwardly (or not at all) over many ZTNA offerings.
- check_circle Limited budget: a well-managed WireGuard server — with MFA at the identity layer, per-device keys, route-based segmentation and periodic access reviews — delivers an excellent level of security with no licensing cost. For a small team, it is hard to beat.
Hybrid Approach: Gradual Migration Without Disruption
In practice, the transition from VPN to ZTNA is not a replacement but a planned coexistence. The path that works best starts with an inventory of which applications remote users actually consume, then classifies them: internal web applications and the most sensitive services are the first candidates to move behind the ZTNA broker, because that is where granularity and non-exposure add the most value.
As applications migrate, the VPN concentrator loses traffic and users: it can be downsized, its policies hardened and its use limited to the cases where it remains the right tool — administrators reaching the management network, legacy protocols, site-to-site tunnels. The end state is not "zero VPN" but a small, closely watched VPN with a specific purpose, alongside a ZTNA that carries the bulk of user access.
This coexistence can last for years without being a problem, as long as each technology has a clearly bounded scope and both integrate with the same identity provider and the same MFA policies.
Frequently Asked Questions
Does ZTNA completely replace VPN?
No. ZTNA is a clear improvement for user-to-application remote access, but site-to-site tunnels between offices and the datacenter, access to management networks (iLO, iDRAC) and non-web protocols remain natural VPN territory. Most organisations run a hybrid model for years.
Which VPN protocol is best: IPsec, WireGuard or OpenVPN?
It depends on the use case. IPsec is the standard for site-to-site tunnels between firewalls thanks to its interoperability. WireGuard delivers the best performance with a minimal codebase and is ideal for modern remote access. OpenVPN stands out for maturity and compatibility when WireGuard is not available or traffic must traverse very restrictive networks.
Is ZTNA more expensive than a VPN?
In licensing terms, usually yes: ZTNA is typically billed per user per month, while a self-managed VPN only requires an appliance or a WireGuard server. For small teams, a well-managed VPN with MFA and segmentation is cheaper. Beyond a certain scale, the operational cost and risk of the VPN model can outweigh the cost of a ZTNA subscription.
Conclusion
VPN and ZTNA are not direct competitors on every front: they are tools with different trust models that solve partially overlapping problems. The key takeaways:
- arrow_right The remote access VPN grants network access after a single authentication: a flat network, possible lateral movement and exposed concentrators as attack surface.
- arrow_right ZTNA grants per-application access with continuous verification of identity and posture, without exposing applications to the internet and with least privilege by default.
- arrow_right The VPN is still the right answer for site-to-site tunnels, management networks, non-web protocols and tight budgets with a well-operated WireGuard.
- arrow_right The hybrid approach — ZTNA for user access, a scoped-down VPN for infrastructure and management — is the realistic destination for most organisations.
If you are designing remote access to your hosted infrastructure — site-to-site tunnels, isolated management networks or a migration strategy towards Zero Trust — contact our team for a technical assessment with no obligation.