VPN or ZTNA? A Remote Access Security Guide for SMEs

What does an attacker see once a single employee’s VPN password gets stolen? In most setups, the answer is: everything. The file server, the accounting software, the camera system, the phone system. Once someone is inside the VPN tunnel, they’ve walked through a door that opens onto the entire network unless it was deliberately locked down. That’s not a misconfiguration; it’s how VPN is built to work.

The model gaining ground as a replacement is ZTNA, Zero Trust Network Access. The name sounds complicated but the logic is simple: a user gets the one application they need to do their job, not the whole network. An accountant sees the accounting software, not the file server. In this piece I’ll walk through the real difference between the two, when a given business should consider switching, and what the cost-versus-effort trade-off actually looks like.

Where VPN structurally breaks down

A VPN “virtually places” the user inside the company network. The moment the connection is up, the device behaves as part of that network and can see everything on it, whether it’s authorized to or not. Security here rests on a single checkpoint: authentication. If the password (and the MFA code, if you use one) checks out, the door swings all the way open. A compromised account leaves an attacker almost nothing standing between them and lateral movement across the network.

The second problem is performance. As cloud apps pile up (email, CRM, accounting, storage), routing all that traffic first through the head-office VPN box and back out to the internet adds a pointless detour. A user working from home who logs into a cloud CRM still has their traffic looping through the office, and the lag shows.

Where ZTNA actually differs

ZTNA runs on “verify first, then connect with the minimum privilege needed.” The user connects not to the network but directly to a single application; nothing outside that application ever enters their field of view. The access decision gets re-evaluated on every session, weighing signals like whether the device is patched, where the connection is coming from, and the user’s role. There’s no “I logged in once, so I’m free to roam” logic anywhere in the model.

	VPN	ZTNA
Access scope	Entire network	One application at a time
Trust model	Continuous trust after login	Re-verified on every request
Impact of a compromised account	Free movement across the network	Contained to that one application
Setup	VPN client + on-prem appliance	Cloud-based broker, clientless options exist
Cloud app performance	Traffic detours through HQ	Direct connection
Visibility/logging	Limited, session-level	Per-application, granular

The two models don’t have to be mutually exclusive. Some businesses keep VPN alive for older, not-cloud-friendly systems like a legacy file server while moving their SaaS apps over to ZTNA.

Which one makes sense for an SME

For a 20-30 person business I wouldn’t advise “move everything to ZTNA right now”; budget and effort need to stay realistic. Three questions are worth asking first.

1. How many people work remotely? If more than five people are regularly connecting from home or from a site, the VPN’s single-point risk grows, and that’s where ZTNA’s payoff shows up clearly.
2. What systems get accessed from outside? If it’s just one or two cloud-based apps (a CRM, say), you may not need a VPN at all: direct application login plus MFA can be enough on its own.
3. Is there a legacy, on-prem server involved? If your accounting or ERP software still runs on physical hardware, that system may still need a VPN or some hybrid setup; forcing everything into the cloud can cost more than the migration is worth.

On cost, ZTNA is usually sold as a per-user monthly license and doesn’t require buying hardware, which means a lower entry cost than a dedicated VPN appliance. But if your existing VPN box is already paid off and doing its job, “if it isn’t broken” is a legitimate answer too. Nobody has to migrate today.

How to actually migrate

Moving everything at once rarely works well. A staged approach does.

• Start with your two or three most critical applications (email and accounting access, say), move those to ZTNA, and leave VPN running for everything else.
• Tie device compliance checks (up-to-date OS, disk encryption on) to the access rule itself.
• Run the old VPN accounts alongside the new setup for two to three weeks and compare the access logs before switching them off.
• Define clearly who needs which application; “everyone gets everything” shouldn’t be the default.

Frequently asked questions

Do I have to shut down VPN completely once I adopt ZTNA? No. Most businesses run both side by side for a while, especially if legacy on-prem systems are still in the picture.

Is ZTNA overkill for a business with under 10 people? If the number of externally accessed systems is small and all of them are cloud-based, direct application login plus strong MFA is often enough without a separate ZTNA investment. The decision should hinge on how many systems get accessed from outside, not headcount.

How long does a ZTNA rollout take? For cloud-based products, getting the first few applications set up can take days. What actually takes time is correctly mapping out who needs access to what.

Does our existing firewall already offer ZTNA? Many modern firewall vendors (Sophos, Fortinet, Palo Alto among them) sell ZTNA as an add-on license. Checking what your current appliance supports is the first step, before shopping for something new.

If you want help mapping out who accesses what on your network, building a staged VPN-to-ZTNA migration plan, or assessing whether your current infrastructure is ready for it, get in touch and we’ll work out together whether it builds on your existing firewall or needs a separate solution.