Rethinking remote access: Why zero trust network access replaces VPNs today

[Jaye_Tillson]

Learn how ZTNA fixes VPN shortcomings by granting app-specific access, verifying context, shrinking the attack surface, and improving security and user experience.

For a long time, VPN was synonymous with secure remote access. If you needed to access the corporate network from anywhere else, you fired up a client, typed in a password, and possibly tapped a token, and you were in. It felt like a neat solution to a simple problem.

However, the truth is that virtual private networks (VPNs) were never designed for the world we live in today. They started life solving a very different challenge, in a very different era. And while VPN technology has steadily improved, the underlying security model has stayed stubbornly the same.

That mismatch is why so many organizations are now moving toward zero trust network access (ZTNA) as the modern replacement.

Let’s take a quick journey through how we got here.

Where VPN started: A tunnel through an untrusted world

In the early days of enterprise networking, most corporate systems lived in a predictable place. The office. The data center. The private network. Users worked on managed devices, inside a building, behind a firewall, with the internet treated as something outside.

As businesses expanded globally and the internet became the default transport, a new requirement appeared: how do we connect sites and users securely over a network we do not control?

That’s the original promise of the VPN. Build an encrypted tunnel between two points, so traffic passing over the public internet can’t be read or tampered with. In other words, create privacy and integrity across an insecure medium.

This was hugely valuable.

It enabled site-to-site connectivity without leased lines. It supported early remote access use cases. It gave organizations a pragmatic way to extend private networking across public infrastructure.

And because the world was simpler, the model made sense. You authenticated the user, established a tunnel, and then treated them as inside.

That last part is the key. The VPN did not just provide encryption. It provided network membership.

How VPN became the remote user solution

As laptops became more and more common and business travel ramped up, VPNs took on a new identity: remote access for individuals. The classic image is an employee in a hotel or coffee shop connecting back to office.

Then broadband happened. Then Wi-Fi. Then smartphones. Then the cloud.

Slowly, the workplace stopped being a single place. But many security architectures still behaved as if it were.

So organizations leaned even harder on VPNs. It was the easiest way to give users access to internal apps, file shares, email, and, later, a growing pile of stuff that had never been designed for internet exposure.

VPNs became the universal adapter. If it ran on the corporate network, the VPN could reach it.

And when something becomes the universal adapter, it becomes the default answer. Need contractors to access a system? Give them a VPN. Need third parties to support an application? VPN. Need people to work from home occasionally? VPN.

In fairness, this worked. Until it didn’t.

The turning point: when remote became normal

The moment remote work shifted from edge case to operating model, VPN weaknesses stopped being theoretical.

The pandemic did not create new problems. It exposed old ones at scale.

Suddenly, you had a huge percentage of the workforce connecting from home networks, personal routers, shared devices, variable patch levels, and all sorts of inconsistent conditions. At the same time, application landscapes had changed. Many critical services were no longer sitting neatly inside the data center. They were in software as a service (SaaS), in public cloud, or split across environments.

VPNs can technically still connect you. But connecting is not the same as securing.

At this point, the question stopped being, can the user reach the network? and became, should this user be allowed to reach this specific application right now, from this device, under these conditions?

VPNs are not built to answer that question well.

How VPN became a risk

To understand why VPNs became such a risk, it helps to look at what they actually do.

A VPN creates a trusted path into a network. Once you are in, the network assumes you belong there. You can often see far more than you need, even if permissions later restrict what you can do.

This is the castle and moat mindset in remote access form.

That model breaks down in a modern threat landscape for a few reasons.

1) VPNs expand the attack surface

A VPN concentrator is an internet-facing gateway into your environment. That means it becomes a high-value target. If attackers can compromise it, they gain a direct route past perimeter controls.

We’ve seen repeated examples over the years where vulnerabilities in VPN appliances became entry points. Even when patched, the cycle is exhausting: discover vulnerability, scramble to patch, hope exploitation did not happen first, investigate, clean up, repeat.

It is not that VPN vendors are uniquely bad. It is that the VPN itself is a critical choke point, exposed to the internet, and therefore constantly attacked.

2) VPNs enable lateral movement

Once an attacker gets a foothold, VPN based access often provides a wide internal view. If credentials are stolen or a device is compromised, the VPN can turn a single compromised user into broad network access.

