ZTNA vs VPN: Is the VPN Dying?

You may have seen this question quite often lately:

“ZTNA is replacing VPN. Is traditional VPN finally dying?”

At first, it sounds reasonable. Organizations are moving applications to SaaS and public cloud, users are working from anywhere, and security teams want more control than simply putting a remote device on the corporate network.

But there is a problem with saying “ZTNA replaces VPN.”

VPN and ZTNA solve related problems, but they don’t work in exactly the same way.

A traditional remote-access VPN creates an encrypted connection between a user’s device and the corporate network. ZTNA takes a different approach: instead of giving the user network access, it tries to give the user access only to the specific application or resource they are authorized to use.

NIST describes Zero Trust as a model where access isn’t automatically trusted based on network location. Authentication and authorization are performed before access to a resource is established, with the focus placed on protecting resources rather than simply protecting network segments.

So the better question isn’t:

ZTNA or VPN?

It is:

Where does each technology make sense?

Let’s look at it from a network engineer’s point of view.

How Traditional VPN Works

Let’s start with something we already know.

Suppose an employee is working from home and needs to access an internal application:

Remote User
    |
    | Encrypted VPN Tunnel
    |
Internet
    |
    v
VPN Gateway / Firewall
    |
    +---- Internal Network
    |
    +---- Application Server

The user starts the VPN client, authenticates, and the VPN gateway establishes an encrypted tunnel.

Depending on the configuration, the user may receive an internal IP address and routes to one or more corporate networks.

For example:

User:        10.10.50.25
VPN Gateway: 10.10.50.1

Internal LAN: 10.20.0.0/16
Server:       10.20.10.50

The user can now reach the server through the VPN.

This is one of the biggest strengths of VPN: it provides network connectivity.

And that’s also where one of its limitations can appear.

If the VPN policy gives the user access to a large network range, the user may be able to reach more resources than the application they originally needed.

That doesn’t mean every VPN automatically provides unrestricted network access. Good firewall policies, segmentation, ACLs and routing can restrict it.

But the underlying model is still network connectivity.

What Changes With ZTNA?

Now consider the same employee accessing an internal HR application.

With ZTNA, the user doesn’t necessarily get an IP address on the corporate network.

Instead, the access decision can look something like this:

User
 |
 | Authenticate
 v
Identity Provider
 |
 | User + Device + Context
 v
ZTNA Policy
 |
 | "Is this user allowed to access HR App?"
 v
HR Application

The important difference is what the user gets access to.

With VPN:

User → Corporate Network → Application

With ZTNA:

User → Authorized Application

The network itself doesn’t have to become available to the user.

Current ZTNA implementations commonly use information such as user identity, device posture, location and other context to make access decisions. The goal is least-privilege access to specific applications rather than broad network access.

This is much closer to the Zero Trust idea described by NIST: don’t assume trust just because a user or device is coming from an approved network.

ZTNA vs VPN: What Is Actually Different?

Here is the simplest way to think about the difference.

The exact behavior depends on the product and architecture. Modern VPN platforms can also support MFA, device checks, segmentation and detailed policies. Likewise, not every ZTNA product provides exactly the same controls.

So we shouldn’t compare an old VPN configuration with a modern ZTNA platform and assume every VPN works that way.

Why Are Organizations Moving Toward ZTNA?

There are a few practical reasons.

1. Applications Are No Longer Only Inside the Data Center

A few years ago, a typical enterprise application might look like this:

User
 |
VPN
 |
Corporate Data Center
 |
Application

Today it could be:

             +-- SaaS
             |
User --------+-- Public Cloud
             |
             +-- Private Data Center
             |
             +-- Multiple Clouds

The user may need access to Salesforce, Microsoft 365, an internal web application, an AWS workload and an application hosted in a private data center.

Sending everything through a traditional VPN concentrator at the corporate data center isn’t always the cleanest architecture.

NIST’s recent Zero Trust implementation guidance specifically addresses environments where enterprise resources are distributed across on-premises and multiple cloud environments.

2. Users Don’t Always Need Network Access

This is probably the strongest argument for ZTNA.

