ZTNA vs Site-to-Site VPN: What Zero Trust Can Replace

ZTNA can replace a site-to-site VPN for everything people do: users reaching applications, partners reaching one system, a newly acquired company reaching your ERP. It cannot replace the tunnel for what machines do to each other: domain controller replication, monitoring that polls branch devices, phone systems, storage replication and industrial control traffic. Most organisations with more than a handful of sites end up with both, and the useful question is how small the tunnel can become.

That distinction is missing from most comparisons. Search for "ZTNA vs site-to-site VPN" and nearly every result compares a remote-access VPN client on a laptop with a ZTNA agent. That is a different decision, covered in IPsec VPN versus ZTNA for remote access. This article is about the tunnel between your buildings.

What each one actually connects

A site-to-site VPN connects networks. ZTNA connects an identity to an application. A tunnel between head office and a branch makes the two address ranges behave like one routed network, so anything on either side can reach anything on the other unless a firewall rule stops it. ZTNA gives a verified user, on a checked device, access to one named application and nothing else.

Site-to-site IPsec works at the network layer. It encrypts IP packets between two gateways and carries whatever is inside them, including routing protocols when the tunnel is route-based.

ZTNA works at the application layer. In the model NIST describes in SP 800-207, a policy decision point checks every request and an enforcement point brokers the session. In practice a connector sits next to the application and opens an outbound connection to the broker. Users never receive an address on the target network. They reach a published application by name, after identity and device checks, and the network behind it stays invisible.

SD-WAN often gets mixed in. It is transport: encrypted overlays across several links, with each application steered over the best path. It still produces a routed network between sites, and only becomes a zero trust design when identity-based access is added on top, as in a SASE platform. The SD-WAN guide covers the transport side.

Sources: IETF RFC 4301 and RFC 7296 (IPsec and IKEv2), NIST SP 800-207 (Zero Trust Architecture).

Where ZTNA cannot replace a site-to-site tunnel

ZTNA cannot carry traffic that starts at the data centre and goes out to a branch device, traffic that depends on broadcast or multicast, or protocols that only work over a routed path. That rules out a pure ZTNA design for domain controller replication, central monitoring and scanning, desk phones, print servers, storage replication and most industrial control traffic.

Projects that cut every tunnel at once break here, for one reason: a ZTNA connector waits for a user's request and does not route.

Server-initiated connections

A lot of IT management runs from the centre outwards. Configuration Manager pushing software to branch machines, Ansible opening SSH to a branch hypervisor, a monitoring server polling a switch or a UPS over SNMP: all of these start at head office and need to reach a private address at the branch. A vulnerability scanner needs raw layer 3 and 4 access to fingerprint hosts and probe ports. Behind a ZTNA broker, the scanner sees nothing, which leaves the branch as a blind spot in your asset inventory.

Active Directory replication

Branch domain controllers replicate with the core in both directions over RPC, using the endpoint mapper on TCP 135 and a dynamic high port range (49152 to 65535), alongside Kerberos, LDAP and SMB. Practitioners who moved this behind application connectors report intermittent replication failures. The common fixes are a locked-down tunnel that only carries domain controller traffic, or moving to cloud identity.

Voice and printing

When an on-premises phone system rings a branch phone, the PBX starts the SIP session towards the phone, and the audio runs over dynamically negotiated UDP ports. Pushing that through a cloud broker adds delay and jitter, and teams report one-way audio and dropped registrations. Printing has the same shape: printers announce themselves with multicast discovery, and a central print server opens the connection to the printer on TCP 9100 or 515.

Industrial and building systems

PLCs, controllers and building management systems speak protocols such as Modbus/TCP, DNP3 and EtherNet/IP. Some, like PROFINET and EtherCAT, run directly on Ethernet frames. These devices cannot run an agent, have no user identity and do not speak web protocols. A SCADA server talking to field controllers needs a stable routed path.

Bulk replication

Nightly backup and storage replication moves large volumes between sites. Hardware IPsec handles that at line rate; a cloud broker adds a bottleneck and sometimes data transfer charges.

None of this makes ZTNA weaker. It makes it a different tool. The tunnel stays where machines talk to machines. The point is to stop using it for everything else.

Where replacing the tunnel pays off

Replacing the tunnel pays off for every connection a person makes. Moving user access to ZTNA removes the routed path an attacker would use to move from a compromised branch laptop to your servers, takes the VPN gateway off the internet for that use, and makes overlapping address ranges irrelevant.

No path for lateral movement

With a site-to-site tunnel, a branch device that falls to phishing can reach the head office ranges. Scans, ARP sweeps and exploitation attempts cross the tunnel like any other traffic, and hypervisors, domain controllers and backup servers are in reach unless internal rules are tight. With ZTNA, the branch device never joins the head office network. It can reach the applications its user is entitled to, and nothing else. The blast radius of one compromised laptop shrinks to that laptop and a handful of application sessions. The guide to network segmentation covers the step from VLANs to identity-based isolation.

