The problem with traditional VPN

When a user connects via a classic VPN (Virtual Private Network), they get a virtual network address directly on the corporate network — from the network's point of view, they're now "inside," the same as a computer physically sitting in the office. The problem is that a VPN typically grants access at the level of the entire network or a large segment of it, not to the specific application the user actually needs.

That means if an attacker steals VPN credentials or compromises a device connected via VPN, they gain potential access to a far broader set of systems than the original user was ever actually authorized for — a classic setup for lateral movement, an attacker's movement across a network after an initial breach.

The ZTNA principle: trust isn't granted to the network

ZTNA (Zero Trust Network Access) is an approach built on the Zero Trust philosophy — "never trust, always verify." Instead of connecting to the corporate network automatically implying trust, ZTNA verifies both the user's identity and the device's state on every single access to an individual application, and grants access only to that specific application — not to the network surrounding it.

VPN: access to the whole network User VPN gateway App A HR database File server Finance system everything visible and reachable ZTNA: access to 1 app only User ZTNA broker checks identity+device App A HR database File server Finance system everything else invisible
With a VPN, a connected device can see and potentially reach the entire internal network segment. With ZTNA, a broker mediates access — after verifying identity and device state, it permits a connection to exactly one specific application, while everything else stays invisible to the user (and to any attacker).

How it works in practice

Instead of connecting directly to the network, the user talks to a ZTNA broker (an access controller) — a central component that verifies, on every access request:

  • The user's identity — typically via a corporate identity provider with multi-factor authentication.
  • Device posture — is the operating system up to date, is antivirus running, is the disk encrypted, is the device on a list of known-compromised devices?
  • The context of the request — from which location, at what time, to which specific application.

Only after successful verification does the broker establish an encrypted connection directly between the user and the specific application — not with the network as a whole. Applications are also often not exposed to the public internet at all as such (so-called dark cloud) — they're visible only through the ZTNA broker, which eliminates the usual way attackers scan the internet looking for vulnerable, publicly reachable services.

Continuous verification, not a one-time login

A fundamental difference from VPN: with ZTNA, trust isn't granted once and for good at login — it's continuously verified throughout the entire session. If context changes during a session — for example, a device falls out of compliance, or the system detects suspicious behavior — access can be terminated immediately, with no need to wait for the next login.

Two deployment models

ModelHow it works
Service-initiated ZTNAA small connector deployed alongside the application initiates an outbound connection to the broker — on the user's side, often just a web browser is enough, with no client to install
Client-initiated ZTNAAn agent runs on the user's device, connecting to the broker and mediating access — requires installing software, but supports a wider range of application types

ZTNA as part of SASE

ZTNA is rarely deployed as a fully isolated technology — in most modern implementations, it's one of the core components of a broader SASE architecture, combined with other elements like CASB (cloud app control) or SWG (web traffic filtering) into a single, cloud-managed platform.

Why it's also better for users

Beyond the security benefits, ZTNA often delivers a better user experience than a traditional VPN too — connections are faster (no need to route all traffic through a central VPN concentrator), and many implementations work straight through the browser, with no separate VPN client to install and maintain.

Summary

ZTNA addresses a fundamental weakness of the traditional VPN — the fact that once connected, it trusts almost everything inside the network. By moving the trust decision from the network level down to the level of an individual application, continuously verifying identity and device state throughout the entire session, and hiding applications from the public internet, it significantly shrinks the attack surface and limits the damage a compromised account or device can cause. As part of the broader SASE architecture, ZTNA is increasingly replacing VPN as the standard way to remotely access corporate applications.