Imagine an employee only needs access to:

https://hr.company.com

Why should that employee need access to:

10.10.0.0/16
10.20.0.0/16
10.30.0.0/16

just to open one application?

ZTNA tries to solve this by creating an access path specifically for the application.

This reduces the amount of internal network exposure.

Cisco describes the difference similarly: VPN commonly connects users to a network segment, while ZTNA connects users to specific applications and uses identity and context in the access decision.

3. A Compromised VPN Account Can Be a Bigger Problem

Let’s take a simple example.

An attacker obtains a valid employee VPN credential.

If the VPN provides broad access to internal networks, the attacker may now have network-level reachability.

The attacker still has to bypass firewall rules, authentication and other controls, but the initial foothold can expose a larger attack surface.

With ZTNA, the goal is different:

Compromised Identity
       |
       v
ZTNA Policy
       |
       +---- HR App       → Allowed
       |
       +---- Finance App  → Denied
       |
       +---- Server VLAN  → No Access

That application-level approach can reduce lateral movement opportunities.

NIST describes Zero Trust as an architecture designed to protect resources and limit internal lateral movement by minimizing access to only the resources a subject actually needs.

But remember something important:

ZTNA doesn’t make compromised credentials harmless.

If an attacker compromises an identity that legitimately has access to a sensitive application, ZTNA still needs strong identity controls, MFA, device security, monitoring and appropriate policies.

So, Is VPN Actually Dying?

Not exactly.

This is where many ZTNA articles become too simplistic.

VPN is still useful when you need network-level connectivity.

Consider a few examples.

Site-to-Site IPsec VPN

Suppose you have:

Office A
10.10.10.0/24
      |
   IPsec VPN
      |
Office B
10.20.20.0/24

You want systems in both networks to communicate.

This is a classic IPsec VPN use case.

ZTNA isn’t simply a drop-in replacement for this requirement.

The same applies to many network-to-network connectivity scenarios involving branches, data centers, cloud networks and infrastructure.

Network Administration

An engineer may need SSH, RDP, database access, network management protocols or other infrastructure connectivity.

Whether ZTNA is suitable depends heavily on the product and architecture.

Some modern ZTNA platforms support protocols beyond traditional web applications, including SSH and RDP, but this is product-specific.

Legacy Applications

Some older applications were designed with the assumption that the client is already inside the network.

Replacing that connectivity model may require application changes or additional access infrastructure.

In such environments, VPN may remain practical.

What About VPN Performance?

Another reason organizations look at ZTNA is traffic flow.

Imagine a user in India accessing a SaaS application hosted in Singapore.

With a traditional VPN architecture, traffic could potentially look like:

User
 |
Internet
 |
VPN Gateway - Corporate DC
 |
Internet
 |
SaaS Application

The traffic has been forced through the corporate environment.

This can introduce additional latency and consume VPN gateway capacity.

This is commonly called backhauling or tromboning, depending on the architecture.

A ZTNA design can instead establish access closer to the user and application, depending on the provider and deployment model.

But again, don’t assume ZTNA automatically means faster.

The actual performance depends on:

• User location
• Application location
• ZTNA service architecture
• Internet path
• Inspection services
• Provider PoP locations
• Encryption overhead
• Endpoint performance

The architecture matters more than the product label.

Does ZTNA Replace the VPN Firewall?

No.

This is another common misunderstanding.

A company moving to ZTNA doesn’t suddenly stop needing firewalls.

You may still need firewalls for:

• Internet edge security
• Data center segmentation
• East-west traffic control
• Site-to-site VPNs
• Cloud network security
• NAT
• IPS
• Application control
• Infrastructure protection

ZTNA changes how users access applications.

It doesn’t eliminate the need for network security controls.

In fact, NIST’s own ZTA lab architecture includes conventional firewalls, routing, IPsec VPN and remote-access VPN alongside Zero Trust technologies.

That’s a useful detail because it shows that Zero Trust isn’t necessarily:

“Remove the firewall and VPN.”

It is more about changing where and how trust decisions are made.

Can VPN and ZTNA Work Together?

Yes.

