A colleague in Singapore needs a finance application in London, while a supplier in Germany needs one project portal. Giving both users the same route into your network creates unnecessary risk. For most distributed teams, the zero trust vs VPN decision is best made application by application: use zero trust network access (ZTNA) for secure remote access to a defined service, and retain a well-managed VPN where older systems still require network connectivity.
That choice depends on your applications, devices and support coverage across countries. Start by identifying what each person needs to reach, rather than choosing a replacement product first.
Key takeaways for distributed teams
- A VPN creates an encrypted connection, but the access behind it may be broader than a user needs.
- ZTNA can apply least privilege by limiting users to approved applications and using identity, device and context signals to make access decisions.
- Older systems may still need a VPN. A mixed estate is often more practical than an immediate switch.
- Test access from the countries where staff work, then review security, performance and support costs together.
Zero trust vs VPN: what changes in practice?
A business VPN, or virtual private network, connects a remote device to a private network through an encrypted tunnel. ZTNA brokers access to a particular application or resource under a defined policy. They support network security in different ways, but neither removes the need to secure accounts, devices and applications.
| Decision point | Traditional business VPN | ZTNA |
|---|---|---|
| Access granted | Usually a route to a network or subnet | Access to specified applications or resources |
| Trust decision | Often concentrated at connection time, with other controls applied separately | Policy can be evaluated for each access request and reassessed |
| Device checks | Possible, depending on the VPN and supporting tools | Commonly used as an input to access policy |
| Legacy compatibility | Useful for applications needing network-level connectivity | Depends on the product and application protocol |
| Traffic path | Can route through a central gateway | Can use a broker or connector closer to the application |
The deciding difference is reach: access control determines how much of the network a user can reach. If an accounts employee only needs one internal web application, granting a route to its wider subnet creates more access to manage and defend.
Where traditional VPNs create risk
VPNs remain useful security tools. The problem arises when a successful connection becomes an implicit reason to trust everything a user can reach. That can increase cyber risk as the threat landscape evolves.
Broad access increases the impact of compromise
A stolen password or compromised laptop can give an attacker the same network reach as its legitimate user. Multi-factor authentication (MFA) helps protect sign-in, but it doesn’t fix excessive permissions. Narrowly scoped access can reduce the attack surface, limiting the systems an attacker can probe for lateral movement.
The practical remedy is to restrict VPN users to the networks they need, segment sensitive systems and review access regularly. A ZTNA deployment can narrow reach further, provided its policies reflect actual job roles.
Gateways need maintenance and capacity
Internet-facing VPN gateways require patching, configuration review and monitoring. If traffic returns to one office through the VPN’s encrypted tunnel before reaching cloud services, hairpinning can add latency. It isn’t inevitable: routing, split-tunnel policy and gateway location determine the outcome.
For worldwide IT support teams, that means checking the real traffic path. A connection that works well in London may feel different to a colleague in Sydney using the same application.
How zero trust network access works
Zero trust is an architectural approach, while ZTNA is one way to apply it to remote access. NIST’s Zero Trust Architecture describes a security model where access decisions are based on a subject and resource, without granting implicit trust because a request comes from inside a network.
Verify the request, then limit its scope
A ZTNA policy can consider who the user is, which application they’re requesting and whether their device meets requirements. For example, a payroll administrator may receive access to the payroll service from a managed laptop, while a contractor receives access only to a project portal.
Continuous verification doesn’t mean asking for a password on every click. It means access remains subject to policy and can change when relevant signals change, such as a revoked account or a device falling out of compliance.
Limit movement between systems
Application-level policies and micro-segmentation reduce the resources available through a compromised account, shrinking the potential attack surface. If a user can reach only the approved service, lateral movement to neighbouring systems is harder after a successful sign-in.
This protection depends on configuration. Broad ZTNA policies can recreate the access problem they were meant to solve, and an exposed application still needs patching and monitoring.
Device posture depends on your endpoint controls
An identity check tells you which account requested access. It doesn’t tell you whether the laptop is encrypted, managed or missing updates. For international IT support teams, collecting that information consistently across devices matters as much as selecting an access broker.
Endpoint posture depends on your endpoint controls
Unified endpoint management (UEM) tools can report device compliance to an identity provider or access platform. Microsoft Intune and Jamf Pro are examples of tools organisations may use to manage different device fleets. Microsoft Entra ID can apply conditional access policies using supported identity and device signals.
Set requirements that staff can meet and support teams can verify. An out-of-date operating system might trigger restricted access or a remediation route; a lost device should lose access promptly. Endpoint posture is evidence, not a guarantee that an endpoint is safe.
Plan for exceptions before rollout
Shared workstations, contractor laptops and devices in newly acquired offices may not appear in your management platform. Unmanaged or non-compliant devices can increase the risk of lateral movement, so blocking them without a plan can interrupt operations, while allowing every exception indefinitely weakens the policy.
Record who owns each exception, what access they need and when it expires. Multi-country IT support also needs a clear process for restoring access when a compliant device is incorrectly blocked.
Global operations change the access decision
Security design has to work where people actually use it. A remote access service that’s reliable near your headquarters may perform poorly for an overnight team on another continent.
Measure application performance, not tunnel speed
Test sign-in, file transfers and application response times across locations used by remote workers in your hybrid workforce. Check endpoint posture too, including the device conditions required for access. Compare the current VPN route with the proposed ZTNA route for each important application. Also check what happens when an identity provider, regional gateway or application connector is unavailable.
For global technology support, these tests should include the hours when local staff work. A rollout that passes during the UK working day can still fail a team operating elsewhere.
Give local teams a clear recovery path
Account lockouts and device failures don’t wait for the London helpdesk to open. If multinational IT support spans several time zones, agree who can complete identity verification before restoring access, replace a device and approve an urgent access exception.
The same applies to IT support for international businesses using local suppliers. Balance local access needs with consistent safeguards to manage cyber risk. Give each supplier only the access its contract requires, and remove it when the work ends.
When should you keep a VPN?
Keep a VPN when a system needs network-level access that your proposed ZTNA service can’t reliably provide. Older client-server applications, specialist management tools and some non-web protocols may still need an encrypted tunnel. Test the actual workflow before deciding that an application is compatible.
A smaller, stable team may keep a VPN as an interim measure while improving MFA, endpoint management, segmentation and gateway maintenance. Document the risks, enforce least privilege to limit lateral movement, and don’t trust a VPN solely because it crosses the network perimeter. UK NCSC guidance recognises that a zero-trust architecture can retain VPN connectivity where it still has a purpose.
For IT support for multinational companies, a mixed model is often easier to operate than forcing every system through one product. Assign each VPN path an owner and a review date, so temporary access doesn’t become permanent by default.
A phased move away from broad VPN access
Migration works best when each change has a measurable outcome. Start with applications that are straightforward to identify and test, while keeping critical legacy connectivity in place until its replacement works.
- Map current access. List applications, users, service accounts, device types, countries of use and existing access control policies. Check what each VPN group can reach, not merely what its members say they use.
- Set the foundations. Confirm MFA, identity ownership, endpoint inventory and device-health signals through unified endpoint management. Ensure your security infrastructure supports these checks and reliable logging. Write separate policies for employees, administrators and third parties.
- Pilot a limited set of applications. Choose a suitable internal application and users in more than one region. Test access, latency, helpdesk recovery, logging, endpoint posture and the effect of a blocked device.
- Reduce VPN reach in stages. Move proven workflows to ZTNA, then remove the corresponding VPN permissions. This can reduce the attack surface and limit lateral movement. Retain and harden connections for systems that still need them. Review logs and user reports after every change.
Don’t switch off a tunnel just because users have a new sign-in page. Confirm that emergency access, administrative tasks and application dependencies work without the old route. Your remote IT support team needs a tested fallback for incidents, not an undocumented exception.
Compare costs and assurance, not licence labels
A VPN renewal and a ZTNA subscription rarely cover identical work, so compare total cost and cyber risk. Price the full service: identity licences, endpoint management, connectors, support hours, logging, deployment effort, legacy VPN capacity and cloud environments. Global IT services may also need regional support arrangements and coverage for local devices.
Check what your insurer or auditor asks for
A proposal to replace VPN doesn’t automatically satisfy a cyber insurance questionnaire or applicable compliance requirements. Requirements vary, so retain evidence of your security posture, including MFA, privileged-access controls, patching, monitoring and incident response. Describe the access model you actually operate, including any remaining VPN paths.
Make activity visible to responders
Confirm that sign-ins, policy denials, connector events and VPN activity feed the monitoring process. CISA’s Zero Trust Maturity Model Version 2.0 places identity, devices, networks, applications and data within the wider programme. Access technology is one part of your security infrastructure.
If your organisation uses external IT support services, agree who investigates a denied request and who investigates a suspicious successful one. Those need different responses, particularly if a successful sign-in may indicate data breaches.
Frequently asked questions
Does ZTNA replace every VPN?
No. Zero trust network access (ZTNA) suits applications that fit its access model, but some systems still need network connectivity. Keep those VPN paths restricted and monitored, then review them as applications change.
Does micro-segmentation stop lateral movement?
Micro-segmentation limits communication between systems, reducing the routes available after a compromise. It can’t guarantee attackers won’t move. Policy errors, excessive privileges and vulnerable applications still need attention.
What should a global team deploy first?
Start with an access inventory and MFA if either is missing. Then pilot ZTNA for a suitable application across several regions. Keep the VPN for untested workflows while measuring access, performance and support demand.
Choose access by application and risk
Across a distributed remote workforce, a colleague in Singapore and a supplier in Germany shouldn’t receive the same network reach simply because both work remotely. Restrict access to what each needs, and keep a VPN only where it provides connectivity you haven’t yet replaced.
If your organisation needs help assessing that mix, ask Zero Through for a security review of existing access paths, endpoint controls and monitoring before changing how staff connect.
