In short
ZTNA vs IPsec is not really an encryption contest. IPsec and SSL VPNs authenticate a device or user and then route them onto a network; ZTNA authorises each application request through a policy engine and brokers a per-app connection, usually via outbound-only connectors. IPsec remains the normal choice for site-to-site tunnels, including branch links into SASE.
Want an impartial recommendation?
Tell us about your users, systems and priorities and we will tell you which option fits, and why.
Three ways to reach private resources
IPsec works at the network layer. IKE (normally IKEv2) authenticates the two ends and negotiates security associations, then ESP encrypts and authenticates IP packets between them. It is used for both remote access, where a client connects to a gateway, and site-to-site, where two gateways join networks together.
SSL/TLS VPN carries traffic inside TLS, typically on TCP port 443, which passes through most hotel and guest networks. Many products also use DTLS over UDP for better performance with real-time traffic. Some offer a clientless web portal for browser access to a few internal sites, alongside a full-tunnel client that behaves like any other VPN.
ZTNA separates the decision from the transport. A client, or the browser for clientless access, asks a broker for a specific application; a policy engine evaluates user, device and context; and if access is allowed, a connection is stitched together to a connector running beside the application. The connector makes outbound connections to the broker, so the application needs no inbound ports at all.
Protocol-level comparison
| IPsec VPN | SSL/TLS VPN | ZTNA | |
|---|---|---|---|
| Layer | Network (IP packets via ESP) | Transport/session (TLS or DTLS), carrying IP or app traffic | Application session, brokered per app over TLS or vendor transports |
| What is authenticated | Gateway and peer (certificates or pre-shared keys), user via EAP or similar for remote access | Gateway certificate and user; device checks vary | User, device and context on every request, evaluated by a policy engine |
| What becomes reachable | Routed subnets, limited by firewall rules | Routed subnets (tunnel mode) or published portal links | Only the applications the policy allows |
| Inbound exposure | Gateway listens on UDP 500 and 4500 (and ESP) | Gateway portal listens on TCP 443 and often UDP for DTLS | Applications and connectors take no inbound connections; only the provider's broker is public |
| NAT and firewall | NAT traversal wraps ESP in UDP 4500; some networks block it | Usually passes networks that allow web traffic | Outbound only from connectors; clients reach the broker on common ports |
| Typical use | Site-to-site, branch to cloud, remote access | Remote access for users | User-to-application access from anywhere |
Still not sure which way to go? Ask us
Tell us what matters most to you and we will recommend one, with the trade-offs explained.
IPsec remote access and site-to-site
IPsec is mature, standards-based and interoperable, which is why it is still the backbone of site-to-site connectivity. For remote access it has two weaknesses in a zero trust design. First, authentication happens once, when the tunnel comes up; after that, the device is a peer on the network and access is governed by whatever routing and firewall rules sit behind the gateway. Second, the gateway has to listen for IKE from the internet.
Neither is fatal. A well-built IPsec remote access service with certificate-based device authentication, MFA, a posture check and tight per-group rules is much stronger than a flat one. It is still network-level access, which is what the NCSC's guidance on ZTNA vs VPN asks you to move away from for user access.
SSL VPN: convenient, and exposed
SSL VPNs became popular because TLS on port 443 just works through most networks and the portal gives clientless access to a few web apps. The trade-off is that the gateway is effectively a public web application that grants network access. Because it must accept connections from anyone, any flaw in it is reachable from the whole internet, and its own authentication sits in front of everything behind it.
That is precisely the NCSC's third anti-pattern in a different form: a component exposed to the internet where a flaw lets an attacker in before any policy check runs. The NCSC's recommendation is to keep private services off the internet and broker access through a hardened component, so that only that component is publicly exposed. In ZTNA, that component is run by the provider and the connectors in your network make outbound connections only.
Weighing up the options?
We can compare them against your own requirements and give you a straight answer.
How ZTNA products transport traffic
ZTNA vendors use different transports, and it is worth knowing which because it affects performance, firewall needs and protocol support:
| Product | Transport described by the vendor | Notes |
|---|---|---|
| Cisco Secure Access (client-based ZTNA) | QUIC and MASQUE from Cisco Secure Client's Zero Trust Access module | Resource connectors run beside the apps; clientless browser access also available, including browser-based SSH and RDP |
| NordLayer | NordLynx, Nord Security's protocol built around WireGuard, with other VPN protocols available | Virtual Private Gateways on dedicated servers give a fixed IP for allowlisting |
| Zero Networks Connect | Lightweight, self-updating WireGuard-based client | No open ports until the user passes MFA; then open only to that user's IP for a set time |
| WatchGuard FireCloud Total Access | WireGuard tunnel to the nearest point of presence, then a second WireGuard tunnel to a FireCloud Gateway on your network | The gateway can be an existing Firebox or a FireCloud virtual gateway |
| Todyl SASE | Always-on agent tunnel to the nearest point of presence on Todyl's Secure Global Network | Same agent as Todyl Endpoint Security |
The point the NCSC makes in its first design requirement is worth repeating: secure transport, whether TLS or IPsec, is necessary but does not establish trust on its own. A WireGuard tunnel that reaches the whole network is still a VPN. What makes it ZTNA is the per-request policy decision and the per-application scope. See the NCSC's How to implement ZTNA for the full list of requirements.
Where IPsec still has a place
Retiring remote access VPNs usually increases the amount of site-to-site IPsec, not reduces it, because offices and cloud networks connect into the security cloud with IPsec tunnels:
- Todyl SASE Tunnel provides IPsec site-to-site connections from an office or cloud network into Todyl's Secure Global Network.
- Cisco Secure Access accepts network tunnels from branches; Cisco SD-WAN can set them up automatically, and Secure Firewall Threat Defense 10.1 added a wizard for site-to-site tunnels to Secure Access.
- NordLayer Premium adds a Site-to-Site connector for linking office networks.
- SD-WAN overlays, including those in Check Point SASE and the Exium Cyber Gateway, connect sites and steer traffic across multiple links.
How branch networking and SASE fit together is covered on SASE vs SD-WAN.
Remote access VPN vs site-to-site
These are often confused in buying conversations. A remote access VPN connects an individual device to a network; it is the thing ZTNA replaces. A site-to-site VPN joins two networks through their gateways, with no software on user devices; it carries traffic between offices, data centres and cloud networks and is still the normal way to connect a branch into an SSE or SASE platform. Server-initiated flows and some legacy protocols are the main reasons to keep a small amount of remote access VPN alongside ZTNA.
Choosing per use case
| Use case | Usual fit | Why |
|---|---|---|
| Staff to internal web apps | ZTNA (client-based or clientless) | Per-app scope, nothing exposed, works on unmanaged devices via the browser |
| Staff to thick-client apps, file shares, SSH and RDP | Client-based ZTNA | Covers non-web protocols; test each app in a trial |
| Admins to servers | ZTNA or an RDP broker, with MFA before admin ports open | Limits blast radius of stolen admin credentials |
| Server-initiated or unusual legacy protocols | Tightly scoped VPN or VPN-as-a-service | Network-level access, restricted to the minimum |
| Branch office into the security cloud | IPsec site-to-site or SD-WAN | No client on every device; standard and interoperable |
Our VPN replacement project guide turns this into a migration plan. If you would like us to review your current IPsec or SSL VPN configuration and which flows could move to ZTNA, contact us; scope is confirmed at quote.
How Forever Systems helps with ZTNA and SASE
We are an independent IT and cyber security provider. We supply and support several zero trust access and SASE platforms, so we can recommend what fits how your people work rather than one vendor's answer to everything.
- Assess first: we look at your current VPN, firewall, identity set-up and the applications people need to reach before suggesting anything new
- Vendor-aware advice across ZTNA, SSE and SASE options, including Cisco Secure Access and Check Point Harmony SASE
- Pilots and phased roll-out: we can help you start with one group of users or one application, then extend access policy by policy
- VPN replacement: planning the move away from remote access VPNs, including identity provider integration and device posture checks
- Ongoing support: policy changes, licence reviews and renewals, with the details confirmed at quote
We work with businesses, schools, charities and public sector organisations. Pricing depends on users, features and term, so ask us for a quote.
Frequently asked questions
Is ZTNA more secure than IPsec?
For user access to applications, ZTNA is usually the stronger design because it authorises each application request and keeps applications off the internet, while an IPsec remote access VPN authenticates once and routes the device onto the network. The encryption itself is strong in both cases; the difference is what is reachable.
Does ZTNA use IPsec?
Some platforms use IPsec for site-to-site tunnels from offices and cloud networks into their points of presence. For user devices, vendors commonly use TLS, QUIC and MASQUE (Cisco Secure Access) or WireGuard-based tunnels (NordLayer, Zero Networks Connect, WatchGuard FireCloud).
Is an SSL VPN zero trust?
Not by itself. An SSL VPN gateway is exposed to the internet and usually grants network-level access after sign-in. Adding MFA and posture checks helps, but zero trust access needs per-request, per-application policy decisions.
What is the difference between remote access VPN and site-to-site VPN?
A remote access VPN connects one device to a network and needs a client on that device. A site-to-site VPN connects two networks through their gateways. ZTNA replaces remote access VPNs for most users; site-to-site IPsec remains the normal way to connect offices and cloud networks, including into SASE.
Can ZTNA replace site-to-site VPNs?
Not usually. ZTNA is about users reaching applications. Branch-to-cloud and office-to-office links still use IPsec or SD-WAN, which is why SASE combines both.
Still deciding?
Ask us and a member of our team will reply by email with a straight answer.