Comparing traditional VPN, gateway-based ZTNA and SDP

This document sets out the technical differences between three common remote access architectures. The comparison table on the Merak product page is a summary of what follows; this version adds the reasoning behind each criterion and the limits of each approach.

1. The architectural models

Traditional VPN

A VPN establishes a tunnel at the network layer. Once a user authenticates they receive an internal address, and access control from that point onward is handled by firewall rules and network segmentation rather than by the authentication mechanism itself.

The VPN gateway needs a routable public address and an open port in order to accept connections. That address is visible to everyone, including requesters who have not authenticated.

Gateway-based ZTNA

ZTNA moves the control point up from the network layer to the application layer. Users no longer receive an internal address; instead a gateway proxies traffic for specific applications and checks identity and policy on each request.

Access granularity is therefore finer than a VPN. The gateway itself, however, still has to be publicly reachable, so a centralised public endpoint remains in the architecture — and all data traffic is relayed through it.

SDP (software-defined perimeter)

SDP separates the control plane from the data plane. The control plane handles authentication and policy authorisation; once authorisation completes, the data plane establishes an encrypted connection directly between client and service.

Protected services open no inbound port at all — a local node makes only outbound connections. A request that has not been authorised by the control plane receives no response whatsoever: the service is not refusing the connection, it does not appear to exist. The three roles this architecture defines, its single-packet authorisation mechanism and its limits are covered in software-defined perimeter (SDP): how it works.

2. Criterion by criterion

3. The reasoning behind each criterion

How attack surface should be measured

When comparing architectures, whether a port is open reflects real risk better than how many protection rules are configured. The first step for automated scanning is finding an address and port that answer. If that step returns nothing, the rest of the exploitation chain has nowhere to begin.

Both VPN and gateway-based ZTNA require a probeable endpoint, so both can be fingerprinted and added to a target list. What differs with SDP is that an unauthorised request gets no response at all, so reconnaissance fails at the first stage.

Why the data path matters for compliance

When traffic transits a gateway operated by a vendor, that vendor is technically capable of accessing it. In cross-border transfer assessments and in regulated industries, that capability becomes something you have to account for.

With the control plane separated from the data plane, the vendor participates only in the authentication and authorisation decision and is not on the data path. In compliance documentation this distinction usually matters more than any performance figure.

Access granularity and lateral movement

Once a VPN authenticates, what an attacker gains is a foothold inside the network. Subsequent movement is bounded by segment design rather than by identity. That is the structural reason a single stolen account can open the whole intranet.

Service-level microsegmentation binds policy to the combination of identity and service. When one identity is compromised, the reachable surface equals what that identity was already authorised for, and does not widen simply because the network was entered.

4. Limits of the approach

SDP is not the right answer everywhere. The following constraints belong in any evaluation:

• A node must be deployed on the endpoint or service side. Environments where nothing can be installed and no separate VM can be placed in front are not a fit.
• Control plane availability is on the critical path. Authorisation decisions depend on it, so its availability design has to be part of the architecture review.
• It does not replace application-layer authorisation. SDP decides whether a service can be reached; roles and data permissions inside the service remain the application’s responsibility.
• Existing monitoring may lose visibility. Point-to-point encryption means intermediate nodes cannot inspect traffic, so monitoring that relies on gateway-side inspection needs rethinking.

5. Common evaluation mistakes

Treating ZTNA and SDP as synonyms. ZTNA describes a principle of access control; SDP describes an implementation architecture. Most ZTNA products on the market are gateway-based, and the difference in data path is substantive.

Comparing feature lists rather than architectures. Both architectures can list “supports MFA” and “supports RBAC”, but where the control point sits determines the blast radius when something fails — and that never appears on a feature list.

Overlooking operational cost after deployment. The number of steps actually required to add a branch, change a permission or replace a device matters more over time than the initial adoption cost.

For the full technical specification version of this document, or an assessment written against a specific environment, please get in touch.