What Zero Trust Really Means
Every vendor sells zero trust as a box you buy. It is a design principle, and the principle is that the network earns you nothing.
What you will learn
- -Strip the marketing off zero trust and state the actual principle
- -Map a request to the policy engine, administrator, and enforcement point
- -Explain why network location is a broken basis for trust
Every security vendor has a product now. , VPNs, badge readers, email gateways, all rebranded overnight with the same two words. So start here: zero trust is not a thing you buy. It is a design principle, and once the principle is clear the sales deck falls apart.
The principle fits in one sentence. Never trust, always verify. Unpacked, it means you stop granting access based on where a request comes from. Sitting on the corporate , riding the VPN tunnel, living inside the firewall: none of that earns trust. Every request to every resource gets authenticated and authorized on its own, every single time.
That is a direct rejection of the model most still run. The castle and moat: a hard perimeter, a soft trusted interior, and one assumption baked into everything, that "inside the network" means "allowed." The moment anything inside is compromised, and something always is, that assumption hands the attacker the whole interior for free. Zero trust deletes the assumption. Location tells you nothing.
The document that actually defines it
Skip the vendor whitepapers and read NIST SP 800-207. Published in 2020, it is the closest thing to a neutral definition, and it describes the machinery in three logical parts.
The engine decides. It takes a request plus signals about the user, device, and resource, and returns allow or deny. The policy carries out that decision, setting up or tearing down the session. The policy enforcement point is the thing in the data path that actually blocks or forwards the traffic. Engine and administrator together are the policy decision point, the brain; the enforcement point is the hands.
Every access follows the same loop. A request hits the enforcement point, the enforcement point asks the decision point, the decision point evaluates policy against live signals, and only then does traffic flow. No standing trust, no "you authenticated an hour ago so you are fine." The check happens per request.
You can watch the model in action with an -aware proxy in front of an internal app. No valid identity, no access, regardless of what network you are on.
$curl -s -o /dev/null -w '%{http_code}\n' https://app.internal.example$curl -s -o /dev/null -w '%{http_code}\n' -H "Authorization: Bearer $TOKEN" https://app.internal.exampleGoogle's BeyondCorp is the reference implementation of exactly this. They moved every internal app behind an access proxy, dropped the privileged corporate network entirely, and now an engineer on hotel wifi and one at a desk in Mountain View identical scrutiny. There is no "inside" to be on.
Poking at an access proxy, mapping what a can reach, or testing whether an app leaks past its enforcement point is active assessment. Do it against a lab you built or infrastructure you are explicitly cleared to test. A local setup with an OPA or Pomerium proxy in front of a dummy app teaches the whole loop without touching anything you do not own.
A vendor pitches a 'zero trust firewall' that, once deployed at the perimeter, marks everything behind it as trusted. Why does this miss the point?