Modern applications support a zero trust architecture, either directly or through an application gateway.
They use transport layer security (TLS), such as HTTPS, to encrypt traffic, along with secure authentication and authorisation measures.
This is the same security that is used on the internet when accessing your bank account or interacting with the government.
Adding a VPN to a modern application reduces security. This article explains why.
Zero trust architecture
Zero trust architecture (ZTA) provides a secure environment, and protects against both external attackers and internal attackers.
The canonical reference is NIST SP 800-207, which defines zero trust as per-request authentication and authorisation, with no asset trusted simply because of its network location.
Good security follows the principle of least privilege. If an attacker does compromise an endpoint, they are limited to direct attacks only against the applications that the user has access to, minimising the blast radius.
Basic zero trust security can be improved by adding an application gateway (proxy or firewall) in front of applications for centralised filtering. Device posture — patch level, disk encryption, EDR status — is also checked on every request, so a compromised endpoint loses access without any change to the application.
Adding a VPN reduces security
This post is about user VPNs that place an end-user device onto a corporate network. Site-to-site VPNs are a separate discussion.
Adding a virtual private network (VPN) on top of a modern application that supports zero trust is a security trade-off.
There is a small increase in protection against external attackers from defence in depth. An external attacker needs to breach both the VPN and the transport layer security.
VPNs do also have other benefits, such as hiding connection metadata, and changing the network exit point — although a proxy can do similar.
However the trade-off is that they provide access from a compromised endpoint to the wider network, granting far more privilege than the application requires.
This would allow an attacker to target unprotected internal systems and communications, well beyond the application they are accessing.
From the Open Security Architecture documentation:
"… VPN creates a network tunnel that extends the corporate network to the remote device — simple to understand but architecturally flawed because it places a potentially compromised device directly on the corporate network …"
In most modern application environments that already supports zero trust, adding a VPN compromises security more than the minor (almost zero) additional protection against external attackers.
Auditors, insurers and internal security teams sometimes apply compliance pressure to "put it behind the VPN" as a blanket control. For an app that already implements zero trust this is the wrong instinct — a control that reduces overall security shouldn't be mandated in the name of security.
Legacy applications
Legacy applications, that don't support a zero trust architecture, may however require a VPN for any secure external access.
The virtual private network provides the necessary encryption and authentication layers, to protect against external attacks, with the same trade-offs of putting a potentially compromised external device onto the internal networks, where an attacker can then reach other internal systems.
Legacy applications are already also vulnerable to internal attackers.
Owners may think they are secure because they are on a protected private network, but it is usually relatively trivial for an attacker to gain internal access — for example by using social engineering to bypass the perimeter or plugging a small implant into an unattended network port. MITRE catalogues this as a standard initial-access technique T1200: Hardware Additions.
Trusting a device or user simply because they are on the internal network is a mistake.
The Open Security Architecture explains this well:
"Traditional perimeter-based security — firewalls at the edge, trusted internal networks, VPN tunnels for remote access — fails when attackers breach the perimeter or when insiders act maliciously. Once inside the trusted zone, lateral movement is trivial. Zero trust eliminates this architectural weakness …"
While a VPN may provide a means of external access, it fails to address the internal attack vulnerability at all.
Rather than provide VPNs the focus should be on adding transport layer security and authentication to legacy applications, to support zero trust.
If the legacy applications can't be upgraded, then there may be ways to front them with an identity-aware reverse proxy such as Caddy or nginx, so the legacy app is never directly exposed.
Or identity-aware access services, sometimes marketed as zero trust network access (ZTNA), can publish individual legacy apps to authenticated users without placing the device on the internal network — a reasonable stepping stone while legacy apps are modernised or retired.
Next steps
- If your application already supports zero trust architecture, then it already has high security.
- Adding a VPN on top of a modern application reduces security and should be avoided.
- Prefer adding zero trust security to legacy applications over exposing them via a VPN.
- If a VPN is needed, only use it for the specific legacy applications that lack protection, and segment the access from the broader network.
- Keep the VPN's scope narrow. Don't use it for applications that already have their own security — doing so adds risk without adding protection.
Diagram icons from the OSA Icon Library, Copyright CC BY-SA 4.0 Open Security Architecture.