Your VPN works. People connect, the finance system loads, and nobody files a ticket. So when a vendor says “you should move to ZTNA”, the reasonable reaction is to ask what is actually wrong with the thing that works. The answer is not that VPNs are broken. It is that they were built to answer a different question.
What a VPN actually gives a user
A VPN builds an encrypted tunnel from a laptop to a gateway, and the laptop then behaves as if it were plugged into the office network. That is the whole design. The question it answers is “are you allowed onto the network?” Once the answer is yes, what you can reach is decided by whatever routing and firewall rules happen to sit behind the gateway.
In a tidy network those rules are tight. In most networks they are a decade of exceptions. Hence the usual complaint about VPNs: authentication happens once, at the door, and everything inside is treated as friendly.
What ZTNA does differently
ZTNA starts from the opposite assumption. NIST’s zero trust architecture (SP 800-207) describes zero trust as moving defences “from static, network-based perimeters to focus on users, assets, and resources”, and says no implicit trust is granted “based solely on their physical or network location”. CISA frames it as “least privilege per-request access decisions” on “a network viewed as compromised”.
Applied to remote access, that means:
- The unit of access is an application or resource, not a network.
- The decision is made per session or request, using identity and, usually, device condition.
- The user never gets a route to the rest of the network, so there is nothing nearby to wander into.
Microsoft’s documentation for Entra Private Access shows the shape of a typical implementation: you define the private resources, assign users and groups to an app, and use Conditional Access policies to control who gets in. A connector inside your network “brokers the connection”, and Microsoft documents the connector as making outbound connections only: it needs ports 80 and 443 open to outbound traffic.
That last detail matters more than it looks, and we come back to it below.
ZTNA and VPN side by side
| Traditional VPN | ZTNA | |
|---|---|---|
| Question answered | Can this user join the network? | Can this identity use this application, right now? |
| What a login opens | A network segment, often broad | The applications granted, and nothing else |
| Trust decision | Mostly once, at connection | Per session or request |
| Lateral movement after a stolen login | Easy if segmentation is weak | Limited to granted applications |
| Inbound exposure | VPN gateway listens on the internet | Depends on design: brokered designs use outbound connections only |
| Legacy and non-web protocols | Works with almost anything | Varies by product; check your protocols |
| Migration effort | Already running | Per-application work: inventory, policy, testing |
The last two rows are where honest comparisons are usually thin. ZTNA is not free. Someone has to list your applications and decide who should reach each one. That is also the most useful exercise in the whole project.
Where the real security difference sits
Two things separate the models in practice.
Blast radius. If an attacker steals a VPN credential, they inherit the network access that credential carries. If they steal a ZTNA credential, they inherit one identity’s list of applications. A short list is a small problem.
Exposure. A VPN gateway is, by definition, a listener on the internet that anyone can find and probe. CISA’s exposure guidance tells organisations to “close or restrict access to ports that do not have a documented operational need”, and notes that exposure reduction “does not mean disabling necessary remote access” — remove it when unnecessary, secure it when necessary. Designs where the protected side connects outward to a broker, as in the Microsoft connector model, remove the inbound listener from the picture. Not every product that uses the ZTNA label works that way, so this is worth asking directly.
Do you need to rip out the VPN?
Probably not on day one. A sensible order:
- List what people actually reach remotely. Applications, servers, databases, admin protocols. Be specific.
- Sort by risk. Administrative access (SSH, RDP, databases) is the highest-value target and the best first candidate for per-resource access.
- Check protocol support for each candidate product against that list. “Web apps only” is a legitimate answer for some products and a dealbreaker for others.
- Move the high-risk access first, keep the VPN for what is left, and shrink the VPN’s reach as applications move.
- Retire what has no remaining users. A gateway nobody uses is still a gateway somebody can attack.
Questions to ask any ZTNA vendor
- Does anything on my side listen for inbound connections from the internet?
- Which protocols are supported: web only, or SSH, RDP, databases and file transfer too?
- Is access decided per session, and can I see and end sessions?
- What happens to the access list when someone changes role or leaves?
- How much of this is configuration I own, and how much sits with you?
Where SSHepherd fits
If your remote access problem is mostly administrators reaching servers, SSHepherd® takes the brokered, outbound-only approach to that specific job. It closes the externally exposed listening port on the server; the server and the user each connect outbound to a broker, which joins them only for authorised identities. It works over SSH, RDP, databases, file transfer and applications, can protect a server in about ten minutes without re-architecting the network, and adds session monitoring, recording and a kill-switch. It is not a general web-application gateway, so treat it as one answer to the admin-access question rather than the whole programme. The SSHepherd page has the details, and our side-by-side comparisons set it against Zscaler ZPA, Cloudflare, Teleport and Twingate, sourced from each vendor’s own documentation.
The bottom line
A VPN decides whether you may join the network; ZTNA decides whether you may use one application. Move the riskiest access first, ask every vendor whether anything still listens on your side, and keep the VPN only as long as something still needs it.