Zero Trust Network Access: Moving Beyond VPNs

Zero Trust Network Access: Moving Beyond VPNs

Most organizations still rely on VPNs as the primary mechanism for remote access. That architecture was designed for a different era, one where the network perimeter was a meaningful boundary and most of the applications employees needed lived inside it. Neither of those conditions reliably holds anymore, and the security math that made VPNs a reasonable solution has shifted considerably.

The 2025 Verizon Data Breach Investigations Report found that attacks targeting edge devices and VPNs as initial access vectors increased from 3% to 22% year over year — a nearly eightfold jump in a single reporting period. The median time to remediate these vulnerabilities was 32 days, while the median time between vulnerability publication and mass exploitation by attackers was zero days. The architecture built to secure remote access has become one of the most actively targeted surfaces in enterprise environments.

Zero Trust Network Access takes a fundamentally different approach, and for many organizations, the gap between how they currently handle remote access and what ZTNA offers has become impossible to ignore.

What VPNs Actually Do — and Where That Falls Short

A VPN extends the corporate network to remote users. Once a user authenticates, they receive broad access to network resources, often far beyond what their role actually requires. That model made reasonable sense when most corporate applications lived on-premises and the threat landscape was different.

The problem is architectural. VPN grants access at the network level, not the application level. A compromised credential or a successfully exploited VPN vulnerability doesn't just expose one application — it exposes significant portions of the network that the legitimate user would have been able to reach. The 2025 DBIR found that credential abuse was the leading initial access vector in 22% of all breaches, and that 88% of basic web application attacks involved stolen credentials. In a VPN-centric environment, stolen credentials translate directly into broad network access.

The remediation challenge compounds the exposure. Tenable Research found that while 54% of organizations achieved full remediation of the 17 edge device CVEs featured in the DBIR, the average time to patch was 209 days — while attackers' average time to exploitation was five days. That gap is not a patch management failure in isolation. It reflects the structural difficulty of keeping internet-facing VPN infrastructure current when operational continuity concerns slow the patching process.

How ZTNA Works Differently

Gartner defines ZTNA as products and services that create an identity and context-based, logical access boundary between an enterprise user and an internally hosted application or set of applications. The applications are hidden from discovery, and access is restricted to verified users and devices. 

The distinction from VPN is structural, not cosmetic. Rather than authenticating once and receiving broad network access, ZTNA verifies identity and device health on a per-session basis and grants access only to the specific application the user is authorized to reach. The underlying network remains invisible to the user — there is no lateral movement opportunity because there is no network access being granted, only application access.

The practical security implications are significant. A compromised credential in a ZTNA environment provides access to the specific applications that credential was authorized to reach, with continuous verification throughout the session. It does not provide a foothold for lateral movement across the network.

Universal ZTNA: Extending Zero Trust Beyond Remote Workers

Most early ZTNA deployments focused exclusively on remote access — replacing VPN for employees working from home. That approach solved one part of the problem while leaving another unaddressed.

Most ZTNA solutions are cloud-based and focus on the remote worker use case. However, when employees returned to the office for at least a few days a week, IT leaders found they required two application access policies — one for remote users and one for in-office users. Having two access policies opens the door for errors and misconfigurations, as well as doubles the IT team's workload. 

Universal ZTNA addresses this by applying the same zero trust principles regardless of where a user is working — remote, in the office, or at a branch location. Policy is defined once and enforced consistently across all connection types, which eliminates the configuration drift that tends to accumulate when remote and on-premises access are governed separately.

Fortinet Universal ZTNA requires no additional licenses and is included as a feature in FortiOS and FortiClient, allowing organizations to shift from VPN to ZTNA at their own pace. For organizations already running FortiGate next-generation firewalls, the path to ZTNA enforcement doesn't require a separate platform purchase or a parallel infrastructure deployment — the capability is already present and can be activated incrementally.

Fortinet is the only vendor delivering ZTNA, SD-WAN, and enterprise-grade security integrated by a single operating system, with all three — SD-WAN for connectivity, ZTNA for secure access, and security for traffic inspection — configurable and managed from the same centralized console. For mid-market organizations that need to reduce vendor complexity and consolidate management overhead, that integration carries meaningful operational value.

The Migration Question: How to Move from VPN to ZTNA

The most common concern technology leadership raises about ZTNA is not whether the architecture is sound — it's how to migrate without disrupting operations. The answer is that it doesn't require a complete cutover.

Gartner recommends looking for scenarios in which targeted sets of users can be switched to work through ZTNA, as this approach provides immediate value in terms of improving overall security posture without requiring an all-or-nothing transition. Starting with specific user populations — contractors and third-party vendors are a common starting point, given the elevated risk associated with external access — allows organizations to validate the ZTNA deployment before extending it to the broader workforce.

Fortinet's approach supports this incremental path directly. Organizations can run VPN and ZTNA simultaneously through the same FortiClient agent, migrating user populations and application segments at whatever pace their operations support, without managing two separate access clients or two separate policy frameworks.

The evaluation questions worth working through before beginning a migration are practical ones: Which user populations represent the highest-risk access scenarios under the current VPN model? Which applications are most sensitive and would benefit most from per-session verification? What is the current device posture verification capability, and does it need to be established before ZTNA enrollment begins? The answers tend to identify a natural starting point that produces meaningful security improvement with manageable operational change.

The Broader Context

Gartner sees strong adoption of ZTNA among organizations with 5,000 to 25,000 users, and growing adoption among smaller organizations as well, with VPN replacement consistently cited as the primary motivation. The justification, Gartner notes, comes from risk reduction rather than cost savings — which is an accurate characterization of what ZTNA primarily delivers.

The shift in attacker behavior toward VPN and edge device exploitation is not a temporary trend. The vulnerability surface that VPN infrastructure presents, combined with the slow remediation cycles that operational requirements impose, makes it a structurally attractive target for both ransomware operators and espionage-motivated threat actors. Organizations that continue to operate purely VPN-centric remote access models are carrying risk that is increasingly well understood by the adversaries looking for entry points.

ZTNA doesn't eliminate all remote access risk, but it does remove the structural conditions that make VPN exploitation so rewarding for attackers — broad network access from a single compromised credential, invisible applications that can still be reached once a user is on the network, and a remediation window that consistently favors attackers.

For organizations already running Fortinet infrastructure, the path to ZTNA is shorter and less disruptive than most technology leadership teams expect. The capability is already there. The question is whether the current access model is still an acceptable risk.

For a broader look at perimeter security fundamentals and why traditional models fall short, our piece on next-gen firewalls covers the foundational context. If your distributed environment includes branch offices and you're thinking about SD-WAN security alongside ZTNA, our piece on SD-WAN security addresses how those two architectures complement each other.

Ready to assess your current remote access posture and evaluate a path to ZTNA? Talk to the Tricension team about what a migration looks like for your environment.