Replace VPN with ZTNA: the safer approach for hybrid working

Why VPN has become a security risk

VPN architectures rest on a simple assumption: anyone who can establish a tunnel into the corporate network is trusted to operate inside it. That assumption fails in four concrete ways in modern environments.

Lateral movement. Once an attacker compromises a VPN credential (phishing, credential stuffing, malware on the endpoint), they have network-level access. From that foothold, lateral movement to sensitive systems is largely unimpeded because the perimeter trusted them in.

Over-broad access. VPNs grant access to network segments, not to specific applications. A user who needs one application gets visibility into everything in their subnet. The minimum privilege principle is structurally absent.

Performance and scale. VPN concentrators are physical or virtual bottlenecks. As the hybrid workforce grew, organisations stacked appliances and added complexity to scale. Performance degrades, support load increases.

Audit invisibility. VPN logs typically show successful connections, not what was done within the session. An auditor asking "what applications did contractor X access yesterday?" gets imprecise answers at best.

How ZTNA works: least privilege, continuous verification and device posture

ZTNA inverts the VPN model. Instead of granting network access, ZTNA grants application access. The user authenticates, the platform evaluates context, the platform creates a scoped, time-bound, application-specific connection. Everything else stays invisible.

The technical building blocks are identity, context and posture. Identity means strong authentication, typically including MFA and integration with the corporate identity provider. Context includes location, time of day, request pattern and behaviour baseline. Posture means real-time verification of the device: OS version, patch level, endpoint protection status, certificate validity.

If any factor changes mid-session (device posture degrades, behaviour deviates from baseline, location shifts unexpectedly), the access decision is re-evaluated. Sessions that started valid can be revoked dynamically.

Universal ZTNA from Cato: one policy for everyone, everywhere

Most ZTNA products are bolted onto an existing infrastructure: a separate gateway, a separate policy engine, a separate client. Universal ZTNA on the Cato SASE platform is different. It runs as a native capability on the same cloud-native platform that delivers SD-WAN, SSE and AI Security.

The practical implications matter. One policy engine means a single policy framework for office workers, remote workers, contractors, suppliers and machine identities. One client (or clientless via browser for unmanaged devices) means lower endpoint complexity. One audit trail means all access decisions, regardless of user category, land in the same data store.

For organisations that have been managing three separate access regimes (VPN for employees, separate portal for contractors, federated access for partners), Universal ZTNA collapses that into one operational model.

BYOD and contractors: the forgotten attack vector

Most VPN architectures handle managed devices reasonably well. Where they fail is BYOD and contractors: personal phones, contractor laptops, supplier engineer workstations. Either they get the same network access as managed devices (a real risk) or they get a clunky separate portal that pushes users to workarounds.

ZTNA handles this gracefully. Posture checks differentiate managed from unmanaged devices in real time; policies adjust access scope accordingly. A contractor on an unmanaged laptop can access the project file share read-only without VPN; the corporate engineer on a managed laptop gets full access plus other resources. Same policy framework, different evaluation outcomes.

This is also where NIS2's supply chain security obligation becomes concrete. ZTNA produces the evidence supervisors expect: which supplier, accessing what, when, with what device posture.

ZTNA and NIS2: demonstrable access control for auditors

NIS2 Article 21 requires access control and identity management. The supervisor expects evidence, not policies on paper. ZTNA generates that evidence as a byproduct of normal operations: every access decision logged with identity, device, context and policy reference.

For compliance reporting, this is the difference between a multi-week evidence-gathering exercise across twelve tools and a console export. We unpack the broader NIS2 compliance story in our article on NIS2 and SASE.

Migration: parallel operation, then VPN retirement

A pragmatic ZTNA migration runs VPN and ZTNA in parallel for three to six months. High-value applications move to ZTNA first; the support team monitors user experience and refines policies. Once the first set of applications is stable on ZTNA, the next set follows. VPN retirement comes when application coverage is complete.

The Cato implementation pattern reflects this: Universal ZTNA activates without immediately disabling the legacy VPN. Customers control the migration timeline based on their operational readiness, not on a vendor cutover schedule.