Zero Trust Is a Strategy. You Have Been Sold a Product.
Overview
Few concepts in security have been as thoroughly commercialized as Zero Trust. It appears on vendor websites as a feature, in product names as a category, and in sales conversations as something an organization can buy, install and check off. A security leader can be forgiven for believing that Zero Trust is a thing you procure — because the entire market has been organized to suggest exactly that.
It is not. Zero Trust is a strategy: an architectural approach built on a single principle — that no user, device, workload or connection is trusted by default, and every access decision must be explicitly verified against identity, context and policy. That principle has to be designed into how the organization grants and governs access across its entire environment. It is an operating model, not a SKU. And the gap between those two understandings is precisely where most Zero Trust initiatives go to stall.
The pattern is familiar. An organization commits to Zero Trust, evaluates products marketed under the label, purchases one, deploys it, and declares progress. Months later, the initiative has lost momentum, the environment is not meaningfully more verified than before, and no one is quite sure what "done" was supposed to look like. The problem was never the product. The problem was treating a strategy as a purchase.
Why This Matters Now
The stakes of getting this right have risen sharply. The dissolution of the network perimeter — through cloud adoption, remote work and the explosion of machine identities — has removed the implicit trust boundary that older architectures relied on. In an environment with no meaningful edge, the only durable way to control access is to verify every request explicitly. Zero Trust is not a fashionable framework; it is the logical response to an environment that no longer has an inside and an outside.
At the same time, the consequences of implicit trust have been demonstrated repeatedly and catastrophically. The attack pattern of the modern era — initial access followed by lateral movement through an environment that trusts internal traffic — is precisely the pattern Zero Trust exists to break. Organizations that have implemented it as a genuine strategy contain compromises that would otherwise spread. Organizations that bought a product and called it Zero Trust frequently discover, during an incident, that the implicit trust they meant to eliminate is still everywhere.
CISO2CISO Insight
You cannot buy Zero Trust any more than you can buy "being healthy." You can buy things that help. But the outcome is the product of sustained discipline applied across the whole environment — and no vendor can sell you that, because no vendor controls your environment.
Why a Product Cannot Deliver It
The reason Zero Trust resists productization is structural. The strategy requires coordinated change across domains that no single tool spans.
It is fundamentally about identity and context. At its core, every Zero Trust access decision asks: who or what is this, are they who they claim to be, what is the context of the request, and does policy permit it? That requires mature identity governance — for humans and increasingly for machines — that sits underneath any product and that most organizations are still building. A tool can enforce a policy; it cannot create the identity foundation the policy depends on.
It spans the entire access surface. Zero Trust is not a control you apply at one point. It is a principle you apply to network flows, application access, workload-to-workload communication, administrative access and data. Achieving it means changing how access works across all of these, which is an architectural and organizational program, not a deployment.
It requires defining what you are protecting. A coherent Zero Trust strategy starts by identifying the organization's most critical assets — the protect surface — and building verification around them, expanding outward over time. That definition is specific to each organization and cannot be supplied by a vendor. Skipping it produces a Zero Trust initiative with no center of gravity.
It is incremental and never finished. Zero Trust is approached in stages, starting with the highest-risk access and maturing over time. It is an operating discipline that has to be sustained as the environment changes, not a project with a completion date. A product purchase has an install date. A strategy has a trajectory.
What a Real Zero Trust Strategy Looks Like
A genuine Zero Trust program is organized around a sequence the market rarely sells, because most of it is not a purchase.
It begins by defining what matters most — the critical assets and access paths whose compromise would be most consequential. It builds the identity foundation that every verification decision depends on, for both human and non-human identities. It then applies explicit verification to access, starting with the highest-risk paths and expanding methodically, removing the implicit trust that lets a compromise spread. Throughout, it treats Zero Trust as a maturity journey measured by how much of the environment has moved from implicit to explicit trust — not by which products have been deployed.
Products absolutely play a role in this. They enforce the policies, broker the access, and provide the telemetry. But they are instruments of a strategy the organization owns, sequenced according to a plan the organization defines. The order of operations matters: strategy first, architecture second, products third. Organizations that reverse it — products first, in search of a strategy afterward — are the ones whose initiatives stall.
Executive Framework
| Dimension | Zero Trust as a product | Zero Trust as a strategy |
|---|---|---|
| What it is | Something you buy and deploy | An architecture and operating discipline |
| Foundation | The tool itself | Identity governance, human and machine |
| Scope | A point of enforcement | The entire access surface |
| Starting point | Vendor evaluation | Defining the critical protect surface |
| Timeline | Has an install date | Has a maturity trajectory, never finished |
| Role of products | The solution | Instruments of a strategy you own |
What CISOs Should Do Next
- Reframe Zero Trust internally as a strategy and operating model, not a product category — the language sets the expectations for everything that follows.
- Define your protect surface first: identify the critical assets and access paths that the strategy will be built around, before evaluating any tooling.
- Invest in the identity foundation — human and non-human — that every verification decision depends on, recognizing it as the precondition rather than an afterthought.
- Sequence the program by risk, applying explicit verification to the highest-consequence access first and expanding methodically, rather than attempting the whole environment at once.
- Select products as instruments of the strategy, evaluated by how well they serve your sequence and integrate with your identity foundation — not by how prominently they carry the Zero Trust label.
- Measure progress by how much of the environment has moved from implicit to explicit trust, and treat the work as an ongoing discipline rather than a project to be closed.
Board-Level Questions
- Are we treating Zero Trust as a strategy we own and sequence, or as a product we purchased and expect to deliver an outcome on its own?
- Have we defined what we are protecting first — our critical assets and access paths — or did we start with tooling?
- Do we have the identity foundation, for humans and machines, that any real Zero Trust verification depends on?
- How do we measure progress — by products deployed, or by how much of our environment no longer trusts anything implicitly?
Final Takeaway
Zero Trust has suffered the fate of every powerful idea that becomes a marketing category: its meaning has been bent toward whatever is easiest to sell. What began as a rigorous architectural principle — trust nothing, verify everything — has been repackaged as a product an organization can buy to become "Zero Trust," and that repackaging has set countless initiatives up to fail. They procured the label and never did the work, because the work is not a procurement.
The organizations that succeed treat Zero Trust as what it actually is: a strategy to remove implicit trust from their environment, built on an identity foundation, applied across the whole access surface, sequenced by risk, and sustained as a discipline. Products serve that strategy. They do not substitute for it.
You will not become Zero Trust by buying something. You will become Zero Trust by deciding what to protect, building the identity foundation to verify access to it, and methodically removing the implicit trust that lets a single compromise become a catastrophe — a strategy no vendor can sell you, because only you can execute it.
*To be continued...*


