Cybersecurity · 2026-07-24

Zero trust, past the slogan

The model verify every request, trust no network solved, buyable inventory — you cannot decide about machine identity — a shared secret the exception path — routed around where it actually stalls One segment, done properly known inventory, owned workloads settles the feasibility argument with evidence
The technology is rarely the blocker. Programmes stall on the inventory, on machine identity, and on the exception nobody was allowed to declare.

Zero trust is a good idea wrapped in bad marketing. Strip away the vendor language and it says something plain: stop granting access on the basis of where a request came from, and start granting it on the basis of what the requester proved.

The technology to do that largely exists. I went and got certified in this, partly to find out whether there was more to it than the diagrams suggested. There is not, technically. Programmes stall somewhere else entirely.

Where they stall

Inventory. You cannot make per-workload decisions about workloads you cannot enumerate. Most organisations discover, about a third of the way in, that their inventory is a spreadsheet with a confidence interval attached. This is the single most common place these efforts quietly stop, and it is nobody's glamorous project to fix.

Identity for machines. Human identity is a solved problem in most enterprises — there is a directory, there is an owner, there is a joiner-mover-leaver process somebody audits. Service identity is very often a shared credential sitting in a configuration file that three teams depend on and no team owns. Every one of those is a small negotiation, and there are hundreds of them.

The exception path. Every real environment contains something that cannot be brought into the model this quarter. A system whose vendor is gone. A workload nobody will risk touching before a certification. If there is no honest, time-boxed exception process, teams do not comply more — they route around the entire programme, and you lose the visibility you started with.

What I would do first

Pick one segment where the inventory is genuinely known and the workloads are genuinely owned. Not the most important segment. The most knowable one. Do it properly there, end to end, including the parts that are tedious.

A working example inside your own organisation is worth more than any reference architecture, because it settles the feasibility argument with evidence rather than opinion. Once people can point at something real in their own estate, the conversation stops being about whether this is possible here and starts being about sequencing. That is a much better argument to be having.

← All posts

The only way out is in.

Sadhguru