ZTNA vs VPN: Choosing Remote Access

If you are choosing how staff, contractors or you yourself should reach internal systems from outside the office, the ztna vs vpn question comes up quickly. Both approaches create a protected path to something private. The difference is what you are trusted with once you are on that path. A VPN usually trusts you with a network. ZTNA, short for zero trust network access, trusts you with one application at a time.

This article is a buyer-oriented comparison. It does not repeat the general idea of zero trust, which is covered in Zero Trust vs VPN. Instead it focuses on the practical choice: what each model grants, what it costs you to operate, a worked example, a checklist to decide, and a safe path if you want to move from one to the other.

The real difference: what you are given after you connect

Strip away the product names and the main difference is the unit of access.

With a traditional remote-access VPN, a user authenticates to a gateway and receives an address inside the private network, or a route into it. From that point their laptop behaves roughly as if it were plugged into the office switch. What they can actually reach is limited only by firewall rules that someone has written and maintained. In many small organisations those rules are broad, because broad rules are easy and rarely break anything.

With ZTNA, the user never joins the network. A client or browser talks to a broker, the broker checks identity, the state of the device and sometimes the time or location, and only then does it connect that user to one named application through a connector that sits next to the application. If the same person wants the file server as well, that is a separate decision. The private network stays invisible to everyone who is not approved for a specific service.

Two consequences follow:

• Blast radius. If a VPN account is stolen, the attacker lands inside the network and can scan it. If a ZTNA account is stolen, the attacker still gets only what that user was approved for, and device checks may block them entirely.
• Visibility. ZTNA logs show which user opened which application. VPN logs usually show that a user connected, and then you need firewall or server logs to learn what they did.

NIST describes this pattern in its zero trust architecture publication, where a policy decision point and a policy enforcement point sit between the user and each resource.

How a VPN grants access in practice

It helps to be concrete about the VPN side, because many of its weaknesses are operational rather than technical.

A typical setup has a gateway with a public address, a pool of internal addresses for remote users, and a firewall policy. The steps most teams follow look like this:

1. Create user accounts, usually linked to a directory.
2. Issue a client profile or certificate to each device.
3. Define which internal subnets remote users can reach.
4. Decide whether all traffic goes through the tunnel or only company traffic.
5. Review the rules when something breaks, and often not otherwise.

That last step is where trouble builds. A contractor who needed a database for two weeks is still allowed to reach it a year later because nobody wrote down an expiry. A developer's laptop that is full of old software still connects as long as the password works. A VPN is perfectly capable of enforcing narrow rules, but narrow rules need steady effort.

A VPN is also simple to reason about. One tunnel, one gateway, one place to look. Any application that speaks over IP works through it, including printers, old line-of-business software and file shares that expect to be on the same network. If you want a refresher on what the encrypted path itself is, see what a VPN tunnel is.

How ZTNA grants access in practice

ZTNA comes in two common shapes. In the agent-based shape, software on the laptop forwards requests for specific applications to the broker. In the agentless shape, the user opens a web portal in a browser and the broker proxies the application for them, which is handy for contractors on personal devices.

In both shapes, the flow is roughly:

1. The user signs in through the company identity provider, with multi-factor authentication.
2. The broker checks device posture, such as whether disk encryption and operating system updates are in place.
3. Policy decides whether this user, on this device, at this moment, may reach this application.
4. A short-lived, application-specific connection is created through a connector, so the application itself never needs an open inbound port.
5. The session is logged and can be ended centrally.

The attraction is that the application can be hidden from the internet without a VPN gateway having to be exposed. The cost is that someone has to write the policy per application, and applications that do not fit the model need a workaround.

Side-by-side comparison for buyers

Question	Traditional remote-access VPN	ZTNA
What does a user receive?	An address or route into the network	A connection to one approved application
Default posture	Trusted once connected, unless restricted	Denied until policy allows
Device health checks	Optional, often added later	Usually a core feature
Legacy and non-web protocols	Work well	Varies, some need connectors or are unsupported
Contractors on personal devices	Awkward, needs a client	Often possible through a browser portal
Ongoing effort	Low at first, grows as rules age	Higher at first, policy per application
Where the cost sits	Gateway hardware or virtual machine, admin time	Per-user service plus identity tooling
Visibility of user activity	Connection-level	Application-level
Single point of failure	The gateway	The broker service and your identity provider

Treat the last row seriously. ZTNA does not remove a single point of failure, it moves it. If your identity provider is down, nobody gets in, and a VPN with local accounts may still work.

A worked example: a 60-person company

Consider a design agency with 60 people. Thirty work from the office most days, twenty are fully remote and ten are freelancers who come and go. Their systems are a project tracker in the cloud, a file server in the office, an accounting application on a small server, and a remote desktop to two powerful rendering machines.

