Secure Remote Access: When VPN Is Enough and When to Move to ZTNA

Start with one question

If one accountant's VPN password leaked today, what could the person holding it reach?

In most organizations we audit, the answer is "nearly everything": the file server, the ERP, switch admin pages, the CCTV NVR. A traditional VPN puts the user's device on the network, and access rules tend to be forgotten. RDP exposed directly to the internet is worse still.

How VPN works, and where it's weak

A remote-access VPN (IPsec or SSL VPN) builds an encrypted tunnel from the laptop to the company firewall. It's on almost every firewall, works with almost any application, and IT teams know it. It has three weaknesses:

1. Scope is too wide. Without group-based rules, users get whole subnets.
2. The gateway faces the internet. Unpatched VPN gateways have been one of the most common ransomware entry points for years.
3. It knows little about the device. Most VPNs check identity but can tell little about whether the connecting device runs EDR, is patched, or is an infected personal PC.

The second point is not theory. Through 2024 and 2025, remote-access gateways from several of the largest firewall vendors had serious flaws that attackers exploited, some of them before a patch was even available. Ransomware groups scan the internet for these login pages first. That means the VPN box needs the same patch discipline as your servers, with someone reading vendor advisories every week, not once a year.

A note for FortiGate owners

FortiOS 7.6.3 removed SSL VPN tunnel mode on every FortiGate model. Remote access now runs over IPsec VPN, which can use TCP port 443 so it still gets through hotel and mobile networks, and the old web mode lives on as "Agentless VPN". Tunnel-mode settings and their policies are not converted during the upgrade. Rebuild remote access as IPsec and test it with a few users before you upgrade, or your remote staff lose access the morning after.

What ZTNA changes

ZTNA (Zero Trust Network Access) does not put the device on the network. The user is connected to specific approved applications through a broker, and each session is decided on:

• User identity plus MFA
• Device posture: OS patched, EDR running, disk encrypted
• Context: country, time, risk level

Applications behind ZTNA usually have no inbound ports open to the internet, because an internal connector makes an outbound connection to the broker. How often posture is re-checked varies by product; some evaluate every request, others periodically. Ask the vendor.

Three ways ZTNA is delivered

None of them is automatically better. Cloud brokers are quick to roll out but every session depends on the vendor's service and your internet link. Firewall-based ZTNA keeps control in-house but you carry the patching, capacity and high availability yourself.

Before buying anything: fix the VPN you have

For most organizations these steps cut the most risk using equipment already on site:

• Close RDP and SSH exposed to the internet. Today.
• MFA on every VPN account, with no exemption for executives
• Current firmware, and someone subscribed to the vendor's security advisories
• Authentication through your directory (AD/Entra ID or RADIUS) instead of local accounts; unused accounts disabled
• Group-based rules: finance reaches the accounting system, engineers reach project servers
• Firewall admin interface not reachable from the internet
• Geo-IP limited to the countries staff actually work from (for example Laos and Thailand)
• Session timeouts and idle disconnects
• Login logs shipped to a log server, with alerts on repeated failures
• VPN user list reviewed with HR monthly

On split tunneling: sending only company traffic through the VPN saves bandwidth on the head-office line, which matters in Laos. But if you enable it, laptops need EDR and DNS/web filtering that work off-site, because their internet traffic no longer passes your firewall.

A quick calculation shows why this matters. Forty remote users on full tunnel, each on a video call at around 2–3 Mbps, push 80–120 Mbps through head office in both directions: in from the laptop, out to the meeting service, and back again. On a 100 Mbps business line that is the whole link, and the people in the office feel it first. Split tunnel for Microsoft 365 or Google Workspace traffic, with endpoint protection that works off-site, usually solves this.

When to start with ZTNA

Our view: for a 10–50 person office with a handful of internal apps and few remote staff, a VPN fixed along the lines above is usually enough for years. ZTNA earns its keep when:

• Many outside contractors or consultants need access to a few systems only (common at mines and construction projects)
• You have branches in several provinces and staff who travel
• You hold sensitive financial or customer data, as banks do
• Most of your applications are already web-based

Worked example: one company, several answers

Take a company with a Vientiane head office of about 80 people, a 25-person branch in the south and a project site with 15 staff and a handful of contractors. Today everyone uses one VPN profile that reaches the whole 10.10.0.0/16 network. After listing who needs what, the design usually ends up mixed:

Nothing here needs a big-bang project. The first and fourth rows are configuration on the firewall you already own. Only the second and third rows need a ZTNA product, and they can start with one application.

Migrating in phases

1. Pick one or two web applications (ERP, HR, intranet) and a pilot group.
2. Install the connector close to the apps and define group policies.
3. Integrate with EDR for device posture.
4. Move outside vendors onto ZTNA before staff, since that is where the risk is highest.
5. Add more apps, and shrink VPN to IT admins and special cases.

On latency: with cloud-delivered ZTNA, traffic from a province goes to the broker first and then back to the application. Choose a provider with a point of presence nearby (Bangkok or Singapore, for example) and test from a real branch before signing.

Mistakes we see often

• MFA that accepts any push. Attackers send prompt after prompt until a tired user taps approve. Use number matching or a hardware key for administrators.
• Old local accounts left on the firewall after moving login to the directory. They bypass MFA and nobody remembers them.
• One ZTNA connector. If the only connector VM reboots, every remote user is cut off. Run at least two, on different hosts.
• Treating ZTNA as endpoint protection. Posture checks read what the endpoint agent reports. Without EDR on the laptop there is little to check.
• Testing only from the office. Try from a 4G connection in a province and from a hotel network before you announce anything.

What changes in Lao conditions

Remote access is only as available as the head-office edge. If the firewall and the fibre ONT are not on a UPS, a brownout at 17:30 disconnects every remote user at once; see our UPS sizing guide. Many provincial offices run on a single ISP or a 4G router, so ZTNA connectors and VPN gateways should sit at the site with the best links, normally Vientiane, not at the branch. Staff who cross to Thailand often connect through Thai mobile networks, so plan Geo-IP rules for both countries rather than blocking everything outside Laos and then opening exceptions by phone.

Vendors who want remote access

ERP, CCTV and factory-equipment vendors often ask you to "just leave TeamViewer running" or for one VPN login their whole team shares. Don't. Give each person a named account with MFA, open only for the agreed window, with session recording. When the contract ends, disable the accounts the same day.

Send us the list

Write down who connects remotely (staff, branches, vendors) and which applications each of them really needs. We'll compare that with what your current VPN actually allows, and tell you which gaps can be closed with configuration and where ZTNA is worth it.