Zero Trust, honestly: what it actually means, and what it does not

For three weeks I have kept us on one path: the Cybersecurity Framework, then the Risk Management Framework, then the two steps everyone gets stuck on. This week I step off that path for one episode, to take on a phrase you have almost certainly heard, probably from a vendor, and maybe never had explained plainly. Zero Trust.

If you have seen "Zero Trust" on a product page or a conference banner, you would be forgiven for thinking it is a thing you buy and switch on. It is not. Zero Trust is a way of thinking about security, and once the idea lands it is genuinely simple. Let me try to make it land.

The old idea it replaced: the castle and the moat

To understand Zero Trust you have to understand what it is reacting against. For a long time security worked like a castle with a moat. You built a strong wall around your network, the firewall, and you decided that anything inside the wall was trusted and anything outside was not. Get past the moat, through the drawbridge, once, and you were in. Inside, you could move around fairly freely.

That worked when everything lived inside the wall: the servers in a room down the hall, the staff at desks on the same network. But look at where things live now. Your systems are in the cloud, not down the hall. Your people work from home, from cafes, from their phones. The wall has holes in it by design, and half of what you care about is outside it entirely. The moat stopped meaning very much.

And there is a nastier problem. Once an attacker gets inside a castle-and-moat network, even by stealing one password, they are treated as trusted, and they can move sideways to much more valuable things. Most bad breaches you read about are not one clever break-in. They are one small break-in, followed by quiet movement across a network that trusted the intruder the moment they were inside.

The one idea: never trust by default, always verify

Zero Trust throws out the idea of a trusted inside. There is no inside. Every request to reach anything is treated as if it came from an untrusted network, every time, no matter where it comes from. You do not get waved through because you are "on the network." You get checked.

That is the whole idea in one line: never trust by default, always verify. A request to open the customer portal, or reach a database, or read a file, is checked on its own merits, right then, regardless of whether it came from the office or a cafe.

The name is a little dramatic. It does not mean you trust nothing, ever. It means you grant trust deliberately, in small amounts, for one request at a time, and you never hand it out for free just because of where someone happens to be sitting.

What actually gets checked

So if every request is verified, verified against what? Three things, in plain terms.

• Who are you? Real identity, proven properly, which in practice means multi-factor: a password plus a second proof, like a code on your phone or a tap in an app, not a password alone.
• What are you on? The device. A company knows a device because it is enrolled and managed, so it can check things like whether the disk is encrypted and the operating system is up to date, rather than trusting some random laptop.
• What are you asking for, and should you have it? Least privilege: you get access to the one thing you need, for this task, and nothing more.

Put those together and a request is allowed only if the right person, on an acceptable device, is asking for something they are actually entitled to. Fail any of the three and the request is refused, even if the last one from the same person was fine. And the checking does not stop at the door. Access is watched while it is used, so a device that falls out of health, or behaviour that suddenly looks wrong, can pull the access back in the middle of a session.

The three ideas underneath it

NIST, the US government body whose guidance the rest of this series is built on, wrote this up properly in a document called SP 800–207, which lays out seven tenets in full. A common plain-language distillation, the one you will hear most often, boils the same mindset down to three ideas.

• Verify explicitly. Decide every access on real signals, identity, device, context, rather than on network location.
• Use least privilege. Give the smallest access that does the job, and only for as long as it is needed.
• Assume breach. Design as if an attacker is already inside. Segment things so that one compromised account or machine cannot reach everything. Keep the blast radius small.

That last one, assume breach, is the mindset shift that makes the rest make sense. You are not just trying to keep attackers out. You are arranging things so that when one does get in, and one eventually will, they are boxed into a tiny corner instead of loose in the whole castle.

What Zero Trust is not

Because the phrase gets sold so hard, it is worth being blunt about what it is not.

• It is not a product. Nobody can sell you "Zero Trust" in a box. Tools help you do it, but buying a tool is not becoming Zero Trust, any more than buying a treadmill is becoming fit.
• It is not a single project you finish. It is a direction you move in, usually for years, one system and one control at a time.
• It is not all or nothing. You do not flip a switch. You make the most important things verify every time first, and you widen from there.

If a vendor tells you their product will "make you Zero Trust," what they usually mean is that their product does one useful piece of it. That can be true and worth buying. Just do not mistake the piece for the whole idea.

A request to the portal, under Zero Trust

Take the customer web portal from the last few episodes. Under the old model, once a support agent was logged into the internal network, reaching the portal's admin screen was easy, because they were "inside."

Under Zero Trust, that same agent opening that same admin screen is a fresh decision every time. Are they who they say they are, proven with multi-factor. Is the laptop known and healthy. Does this specific person have the right to this specific screen, right now. Only then does it open. And if they then try to reach something they have no business touching, that is a separate check, and it fails, even though they are "in."

Nothing about that requires a magic product. It requires strong identity, some sense of device health, and access granted narrowly. Which is exactly where you start.

Where I would start

You do not do Zero Trust all at once, and you do not start by buying anything. You start with the cheapest, highest-value moves.

• Get identity right. Strong authentication and multi-factor everywhere, for staff and for customers. If you do only one thing, do this.
• Know what you have. You cannot protect, or segment, assets you have not listed. This is the Identify work from episode one, and it pays off here.
• Give least privilege. Stop handing out broad, standing access. Grant what the task needs, for as long as it needs it.
• Segment the important things. Make sure a foothold in one place does not open the door to everything.

None of those is exotic. They are good security done deliberately, with the assumption that the moat is already gone.

A pocket recap

• The old model trusted everything inside the network wall. Cloud and remote work dissolved the wall, and attackers used the trusted inside to move sideways.
• Zero Trust removes the trusted inside. Every request is verified on its own, every time: never trust by default, always verify.
• Each request is checked on identity, device, and least privilege. Fail any one and it is refused.
• A common summary boils the mindset into three ideas: verify explicitly, use least privilege, assume breach. NIST's own document, SP 800–207, sets out the full architecture in seven tenets.
• It is not a product, not a finished project, and not all or nothing. Start with identity and multi-factor, then widen.

Next week I close the season where a beginner should actually begin: a simple, honest plan for a small team that has to start somewhere. No jargon, just the first moves that matter most.

I am learning this in the open, so if I have flattened something a Zero Trust practitioner would put more carefully, please say so. That is half the reason I write these down.

Thanks for reading.

Field Notes is a weekly series where I try to explain security frameworks in plain language, mostly to understand them better myself. The main source for this piece is NIST SP 800–207 (Zero Trust Architecture), from the NIST Computer Security Resource Center (csrc.nist.gov). The exact, normative wording always lives in the official document; these are my plain-language notes. The free hands-on lab is at github.com/farouq7399/field-notes-lab.