With a VPN only. Everyone gets a client. Remote staff reach the whole office subnet because the admin did not have time to split it. A freelancer's compromised home laptop can now see the file server, the accounting server and the printers. The admin's fix is to create three user groups and three firewall rules, which works but needs updating whenever a project starts or ends.

With ZTNA only. The project tracker is already in the cloud and is reached through normal sign-in. The accounting application and the rendering machines are published as named applications. Freelancers get access through a browser portal to only the project files they need, with a time limit. This works nicely until the team discovers that the file server uses a protocol the broker handles poorly, and a designer's backup software cannot reach it.

With both. The agency keeps a small VPN for the file server and its older tools, restricted to a small group on managed laptops. Everything else moves to named-application access. The VPN's rules are now few and easy to review, and the high-risk population, the freelancers, never touches it.

The example is not special. The mixed outcome is common because real organisations always have at least one application that does not fit neatly.

A checklist for deciding

Answer these questions honestly. The pattern of answers matters more than any single one.

1. Where do your applications live? If most are in the cloud or behind web interfaces, ZTNA fits naturally. If most are older desktop applications that expect a local network, a VPN is simpler.
2. Do you have a central identity provider with multi-factor authentication? ZTNA assumes you do. If you do not, fix that first, whichever access model you choose. CISA's guidance on multi-factor authentication is a good starting point.
3. Can you describe each user's job in terms of applications? If you can list roughly which five tools each team needs, per-application policy is realistic. If no one knows, you will end up granting everything anyway.
4. Who are your riskiest users? Contractors, vendors and staff on unmanaged devices benefit most from narrow access.
5. How many admin hours per month can you afford? ZTNA front-loads the work. A VPN spreads it out and then lets it rot.
6. What would a single stolen account cost you? If the answer is "very little, because everything is already separated", a VPN is probably fine. If the answer is "everything", prioritise narrower access.
7. Do you have compliance requirements for access reviews? Application-level logs make reviews easier.

If you answered mostly cloud, mostly web, good identity, and sensitive data, lean to ZTNA. If you answered older systems, small team, and one office server, a well-run VPN is a respectable choice.

Moving from a VPN toward ZTNA without breaking work

A forced cutover is the fastest way to lock everyone out on a Monday morning. A phased path is calmer.

1. Inventory. List every internal application, the protocol it uses and who needs it. This list is the most valuable output of the whole project.
2. Tighten the VPN first. Replace broad subnet access with groups. Remove accounts that no longer map to a person. This step lowers risk immediately and prepares the policy you will reuse.
3. Pilot with a low-risk application. Publish one web-based application through ZTNA and have one team use it for a month.
4. Move contractors first. They are the biggest risk and the easiest to give browser-based access.
5. Move the rest by application family, keeping the VPN for anything that fails testing.
6. Review every quarter. Remove stale policies. Policy that nobody reviews rots just as firewall rules do.

The CISA Zero Trust Maturity Model is useful for judging where you are along this path, because it describes stages rather than demanding a single leap.

Limits and mistakes to avoid

ZTNA is not a magic label. Watch for these:

• Buying the product and keeping the broad rules. If every user is approved for every application, you have a VPN with a new name.
• Ignoring non-web traffic. Voice, discovery protocols, server-initiated connections and some database tools do not always pass through a broker.
• Single dependency on identity. Plan an emergency access method for administrators, and protect it carefully.
• Forgetting the endpoint. A hijacked laptop that already holds a valid session can still use the applications it is approved for. Device checks and short sessions reduce that, but they do not remove it.
• Treating ZTNA as a privacy tool. It protects applications from unapproved users. It does not hide your browsing from your employer's broker, which can log your activity.
• Underestimating latency. Traffic goes to a broker before it reaches the application. If the nearest broker point is far away, users notice.

Equally, VPN mistakes remain familiar: one shared account for a whole team, no expiry on contractor access, and gateways that are never patched. NIST's telework security guidance lists good habits for either approach.

Where individuals and small teams fit

If you are one person, a freelancer or a family, you do not have an access-control problem of this kind. You probably want a VPN to protect traffic on public or shared networks, which is a different job from either ZTNA or a company gateway. The comparison in business VPN vs personal VPN explains the split, and what small businesses should look for covers the middle ground. If you work remotely and your employer already provides access, the remote work guide shows how a personal VPN can sit alongside it without interfering.

Summary

ZTNA and a traditional VPN differ in what they trust you with: a VPN gives a network path, ZTNA gives a verified connection to one application. ZTNA narrows damage from stolen accounts and gives better visibility, but it needs good identity, per-application policy and a plan for legacy protocols. A VPN is simpler and handles older systems well, but rules need regular review. Many organisations sensibly run both while they migrate.

If what you need is a simple personal VPN for your own devices rather than a company access system, you can look at the pricing page at your own pace.