Why Your VPN Is About to Get Weird

The corporate VPN stands as the longest running piece of security theater in tech. It was invented in 1996 to give remote workers the same network access they had at the office. It still mostly does that. It also still mostly does that badly.

For thirty years, the alternative was “do nothing” or “give up and put everything in the cloud.” Neither of those is quite right either. The thing that is finally replacing the VPN is not a single product. It is a stack of ideas, most of which are not new, that happen to work better now than they did five years ago.

What the VPN is actually doing

A traditional VPN takes the user, encrypts their traffic, sends it through a tunnel, and lands them on the corporate network as if they were physically there. Once on the network, the user can reach internal services the same way the office employee can.

That model made sense when the office was the source of truth. The file server was in the office. The HR system was in the office. The development environment was in the office. The VPN was a remote office.

None of that is true anymore. The file server is in S3. The HR system is in Workday. The dev environment is in a Kubernetes cluster running on a hyperscaler. The office is a place you go to be on video calls.

So the VPN is a tunnel that lands you on a network where almost nothing you actually need lives.

What is replacing it

The buzzword is “zero trust.” The reality is more boring. It is a set of small, specific decisions about how to authenticate and authorize access to specific resources, regardless of where the user is or what network they are on.

Identity Aware proxies

Instead of putting the user on a network and letting them reach anything, you put a proxy in front of every internal service. The proxy checks the user’s identity, the device’s posture, and the request itself. The user never touches the underlying network.

Cloudflare Access, Tailscale, Twingate, Netskope, Zscaler. The list is long and the products overlap. The core idea amounts to the same: do not put the user on a network. Just let them reach the specific thing they need.

BeyondCorp

Google published a paper in 2014 describing how they removed VPN from their internal network. The paper sat on the shelf for years because the tooling was not there. The tooling is there now, and “BeyondCorp” has become a generic term for the model: trust the device and the identity, not the network.

SSH and WireGuard

For developers, the truth is that most “VPN access” was a workaround for “I need to SSH into a box.” A WireGuard mesh, a bastion host, or just decent SSH key management does that better than a full VPN client. This stands as the boring, unsexy answer that is increasingly the right one.

Browser isolation

For the case of “I need to look at one internal web app and that is it,” running the browser in a remote container is sometimes the right answer. The user never touches the actual internal system. They look at a rendered picture of it.

What is still hard

This is not a one way trip. There are real things the VPN did that the replacements do not all handle well yet.

• Legacy apps. The 1998 file server that only listens on internal IPs and refuses to authenticate against anything modern. The VPN made it accessible. Replacing it with an identity aware proxy requires touching the app, which requires the app to exist in a form someone can touch.
• Network Level tools. Wireshark, nmap, anything that needs raw network access. The proxy model does not give you a network. It gives you specific resources.
• Compliance theater. Some auditors still want to see “VPN access is logged” on a checklist. That is changing, but slowly.
• Mobile and unmanaged devices. The “trust the device” model works if you can manage the device. It gets harder when the device is a contractor’s laptop, a BYOD phone, or a personal iPad.

What to do about it (if you are a company)

1. Inventory what people actually use the VPN for. Most companies will find that 80% of VPN usage is one of three or four specific services. Those are the candidates for the proxy model.
2. Pick one identity aware proxy and pilot it on one service. Do not try to replace the VPN everywhere at once. Pick the least sensitive, most painful thing to VPN into, and put a proxy in front of it.
3. Adopt device trust explicitly. A managed device gets more access than an unmanaged one. Make this a policy, not a hope. MDM, posture checks, attestation. None of this is exotic in 2026.
4. Plan to keep the VPN around for the long tail. It will be there for years, used by a shrinking minority. That is fine. The goal is not to delete the VPN. The goal is to make it the exception, not the default.

What to do about it (if you are an end user)

1. Stop using personal VPN services for “security.” A consumer VPN moves your traffic from your ISP to a VPN provider. It does not make you anonymous, and it does not protect you from anything your ISP was actually going to do. The marketing is louder than the security.
2. Use a real password manager and MFA on every account that matters. The VPN was not protecting you from the actual risks. The password manager is.
3. Push back on the VPN requirement for things that do not need it. If a service is in the cloud and authenticates against your SSO, you do not need to be on the corporate network to use it. The VPN requirement is usually someone else’s assumption, not a real need.

The bottom line

The corporate VPN is not dead. It is just no longer the center of the security model. The companies that are getting this right are treating network access as one input among many, layering identity, device trust, and per resource authorization on top of whatever transport happens to be in use.

The thing that finally killed the VPN was not a better VPN. It was the cloud, which made the network irrelevant, and identity systems, which made the network unnecessary. The replacements are not as clean as the marketing suggests, but they are better than the thing they are replacing.