And in many environments, this is probably the most realistic transition path.

You don’t have to replace every VPN connection on day one.

For example:

                    Enterprise
                        |
          +-------------+-------------+
          |                           |
        ZTNA                          VPN
          |                           |
      User-to-App              Network Connectivity
          |                           |
   Internal Applications       Branch / Legacy / Admin

You could move normal employee application access to ZTNA while keeping VPN for workloads that genuinely require network-level connectivity.

There are also architectures where ZTNA capabilities are added around an existing VPN deployment during migration. Fortinet, for example, documents a ZTNA-over-VPN approach as a transition model rather than treating VPN and ZTNA as mutually exclusive technologies.

NIST’s 2025 implementation guidance also describes a transition from full-device VPN access toward more granular per-application tunneling, rather than assuming that organizations must replace everything immediately.

When Should You Consider ZTNA?

ZTNA becomes particularly interesting when your environment looks like this:

Users → Anywhere
Applications → Everywhere
Devices → Managed + Unmanaged
Identity → Centralized
Cloud → Multiple Providers

You may want to consider ZTNA when:

• Most remote users only need access to specific applications.
• Applications are spread across cloud and on-premises environments.
• You want identity-based access policies.
• Device posture is important.
• You want to reduce broad network exposure.
• You have many contractors or third parties requiring limited access.
• VPN backhauling is creating performance problems.
• You are working toward a broader Zero Trust architecture.

But don’t deploy ZTNA just because it is the newer acronym.

Start with the access requirement.

When Does VPN Still Make Sense?

VPN remains a practical choice when you need network connectivity rather than simply application access.

For example:

Site-to-Site Connectivity
        ↓
      IPsec
        ↓
Network-to-Network

or:

Engineer
   ↓
VPN
   ↓
Management Network
   ↓
SSH / RDP / Network Devices

VPN can also make sense where you already have a well-designed deployment with strong MFA, segmentation, logging, endpoint controls and restrictive firewall policies.

A poorly designed VPN can be risky.

But a poorly designed ZTNA deployment can also be risky.

The technology doesn’t replace good security architecture.

The Part Many Comparisons Miss

ZTNA and VPN aren’t really direct competitors at every layer.

A VPN is primarily a secure connectivity technology.

ZTNA is an access-control approach built around identity, context and least privilege.

In fact, some ZTNA products use encrypted tunnels underneath the application access model. So the real difference isn’t simply:

Encryption vs No Encryption

It’s more like:

VPN:
"Connect this device to this network."

ZTNA:
"Allow this identity, on this device, under this context,
to access this specific resource."

That is a much more useful way to understand the difference.

What Does the Future Look Like?

I don’t think the future is:

VPN → Dead
ZTNA → Everything

A more realistic enterprise environment looks like:

                    Security Architecture
                            |
          +-----------------+-----------------+
          |                 |                 |
         ZTNA              VPN             Firewall
          |                 |                 |
      User-to-App       Network Access   Network Security
          |                 |                 |
       SaaS/Apps      Branch/Legacy      Data Center/Cloud

Organizations will likely continue moving application access toward identity-centric and least-privilege models.

At the same time, VPN technology will continue to have valid use cases for network-to-network connectivity, legacy systems, infrastructure access and other scenarios where a secure network tunnel is actually what you need.

The transition may be gradual rather than a complete replacement.

And that is probably the most important point.

Final Takeaway

So, is the VPN dying?

For some remote-access use cases, traditional VPN architecture is being replaced by more granular application access models.

But VPN itself isn’t disappearing.

If you need to connect two networks, an IPsec VPN can still be exactly the right tool.

If an employee only needs access to one internal application, giving that user broad network connectivity through a VPN may no longer be the best design.

The real shift is from:

“How do I securely connect this user to my network?”

to:

“What does this user actually need to access, and under what conditions should I allow it?”

That is where ZTNA changes the conversation.

And for a network/security engineer, that’s probably a more useful way to look at the future of remote access than simply asking whether VPN is dead.

Sameer

Cybersecurity blogger with a focus on firewalls, network security, and tech trends making security simple for everyone, from IT pros to curious minds.