Fewer exposed gateways

Perimeter devices that accept connections from the internet are among the most targeted systems of the last few years. CISA's Known Exploited Vulnerabilities catalogue includes CVE-2024-3400 in Palo Alto's GlobalProtect, CVE-2024-21762 in the FortiOS SSL VPN, CVE-2024-40766 in SonicWall's SonicOS, and the Cisco ASA flaws used in the ArcaneDoor campaign. Most of these sit in remote-access and management services rather than in IPsec itself, but they all live on the same internet-facing box. A ZTNA connector opens no inbound ports, so there is nothing at the branch for a scanner to find.

No shared keys to manage

IPsec meshes run on pre-shared keys or certificates. A key reused across branches means one leaked configuration backup exposes the whole mesh; certificates fix that but bring renewals and the risk that one expired certificate takes down dozens of tunnels. ZTNA uses short-lived credentials tied to your identity provider, revoked with one change.

Mergers and partners

Two companies that both use 192.168.1.0/24 cannot simply be joined with a tunnel. They need NAT on both sides or a renumbering project. ZTNA publishes applications by name, and the connector resolves the address inside its own network, so overlapping ranges stop mattering. The same logic applies to suppliers: instead of a tunnel into your network, the partner gets one application. Third-party access without VPN works through that pattern.

Decision matrix by scenario

The right answer depends on what crosses the link. This matrix covers the six situations mid-market teams ask about most.

Matrix based on the architecture patterns in NIST SP 800-207 and the MEF 70 SD-WAN service framework, and on practitioner reports from migrations.

If your sites fall in the second or fifth row, the quickest way to see the difference is to publish one internal application through ZTNA and keep the tunnel running alongside it. You can try Jimber free on a single site.

Operations and cost

Day to day, the two models fail in different ways and cost money in different places.

Packet size and frozen transfers

IPsec adds between roughly 50 and 73 bytes of headers to every packet, more with NAT traversal, which leaves a usable size of about 1,420 to 1,440 bytes inside the tunnel. When a full-size packet with the don't-fragment bit set hits that limit and a firewall drops the ICMP message that should report it, the result is the classic black hole: connections open, then large transfers hang. The fix is MSS clamping on every tunnel interface. ZTNA sessions run as ordinary TLS or QUIC connections, so the operating system's own TCP stack handles packet size and this class of fault does not occur for published applications.

Rekeying and failover

IPsec tunnels renegotiate keys on a schedule. Packet loss or a busy CPU during a rekey can leave both ends out of sync until dead peer detection rebuilds the tunnel, and branches on dynamic addresses need extra workarounds. ZTNA connections are outbound, and transports such as QUIC can move a session from fibre to 4G without a new login.

What you can see

An IPsec tunnel gives you flows: addresses, ports and volumes, which you then correlate with DHCP and directory logs to find a person. A ZTNA log records who connected, from which device, to which application. The trade-off is less hop-by-hop troubleshooting across the WAN.

Where the money goes

Site-to-site designs spend on hardware: a firewall or router at each site, often in pairs, annual support contracts, and sometimes MPLS circuits. A cloud platform moves that spend to a subscription, usually per user, and lets branches run on ordinary broadband with a lighter edge device. Which is cheaper depends on how many sites you have, how many users, and whether a refresh is due anyway. The savings are largest where expensive private circuits can go; the cost of leaving MPLS breaks that part down. Organisations replacing end-of-life branch firewalls, such as the Cisco Meraki MX64 and MX65, face the same calculation at refresh time, covered in Meraki MX end of support.

What NIS2 and CyFun expect around segmentation

Neither NIS2 nor CyFun names a technology. Both expect you to control which systems can reach which, to limit access to what is needed, and to show evidence of it.

Article 21 of NIS2 lists the measures in scope. Three of them bear directly on inter-site connectivity: supply chain security, which covers how partners reach your systems; policies on cryptography; and access control. A flat tunnel that gives a supplier or a branch broad reach into head office is hard to square with least privilege. Old IKEv1 tunnels with weak ciphers and shared keys are hard to square with a cryptography policy. Under Article 20, management bodies approve and oversee these measures and can be held liable for failures.

In Belgium, the CCB's CyberFundamentals framework turns those duties into controls, and certification against it gives a presumption of conformity with the Belgian NIS2 law, in force since 18 October 2024. CyFun's Protect function includes access control and network segregation. In an audit, that translates into concrete questions: which traffic is allowed between sites, who approved the rules, and where the logs are. An any-any rule across a site-to-site tunnel is an easy finding. Identity-based access logs that show exactly who reached which application are strong evidence. The VPN to ZTNA migration plan sets out how to move user access first and leave the infrastructure tunnel for last.

