[ZT 1] Zero Trust Is Not a Product

Nobody sells Zero Trust, including the vendors who say they do. Microsoft says so on its own documentation, NIST needed 24 organizations and 19 distinct builds to demonstrate one, and the man who coined the term has spent a decade saying you cannot buy it. What you can do is practice it.


At some point in the next year, someone above you in the org chart is going to ask what it would cost to buy Zero Trust. The question arrives in good faith. It has a budget line waiting behind it, and a vendor happy to fill it. This article is the answer I give when I get that question, and the answer starts with an inconvenient fact: nobody sells Zero Trust, including the companies that say they do. Microsoft says so in its own documentation. The government agency that wrote the maturity model says so. The analyst who coined the term has spent fifteen years saying so. What they all sell is components. Zero Trust is what you do with them.


The sentence the vendor will not read to you

Microsoft’s own deployment documentation carries this sentence, word for word: “Zero Trust is a security strategy. It isn’t a product or a service, but an approach in designing and implementing the following set of security principles.” That is not a blogger’s paraphrase or an analyst’s critique. It is the first thing Microsoft tells you before walking you through deploying its own products. The same company’s marketing site organizes its entire security portfolio under a Zero Trust banner and routes every pillar of the strategy to something you can license. Both things are true at once, and the tension between them is the whole problem this series exists to untangle. The products are real and most of them are good. The strategy is not inside any of the boxes.

The principles the sentence refers to are three, and they are short enough to hold in your head through every design decision you will ever make. Verify explicitly: every access request gets authenticated and authorized on all the signal available, identity, device health, location, workload, data classification, anomalies, every time, not once at the front door. Use least privilege access: give the minimum access needed, for the minimum time needed, and take it back afterward. Assume breach: design as if the attacker is already inside, because segmentation, encryption, and detection built on that assumption keep working on the day the assumption comes true. Nothing in those three sentences names a product, and that is not an accident of phrasing. They describe how an organization behaves.

What the words actually mean

The name misleads people, so let me be precise about what is and is not being trusted. Zero Trust does not mean trusting nothing, and an estate that literally trusted nothing would not function. The formal definition, NIST Special Publication 800-207, puts it plainly: zero trust assumes there is no implicit trust granted to assets or user accounts based solely on their network location or on who owns the hardware. The thing being removed is not trust. It is the shortcut where being on the office network, or the VPN, or the corporate laptop counted as trust all by itself. Trust still gets granted constantly, thousands of times a day. It is granted per session, per request, based on evidence presented at that moment, and it expires.

Said differently: the old model trusted by default and blocked by exception. This model blocks by default and trusts by exception, where the exception is a verified identity on a healthy device doing something its role permits. Every mechanism this blog has ever written about, Conditional Access, device compliance, privileged identity management, the network edge, is a way of manufacturing those exceptions reliably and cheaply enough that the business never feels the default.

The proof that you cannot buy it

If the claim that no product delivers Zero Trust sounds like consultant positioning, consider what it took the people with no product to sell. NIST’s National Cybersecurity Center of Excellence spent years building working Zero Trust architectures for its implementation guide, SP 1800-35, finalized in June 2025. The result was nineteen distinct example builds, assembled from commercial off-the-shelf technology contributed by twenty-four industry collaborators, Microsoft among them, alongside its fiercest competitors. Nineteen ways to do it, two dozen companies’ products, and not one of the nineteen came out of a single box. That document is the closest thing the field has to a controlled experiment, and its result is the thesis of this article.

CISA’s Zero Trust Maturity Model points the same direction from a different angle. It measures an organization across five pillars and four maturity stages, and the things that move you up a stage are behaviors: how access decisions get made, how automated your responses are, how continuously you validate. A purchase order can put a capability on the shelf. It cannot make your organization use it, and the model only credits the using. The man who started all of this, John Kindervag, wrote the original Forrester report in 2010 and has repeated ever since, at every vendor that has employed him, that Zero Trust is a strategy and that no product delivers it. When the originator, the standards body, the government, and the largest vendor in the market all agree on something, and that something is bad for sales, I am inclined to believe it.

NIST needed nineteen distinct builds and twenty-four organizations’ products to demonstrate Zero Trust. Not one of the nineteen came out of a single box. That is the closest thing the field has to a controlled experiment.

Why the confusion persists

The confusion is not stupidity, it is economics. Zero Trust spent its first decade as a paywalled analyst concept while vendors did the public explaining, and vendors explain things in terms of what they sell. Forrester itself eventually complained that the market had only ever seen Zero Trust through vendor marketing, and published a formal definition to try to take the term back. By then whole product categories had named themselves after the strategy. ZTNA, Zero Trust Network Access, is a genuinely useful category of remote access product, and it is also two letters of marketing attached to a network client. Buying one gets you a better VPN replacement. It does not get you Zero Trust any more than buying running shoes gets you a marathon.

There is a second, softer reason the confusion survives: the product framing flatters everyone. The vendor gets a deal, the executive gets a line item that reads as a completed initiative, and the engineer gets new software instead of the harder assignment, which is changing how access works for every person in the company without breaking a Tuesday. A strategy has no install date. That is an uncomfortable thing to put on a roadmap, and so the industry quietly agreed to pretend otherwise. I have watched that pretense fail at enough organizations to say the pattern out loud: the estates that bought Zero Trust have a shelf of enabled features and the same flat network they started with. The estates that practiced it sometimes spent less.

What your money does buy

None of this means the products are beside the point. You cannot verify explicitly without an identity platform and a policy engine. You cannot condition access on device health without management and an endpoint security signal. Least privilege at human speed requires tooling that makes elevation temporary, and assuming breach is empty talk without detection and the means to contain what you detect. The strategy is unreachable without components, which is exactly why every serious framework maps capabilities to its pillars, and why Microsoft was named among the Leaders when Forrester evaluated Zero Trust platforms in 2025. If your organization runs Microsoft 365, you already own a remarkable share of the necessary components, and one of the recurring jobs of this series is pointing out which ones are sitting in your license unused.

The distinction I want you to carry out of this article is between owning and practicing. A tenant with Conditional Access licensed but three policies deployed is not further along than a tenant with none, and a tenant that enabled every feature in a weekend is often worse off, because controls nobody understands get disabled the first time they inconvenience a director. Progress in this strategy is measured in decisions made and habits changed, per pillar, unevenly, over years. That is what the maturity models measure. It is also, for what it is worth, why this work stays interesting.

Where this series goes

This site already teaches most of the machinery in depth: Conditional Access as the control plane, the identity platform under it, device management, the Defender stack, privileged access, the network edge. What has been missing is the map, and that is what these foundation articles are. Before we argue about any control, we are going to establish what Zero Trust actually is, where it came from and what it replaces, what it changes about daily work for the people in your building, and what the market of frameworks and vendors honestly looks like, Microsoft and otherwise. No configuration, no decisions yet, no shopping. The journey metaphor gets abused in this field, but it is the accurate one: a journey is the kind of thing that has a map, a starting point, and stages, and cannot be purchased at any price. The next article is about the starting point, the world the perimeter built, and why it ended.


Zero Trust
Next: [ZT 2] From the Perimeter to the Access Decision