Your VPN Is a Flat Network You Dial Into. That Is the Whole Problem.

I once wrote about tearing down a flat datacenter network, the kind where every machine can reach every other machine and a single compromised host owns the building. I stand by all of it. Then I looked at how most companies grant remote access to their systems and realized we rebuilt the exact same mistake one layer up, gave it a login screen, and called it secure.

That is what a traditional VPN is. It checks who you are once, at the door, and then puts you on the internal network with the same reach as anyone else who made it through. From that moment, the only thing standing between you and every internal service is the fact that you connected. That is not access control. It is a flat network you dial into.

Table of contents

The short version

• A VPN grants network reach, not authorization. Once you are on, you can reach everything.
• That makes lateral movement trivial and the blast radius the entire network.
• Zero trust flips it: no implicit trust from being “on the network,” every connection verified per identity and per resource.
• The replacement is an identity-aware mesh plus an SSO provider, with access decided by policy, not by network location.
• The clearest proof it is better is offboarding: disable one identity and every path dies at once.

What a VPN actually gives you

Strip away the branding and a VPN does one thing: it extends the internal network to your laptop. After the handshake, your machine has an internal address and can send packets to internal hosts, the same as if you were plugged into a switch in the office.

Notice what that does not include. It does not check whether you should be talking to the finance database. It does not care that you are an engineer who only ever needs two services. It grants reach, and reach is the wrong unit. Authentication answered “who are you” once and then never asked “and should you be allowed to touch this specific thing,” which is the question that actually matters.

The flat network problem, again

The reason this feels familiar is that it is the same failure as the flat datacenter, moved up a level. In a flat L2 network, one foothold gives you the whole segment. On a flat VPN, one set of stolen credentials or one compromised laptop gives you the whole internal estate.

Lateral movement is the attacker’s favorite phase, and a flat network is a gift to it. You do not have to breach each service. You breach one thing, you are “inside,” and inside is a single open room. Everything I disliked about the unmanaged datacenter network is true here, except now the front door is on the public internet.

Zero trust, in one sentence

Never trust the network. Verify identity for every connection, and authorize it against the specific resource being reached.

The phrase gets overused to sell products, but the core is simple and it is mostly a mindset. The product matters less than the property: access is derived from identity and policy, not from being inside an address range. Being on the network means nothing. Every request has to prove who is making it and be checked against what that identity is allowed to reach. There is no “inside” to be safely within.

What replaced the VPN

The setup that replaced our tunnel had two parts. A self-hosted mesh control plane handled the connections themselves, point-to-point and encrypted between endpoints rather than everyone landing on a shared subnet. An SSO identity provider handled who you are, so identity came from one authoritative place, tied to the person and their device, not to a shared network credential.

Access then became policy instead of geography. You express who can reach what, and the mesh enforces it:

{
  "acls": [
    { "action": "accept", "src": ["group:platform"], "dst": ["tag:service-a:443"] },
    { "action": "accept", "src": ["group:oncall"],   "dst": ["tag:prod-db:5432"] }
  ]
}

An engineer in group:platform can reach service-a and nothing else implied by it. There is no flat subnet to wander around. Each allowed path is a specific, authenticated, encrypted connection, and everything not written down is denied by default.

Least privilege, for the network

This is the same idea as scoping an IAM role, applied to reachability. A person gets network access to exactly the resources their role needs, and not one host more. The engineer who needs two services can reach two services. The on-call who needs the database during an incident can reach the database, and that grant can be scoped and time-bound instead of permanent.

The offboarding test

If you want to know how good an access model really is, look at what happens when someone leaves.

With a VPN, offboarding is a chore with loose ends: revoke a certificate, rotate a shared secret, and hope nothing cached still works. With identity at the center, you disable the person in the SSO provider and every path they had collapses at once, because every connection was deriving its right to exist from that identity in real time. One switch, clean.

That single difference tells you which model actually knows who is on the network. One of them is guessing from a certificate it handed out months ago. The other one asks, every time.

Final takeaway

A VPN was a reasonable answer to a question we have outgrown. It made a remote machine act like a local one, which was useful when “the network” was a place you trusted and wanted to extend. But trusting the network is exactly the assumption that keeps burning us, in the datacenter and now in remote access.

The fix is not a better tunnel. It is to stop granting reach and start granting authorization, per identity, per resource, checked every time. Flat networks were a bad idea when they were made of switches. They did not get better because we wrapped one in encryption and pointed it at the internet.

Stop dialing into a flat network. Give people access to the specific things they need, verify it on every connection, and let “being on the network” finally mean nothing at all.