The case for keeping IPsec

An experienced network engineer will make three good arguments for the tunnel.

"IPsec carries anything at line rate." True. A tunnel does not care what is inside it, and firewalls with crypto acceleration encrypt at multi-gigabit speeds with negligible delay. ZTNA terminates sessions and checks identity, which costs time and processing. For bulk replication, large file transfers between sites and anything latency-sensitive, the tunnel is the better tool. That is why the hybrid design keeps it for exactly that traffic.

"A tunnel between my own firewalls depends on nobody." Also true. Keys, routes and policies sit on your own equipment, and a cloud broker or identity provider outage does not touch it. Moving inter-site traffic to a cloud platform adds a dependency, and that deserves a real answer: what happens to each application if the platform is unreachable. The answer for user access is usually acceptable, because users reaching SaaS already depend on the internet and their identity provider. For production traffic between machines it often is not, which again argues for keeping a narrow tunnel.

"Half my devices cannot run an agent." Cameras, printers, badge readers, building controllers and PLCs have no user and speak no web protocols. A tunnel reaches them by IP address with no extra parts. Forcing them behind ZTNA means jump hosts and reverse connectors. The engineer is right that the tunnel is the simplest tool here. The disagreement is only about the people: laptops, contractors and remote staff do have identities, and giving them a routed path into the network is the part that no longer makes sense.

Conclusion

ZTNA does not replace the site-to-site VPN. It replaces most of what the site-to-site VPN was being used for. Keep a narrow, tightly filtered tunnel or SD-WAN path for the machine-to-machine traffic that needs routing, and move every person, partner and acquired company to identity-based access. The tunnel gets smaller, the network stops being flat, and the internet-facing gateway loses most of its reasons to exist.

The choice also does not have to mean two vendors. Jimber covers SD-WAN between sites and ZTNA for users on one European platform, so the hybrid design runs from one console. Try Free with one site and one application, or book a demo to map which of your tunnels can shrink.

Frequently asked questions

Can ZTNA replace a site-to-site VPN?

Not completely. ZTNA replaces the tunnel for user-to-application access, partner access and most cloud application access. It cannot carry server-initiated traffic, broadcast-dependent services, domain controller replication, voice or most industrial protocols, which need a routed path. Most multi-site organisations end up with a hybrid design.

What is the main difference between ZTNA and a site-to-site VPN?

A site-to-site VPN joins two networks at layer 3, so devices on either side can reach each other unless rules block them. ZTNA connects a verified user on a checked device to one specific application at layer 7, while the network behind it stays invisible.

Why is a site-to-site VPN a security risk?

It creates a routed path between locations. If one device at a branch is compromised, an attacker can scan and attack systems at head office across the tunnel unless internal rules are strict. The gateway also has to accept connections from the internet, which makes it a target in its own right.

How does ZTNA prevent lateral movement between branches?

The user's device never receives an address on the target network. It can only reach the applications its user is entitled to, through brokered connections. Other subnets, servers and devices are not routable from that device, so scans and exploit attempts have nothing to reach.

What happens to printers and desk phones when moving to ZTNA?

They often break under a pure ZTNA design, because they rely on broadcast discovery, dynamic UDP ports and connections that start at the server. Keep them on separate, locally routed and filtered network segments, or move to cloud printing and a cloud phone system.

How do we keep Active Directory replication working without a full tunnel?

Either keep a narrow, route-based tunnel that only allows traffic between domain controllers on the required ports, or move the branches to cloud identity. Application connectors are not a reliable path for multi-master replication over dynamic RPC ports.

How does ZTNA handle overlapping IP address ranges?

Applications are published by name, and the connector resolves the address inside its own network. Two organisations can both use 10.1.1.0/24 internally without conflict, which avoids NAT on both sides or a renumbering project during a merger.

Does a ZTNA connector need open inbound ports?

No. A site-to-site gateway listens on UDP 500 and 4500. A ZTNA connector makes outbound encrypted connections to the broker, typically over port 443, so the site exposes no listening service for internet scanners to find.

Can SD-WAN replace ZTNA for branch security?

No. SD-WAN is a transport technology. It picks the best link and encrypts traffic between sites, but it still produces a routed network with the same lateral movement risk. It becomes a security design when combined with identity-based access, web security and firewalling in a SASE platform.

How do we give a maintenance supplier access to production systems without a tunnel?

Place a ZTNA connector next to a jump host in a separate zone. The supplier signs in with multi-factor authentication, reaches only that jump host through the broker, and manages the controllers from there. No network path exists between the supplier and the production network.