TL;DR The old model is a castle. Get past the wall and you’re trusted everywhere inside. Zero trust is a hotel. Your key card opens your room, the gym if you booked it, and nothing else, and every door checks the card every time. Below, the three principles, a day in that hotel, and what the key card turns into once the doors are software.
“So what is this zero trust thing everyone keeps talking about?”
I get that question a lot. Usually from a manager or an executive who has to approve a security budget and doesn’t have a technical background to lean on. And most of the explanations I’ve seen are bad. They either drown you in jargon or sand the idea down until there’s nothing left to hold.
So here’s the version I use instead. I’ve tried it on my parents, on executives, and on the colleague who still calls the firewall “the internet box”. It works because it starts with a thing you’ve held in your own hand, a hotel key card. From there it goes all the way down to mTLS and identity-aware proxies, and the idea doesn’t change on the way.
The castle it replaces
Before the hotel makes sense, you need the thing it replaces.
Traditional network security is a medieval castle. You build a big wall (the firewall), dig a moat around it and put guards at the gate. Anyone outside the wall is untrusted. Anyone who makes it inside is trusted, and can go anywhere and do anything.
That was a fair design when:
- Everyone worked in the same building
- All the servers lived in the basement
- “Remote work” meant carrying a laptop home once a year
Then people started working from coffee shops and applications moved to the cloud. Half the kingdom was outside the wall now, and the wall stopped meaning much.
The castle has one flaw that the rest never makes up for. Once someone is past the gate, they’re trusted. An attacker who compromises one laptop inside the network can walk around freely. Most breach write-ups I’ve read have that shape. Phishing gets someone in, then they move “laterally” through a network where everything trusts everything else. One phished laptop, and the blast radius is the whole castle.
The hotel
Now the picture I use instead.
Picture a modern hotel. You check in at the front desk and get a key card. That card:
- Opens your room
- Opens the gym (if your booking includes it)
- Opens the pool area (if your booking includes it)
- Opens the parking garage (if you registered a car)
- Does NOT open other guest rooms
- Does NOT open the staff areas
- Does NOT open the kitchen
Every door decides for itself whether to let you in. The door doesn’t care that you’re “inside the hotel”. It wants to know whether this card may open this door, right now.
That’s zero trust in one sentence. Every door checks, every time, wherever you’re standing. The rest of this post is that sentence with more detail.
Why the name trips people up
Quick detour, because the name does damage before the idea gets a chance.
“Zero trust” sounds like you trust nothing and nobody, which would be paranoid and unworkable. “Verify everything” would’ve been the honest label. “Continuous verification” if you wanted the consultants to like it. We’re stuck with the buzzword, so we work with it.
What it means in practice:
- Don’t trust based on location (being inside the network)
- Don’t trust based on history (you logged in once, so you’re trusted forever)
- Verify every access request, every time
- Grant the minimum permissions the job needs
At the hotel you’re a verified guest with a specific list of doors, and you show the card at each of them.
Three principles, one key card
Zero trust has three load-bearing principles, and the hotel covers all of them.
Verify explicitly
Every door checks your card, every time. There’s no wristband that says “trusted guest” and waves you through the rest. The pool checks. Your room checks.
In software, that means every access request gets authenticated and authorized, no matter where it comes from. The request from the office network gets the same treatment as the one from the coffee shop.
Least privilege
Your card opens what you need and nothing more. Booked a basic room? You get your room and the common areas. Booked the executive suite with gym access? You get those too. You never get other guest rooms, and you never get the staff corridor.
In software, people and services get the minimum permissions their role requires. An accountant doesn’t need the source code. A developer doesn’t need the HR records.
Assume breach
The hotel is designed on the assumption that someone will eventually hold a card they shouldn’t. That’s why every door checks on its own. A stolen card opens what that card was allowed to open, and the rest of the hotel stays shut.
In software, you design as if the attacker is already inside. Limit the blast radius, segment the network, watch what talks to what. This is the principle I care about most, because it matches how I think about every system I run. Failure is the default I plan for. Something in the setup is going to get compromised eventually, and I want to know beforehand where that stops.
A day in the hotel
The three principles are the theory. Watching them run for a day is where it clicks.
Morning. You head to the gym and tap your card on the door. The door asks three things. Is this guest allowed in the gym, is the booking still valid, is the gym open right now? Yes to all three, so it opens.
Midday. Back in your room, you want room service. You call, and they ask for your room number and a security code from your check-in receipt. Caller ID on its own isn’t enough for them.
Afternoon. You try the printer in the business center. You authenticate again, card plus a PIN you set at check-in. For some resources, holding the card doesn’t cut it.
Evening. Your booking ends at 6 PM, but your flight is at 8 PM. You ask for a late checkout and the front desk extends your access to 7 PM. At 7:01 PM your card stops working everywhere. Room, gym, all of it.
One day, and the whole model has been on show. Continuous verification, access with an end time, a stronger check for the sensitive stuff, and revocation the moment the access expires. Nobody had to go around collecting cards.
What it isn’t
A few misconceptions, because they come up in almost every conversation I have about this.
“So no more passwords?” You still authenticate. You do it more carefully, and often with more than one factor.
“So a VPN everywhere?” A VPN is the castle gate. Get through it and you’re trusted inside. Zero trust often replaces the VPN altogether with a check per resource, and Google’s BeyondCorp is the canonical example of doing exactly that.
“That’s for big companies.” The principles scale down. Your home network can run on them too.
“Which product do I buy?” Vendors will happily sell you a “zero trust solution”, but there’s nothing to install. It’s an approach you build toward, one door at a time.
“So we switch it on next quarter?” Moving to zero trust takes time. It’s a migration, and a slow one. There’s no switch.
Where the hotel stops and the software starts
Here the metaphor runs out and the real systems take over.
In a real zero trust setup the doors are software. There’s no wall any more. Every request carries proof of who or what is making it, and every resource decides for itself whether that proof is good enough.
- The key card becomes a cryptographic identity. For services that often means SPIFFE identities and short-lived certificates instead of a long-lived shared secret.
- The door check becomes mTLS, where both sides prove who they are before a single byte of application data moves.
- “Every door checks on its own” becomes microsegmentation. In Kubernetes that’s a NetworkPolicy per workload, enforced by a CNI like Cilium, so a compromised pod can’t reach anything it wasn’t explicitly allowed to reach.
- The late checkout that expires at 7:01 PM becomes short-lived credentials from something like Vault, so access ends on a timer instead of lingering until someone remembers to revoke it.
None of that changes the idea. It’s the same hotel with cryptography where the plastic was, and each bullet is one door.
This is also why zero trust sits so well with how I think about sovereignty. Once you stop trusting the network and start verifying every request, you have to know who talks to what, and why. There’s no vague “inside” left to wave through. Every connection is something you can inspect and something you can revoke, and why I won’t run what I can’t inspect is in Sovereign Infrastructure.
The version for the meeting
When someone asks you what zero trust is, try this:
“Traditional security is like a castle. Once you’re inside the walls, you’re trusted everywhere. Zero trust is like a hotel. You have a key card, but every door still checks whether you’re allowed through. Being inside doesn’t mean you have access to everything.”
That’s the whole thing. Underneath sit identity providers, microsegmentation, mTLS and monitoring, but they’re all implementing that one sentence.
My parents got the hotel and none of the bullets. Everything past the hotel is for whoever comes back with a second question.