Attackers love this. It gives them room to move, to explore, to find the real prize. Domain controllers, file servers, sensitive apps, backup systems. The stuff that turns an incident into a crisis.

When you design access around the network, you unintentionally make the network the playground.

3) VPN access decisions are too static

Traditional VPN controls focus on authentication at the start of a session. After that, the session often lasts for hours. Sometimes days.

But risk is not static.

A device posture can change. A user can move location. A session can be hijacked. Credentials can be replayed. A good login at 9 a.m. does not guarantee a safe session at 3 p.m.

Modern security needs continuous assessment and adaptive policy. VPNs were not built for that, and bolting it on is usually clunky.

4) VPNs create friction for users and IT

Anyone who has supported VPN at scale knows the pain.

• Client issues
• Split tunnelling debates
• Latency and backhauling
• Capacity planning
• Hairpinning traffic to reach cloud apps
• Complex network routing
• Ticket volumes

VPNs often become a performance and productivity problem, which leads to risky workarounds. Users find alternate paths, IT teams create exceptions, and security posture slowly erodes.

When security gets in the way of work, work finds a way around security.

Why VPN is not fit for purpose in the hybrid world

The modern enterprise is not a single network anymore. It’s a mix of:

• SaaS applications users access directly over the internet
• Public cloud workloads
• Private data centers
• Branch and campus networks
• Mobile users on unmanaged networks
• Third parties and contractors
• Machine-to-machine traffic
• Application programming interfaces (APIs) and automation
  
  

In that world, the idea of connect to the network and then access what you need is backwards.

Users do not need access to networks. They need access to applications and services.

Also, security teams do not want to expand internal reach. They want to reduce it.

VPN assumes trust after authentication. Hybrid requires verification every step of the way.

Enter ZTNA: access to apps, not networks

ZTNA flips the model.

Instead of placing the user on the inside, ZTNA brokers a connection to a specific application. You authenticate the user and evaluate context, then grant access only to what the user is allowed to use.

No broad network access. No implicit trust. No once you’re in, you’re in.

That is a fundamentally different security posture.

ZTNA is built around a few core principles.

Verify explicitly

ZTNA treats every access request as a decision point. Identity matters, but so does device posture, location signals, risk scores, and policy. This aligns perfectly with a zero trust mindset: never assume, always verify.

Enforce least privilege

Users get access to specific apps, not the whole network. That immediately reduces the attack surface and limits lateral movement. If an attacker compromises a session, what they can reach is far smaller.

Assume breach

ZTNA designs as if compromise is already possible, which means you focus on containment by default. Segmentation and micro perimeters are not afterthoughts; they are the starting point.

Improve user experience

Done well, ZTNA can actually be easier for users. Access becomes more seamless, more consistent, and often faster, because traffic does not have to hairpin through a central VPN gateway to reach a cloud service. ZTNA can also reduce complexity for IT by shifting from network routing gymnastics to policy-driven access.

Why organizations are replacing VPN with ZTNA now

It’s tempting to say ZTNA is the future and leave it there. But the real reason organizations are moving now is more practical.

They are tired of the trade-offs.

• They want stronger security without crushing user experience
• They want to reduce exposure from internet-facing VPN gateways
• They want better visibility into who is accessing what
• They want a consistent policy across on-premises and cloud
• They want to support modern workstyles and third-party access safely
• They want to shrink the blast radius when something goes wrong
  
  

ZTNA is not just a new remote access tool. It is a shift from network-centric security to identity and application-centric security.

And it fits naturally into broader modern architectures like security service edge (SSE) and secure access service edge (SASE), where secure access, web security, cloud app controls, and threat protection come together under unified policy.

The takeaway: VPN solved yesterday’s problem

VPNs were a brilliant solution to a problem that mattered: how to extend private connectivity over an untrusted network. They enabled remote access long before anyone imagined a world of cloud-first, hybrid work, and constant credential theft.

But security models have to evolve with reality.

Today, the biggest risk is not the lack of encryption. It’s the assumption of trust.

In a hybrid world, connect to the network is no longer the goal. Secure access to the right resource, for the right user, under the right conditions, is the goal.

That’s why ZTNA is replacing VPN. Not because VPN is broken technology, but because it’s the wrong model for the job we’re trying to do now.

By Author:
Jaye Tillson,
CTO Security