Most Thai organisations that opened up remote work after COVID still lean on SSL/IPsec VPN, even though the global cyber security industry declared the VPN "legacy" back in 2021. Gartner forecast that by 2025 70% of new remote-access deployments would use ZTNA rather than VPN (up from less than 10% in 2021). Now, in 2026, the real figure is probably close to that forecast.
VPN versus ZTNA — the picture in plain terms
If a VPN is the key to every room in the building — once you log in you have a route to every subnet the network policy allows — then ZTNA is a key that opens only the room you are entitled to at that moment, decided by identity plus device posture plus behaviour at that point in time.
| Dimension | Traditional VPN | ZTNA |
|---|---|---|
| Default behaviour | Allow the LAN, block the rest | Deny by default |
| Access scope | A whole subnet, or the whole LAN | One application, one session |
| Identity model | Username + password (+ MFA) | Identity + device + context + risk |
| Re-authentication | At the start of the session | Continuous, during the session |
| Lateral movement | Possible once credentials leak | Segmented — applications cannot see each other |
| Performance | Hub-and-spoke, added latency | Direct-to-app, lower latency |
A VPN trusts the user once they are through the front door. ZTNA trusts nobody, not even in the bedroom.
Why Cisco, Fortinet, Zscaler and Palo Alto are all pushing ZTNA
Each vendor has its own product name (Cisco Duo Network Gateway, Fortinet Universal ZTNA, Zscaler Private Access, Palo Alto Prisma Access) but the principles line up:
- Identity-aware proxy — the user never actually joins the network; they come in through a broker that checks who they are
- Device posture check — is EDR running, are patches current, is disk encryption on
- App-level segmentation — Marketing can open the CRM but cannot see the Finance file server, not even by ICMP
- Continuous evaluation — if a user starts downloading data in an unusual pattern, the session is downgraded or killed immediately
What to weigh before migrating
Having watched ZTNA migrations both succeed and fail, these are the points that are usually underestimated:
1. Legacy applications without modern auth
Plenty of older ERP, AS400 and accounting systems still bind straight to Active Directory over LDAP and do not speak SAML or OIDC. Some ZTNA gateways support legacy auth bridging, but it has to be configured carefully or it becomes a new hole of its own.
2. Third-party and contractor access
The old VPN habit was a guest VPN account with a 90-day life. The ZTNA-friendly approach is a separate guest IdP (Azure External ID, or Okta Workforce plus Customer Identity, for example) with time-bound provisioning per application — but many contractors are still used to GlobalProtect/AnyConnect, so change management matters as much as the technical setup.
3. Branch offices with a lot of on-prem applications
ZTNA from a SASE vendor (Zscaler, Cloudflare, Netskope) works well with SaaS, but if the main data centre is still on-prem you need a connector appliance in each branch, or traffic will travel halfway around the world and back.
4. The real cost is higher than the quotation
ZTNA licences are priced per user per month and are sometimes several times a VPN licence. The budget also has to include connector hardware, an observability stack, an identity provider upgrade and internal training. The real ROI usually comes from reduced breach cost, not from direct licence savings.
A migration strategy that actually works
Phased migration (recommended for Thai organisations)
- Months 1-2: run a ZTNA pilot on the 1-2 most sensitive applications (HRIS, finance ERP) for the executive team and IT admins
- Months 3-4: extend to back-office applications (HR portal, file share, ticketing) for every department
- Months 5-6: bring in third-party contractors and branch offices
- Months 7-12: decommission the old VPN concentrator, keeping it only as break-glass
Parallel operation
Run ZTNA and VPN side by side for 6-12 months and let users choose. It is far less disruptive, but the logs have to be analysed regularly so nobody quietly falls back to the VPN just to avoid configuring ZTNA.
The summary for decision makers
ZTNA is not "a newer, better VPN" as the marketing claims. It is a change to the organisation's trust model, and it requires:
- a strong identity provider (Azure AD/Entra ID or Okta, with MFA enforced for 100% of users)
- an asset inventory backed by a CMDB that is actually up to date
- a SOC team that reads identity and access logs every day
If those three are not in place, migrating to ZTNA produces the opposite of what was intended — less security, because policies get loosened until people can work again. So before signing the next PO, ask your own team: "if our IdP is down for 30 minutes, can staff still work?" If there is no answer, the foundation is not ready.