For thirty years, network security worked like a castle. Build a strong wall around the network with firewalls and a VPN for the people outside, and treat everything inside the wall as trusted. Once you were in, you were in.
Zero trust starts from the opposite assumption: the attacker is already inside, or will be. So being on the network gets you nothing. Every request to every application has to prove who's making it, from what device, and whether they should be allowed, every time.
Where the idea came from
The concept is older than the buzzword.
- 2004: the Jericho Forum, a group of large-company security officers, argued that the network perimeter was dissolving and called for "de-perimeterisation." The term didn't catch on. The idea did.
- 2009: Operation Aurora. Chinese state hackers broke into Google and dozens of other companies through a single compromised employee machine and moved freely inside. Google's response was BeyondCorp: it stopped treating its corporate network as trusted at all, and put every internal application behind an access proxy that checks the user and the device. It published how it did it from 2014 on.
- 2010: the name. John Kindervag, then an analyst at Forrester, coined "zero trust" for this model.
- 2020: NIST SP 800-207 gave it a formal architecture.
- 2021–2022: the US government made it policy. Executive Order 14028 and OMB memo M-22-09 told federal agencies to reach specific zero trust goals by the end of fiscal 2024, which is this September.
Why this year makes the case
If you want an argument for zero trust in 2024, look at what's been happening to the castle walls.
- January: zero-day vulnerabilities in Ivanti's Connect Secure VPN were exploited widely, and CISA took the unusual step of ordering federal agencies to disconnect the devices entirely.
- February: Change Healthcare was ransomed after attackers logged into a remote access portal with a stolen password, on an account with no MFA.
- April: a critical flaw in Palo Alto Networks' GlobalProtect VPN gateways was exploited before a patch existed. The same month, Cisco disclosed that state-backed attackers had been breaching its ASA firewalls.
The pattern is the same each time. The device that guards the perimeter is itself exposed to the whole internet, it's complex, and when it falls, the attacker lands on a flat internal network where most things trust them. The wall is the attack surface.
What zero trust actually means
Strip away the marketing and it comes down to a few principles:
- Identity, not location, grants access. Being on the office network or the VPN proves nothing. A request is allowed because a verified user on a verified device is permitted to use that specific application.
- Check every request. Authentication isn't a one-time gate at the edge. Sessions are short, and access is re-evaluated when context changes: a new device, a new country, a device that's fallen out of compliance.
- Least privilege. People and services can reach only what they need. I wrote about that in its own right in the least privilege principle.
- Assume breach. Segment so that a compromised laptop or server can't reach everything else, log everything, and design so that one failure isn't total.
What it doesn't mean
Zero trust has become one of the most abused phrases in security marketing. Some correctives:
- It's not a product. No single appliance makes you zero trust, especially not one that's a VPN with a new name. Anything that promises it in a box is selling the box.
- It's not "trust nobody." It's "trust nothing by default, verify explicitly." The verification is the whole point.
- It's not finished in a quarter. For most organizations it's a multi-year migration, application by application.
What it looks like for a normal shop
You don't need Google's budget. The core pieces are now widely available, many of them open source:
- A single identity provider with strong MFA. Everything authenticates through it: Microsoft Entra, Okta, Google, or self-hosted with Keycloak or Authentik. Prefer phishing-resistant methods like FIDO2 security keys and passkeys over SMS codes and push approvals that people tap without thinking.
- An identity-aware proxy in front of internal web apps, instead of exposing them through a VPN. Cloudflare Access, Pomerium, Google's IAP, or Authentik's own proxy. Each request is checked against the identity provider before it reaches the application.
- A mesh, not a tunnel, for everything else. WireGuard-based tools like Tailscale, Headscale or NetBird give each device its own identity and enforce per-device access rules, rather than dropping everyone onto the same flat network.
- Device posture. At minimum, managed devices, disk encryption and current patches as a condition of access.
- Segmentation and logging. Firewall between workloads, not just at the edge, and keep authentication logs somewhere an attacker can't delete them.
A reasonable first project: pick the internal application your remote staff use most, put it behind an identity-aware proxy with MFA, and take it off the VPN. Then do the next one. When the VPN has nothing left behind it, turn it off.
There's a longer, more technical look at the architecture in my deep dive into the zero trust security model.
Since then
Added October 2026. The VPN appliance breaches never really stopped. Edge devices from Fortinet, Ivanti, Citrix, Cisco and Palo Alto stayed on CISA's list of known exploited vulnerabilities right through 2025, which is the best argument for this approach I could have asked for.