Zero Trust is a posture, not a product

The phrase Zero Trust has been almost entirely consumed by the market. It appears on product pages for firewalls, network monitors, identity platforms, microsegmentation tools, and endpoint agents — each vendor implying that purchasing their product advances the organisation toward the state the phrase describes. It does not work this way. The phrase describes an architectural and organisational posture. It cannot be purchased. It can only be built, slowly, across teams, through decisions about where verification happens and what trust boundaries mean, at a cost that does not appear on a vendor invoice.

John Kindervag's 2010 Forrester research described a philosophy, not a product category: never trust, always verify. Move the trust boundary away from the network perimeter — which is porous, assumed-secure by convention, and historically incorrect — to the individual transaction. Every access request must be authenticated, authorised, and evaluated in context. The network is not the security boundary. The identity, the device posture, the request context, and the data sensitivity together constitute the boundary, dynamically, per-request. This model is sound and demanding. It requires knowing what you are protecting, who should have access to it, and what legitimate access patterns look like. Most organisations do not have this knowledge in a form precise enough to enforce it consistently.

Implementing Zero Trust in a real environment surfaces three requirements that no vendor adequately prices into their sales cycle. First: a complete and maintained asset inventory, because dynamic access controls applied to assets you have not enumerated produce unpredictable results, not security. Second: identity infrastructure mature enough to provide meaningful context at access time — device health, network location, time of day, role, session risk score — and act on it consistently across all access paths, including the legacy applications that cannot participate in modern authentication flows. Third: monitoring capable of detecting anomalous access patterns in a model where everything is, by design, potentially reachable, and where anomalous must be defined against your baseline, not a generic industry threat model. None of these capabilities come in a box. All of them require organisational maturity that accumulates over years.

The gap between the marketing deck and the threat model is where breaches live. Organisations that purchased the product and called it done typically retained the implicit trust assumptions of their old network architecture while adding the operational complexity of a new control plane. The organisations that have implemented the posture correctly do not describe it as an achievement. They describe it as a discipline they practise continuously — reviewing access decisions, tightening over-provisioned identities, re-evaluating what the trust model from six months ago was actually assuming about the world. Zero Trust as a destination is a narrative that serves vendors. Zero Trust as a practice is a different and more demanding commitment.