Explaining Zero Trust to Non-Technical Executives
Earlier in this series
If you sit anywhere near a security budget, a vendor has already said the words "zero trust" to you. Possibly several vendors, describing several completely different products, all with the same two words on the slide.
I spent years in B2B sales before I became a security practitioner, so I recognise the pattern from the inside: a genuinely good idea becomes a label, and the label gets stuck on everything. This piece separates the idea from the label. By the end you will be able to explain zero trust in one paragraph and defend your budget with three questions.
First, the term itself, defined plainly: zero trust is a security approach in which no person, device, or connection is trusted automatically because of where it is. Every access to something valuable must be verified, every time, based on who is asking and whether they should have it.
That definition is abstract, so let me do what I always do — start with buildings.
The castle and the hotel
The old model is a castle with a moat. One strong wall, one drawbridge, guards at the gate. Getting in is hard. But once you are inside — because you work there, or because you sneaked in — you can walk almost anywhere. The interior is trusted. In network terms: a strong perimeter (the moat is the firewall, the filter between your network and the internet), and generous freedom within.
For decades this was reasonable. Then everything moved: employees work from homes and airports, data lives in rented cloud services rather than the basement, contractors and suppliers connect from everywhere. The castle still has a moat, but half the kingdom now lives outside the walls. Worse, as I showed in Phishing Explained Without the Jargon, attackers rarely storm the gate anyway — they get a legitimate resident to open the door. Once inside a castle-model network, a phished attacker inherits all that interior trust.
Zero trust is a hotel with keycards. Anyone can enter the lobby. But your keycard opens your room — not every room. It opens the gym, but not the manager's office. It expires when your stay ends. If the hotel suspects a card was copied, it cancels that one card without changing every lock in the building. Nobody is "inside and therefore trusted"; every door checks every card, every time.
That is zero trust in one image: move the checking from one big gate to every individual door, and make the checks specific to the person, the door, and the moment.
Where the analogy breaks — and I always tell you where it breaks. First, hotel doors check the card, not the guest: a stolen card works until cancelled. Real zero trust aims higher, checking who you are, the health of the device you are using, and whether the request is normal for you. Second, hotels check only at the door; good zero trust designs keep noticing behaviour after entry — the guest who opens their own room is fine, the "guest" trying two hundred doors in an hour is not. Third, a hotel issues cards at one front desk; in a company, deciding who gets which "card" for which "door" is a continuous management discipline, and it is where most real-world efforts succeed or fail.
What zero trust is not
This is the section that protects your budget.
It is not a product. You cannot buy zero trust, in the same way you cannot buy "being in good shape." Products can help — identity systems, device checks, access controls — the way running shoes help fitness. But a vendor selling "zero trust in a box" is selling shoes and promising the marathon. As I noted in my glossary, vocabulary confusion is rarely innocent when money is involved.
It is not distrust of your employees. The phrase sounds hostile, and executives sometimes hesitate to endorse it for cultural reasons. The target of the "zero" is not your people; it is the assumption of location. It stops meaning "we trust whoever is in the building." Your people keep access to what they need — in fact, well-implemented zero trust often feels smoother for staff, because access follows them wherever they work.
It is not a project with an end date. It is a direction of travel. Organisations become more zero-trust over years: first strengthening identity checks, then limiting what each account can reach, then adding device and behaviour checks. Anyone promising completion by next quarter is describing an installation, not a transformation.
Three questions to ask any vendor
You do not need technical depth to interrogate a zero-trust pitch. These three questions do the work:
| # | The question | What a good answer sounds like | The warning sign |
|---|---|---|---|
| 1 | "Which specific part of zero trust does your product cover, and which parts does it not?" | A bounded claim: "We handle identity verification; you still need to decide who gets access to what." | "We cover all of it." |
| 2 | "What do you need from us for this to work?" | A demand list: an inventory of your systems, decisions about access rules, named internal owners. | "Nothing — it just deploys." |
| 3 | "If an attacker steals a legitimate employee's password, walk me through what happens." | A concrete story of limits: what the attacker can reach, what gets flagged, how access is cut. | Anything vague, or a pivot back to prevention. |
The pattern behind all three: honest vendors describe boundaries and homework; label-sellers describe magic.
The one-paragraph version
Here is the summary I would want you to repeat in your next board meeting:
"Zero trust means we stop trusting anyone just for being inside our network, the way a hotel checks every keycard at every door instead of trusting everyone past the lobby. It is an approach we implement over years, not a product we buy — so when vendors use the phrase, we ask what part they cover, what work falls on us, and what happens when a password is stolen."
If you can say that, you understand zero trust better than most people selling it.
Later in this series I will look at the other phrase that dominates policy and boardroom debates alike — encryption, and what it can and genuinely cannot protect.