Ask ten vendors whether their product implements Zero Trust and nine of them will say yes. Ask them to explain specifically which NIST SP 800-207 tenets their product satisfies and the conversation gets much shorter.
Zero Trust has become so thoroughly marketised that it has lost much of its operational meaning. Security teams are left trying to evaluate whether they have a “Zero Trust strategy” when they are not sure what that would actually look like in practice.
Let us be precise about what Zero Trust means, why it cannot be purchased as a product, and why identity is the only viable foundation for it.
What Zero Trust Actually Means
Zero Trust is an architectural philosophy, not a technology category. Its core premise is straightforward: no user, device, or workload should be trusted by default, regardless of their network location. Every access request must be explicitly verified against policy before being granted, and access should be limited to the minimum necessary for the specific task.
The term originated from Forrester analyst John Kindervag in 2010, and was formalised by NIST in Special Publication 800-207 in 2020. NIST identifies seven tenets:
- All data sources and computing services are considered resources
- All communication is secured regardless of network location
- Access to individual enterprise resources is granted on a per-session basis
- Access to resources is determined by dynamic policy
- The enterprise monitors and measures the integrity and security posture of all assets
- All resource authentication and authorisation is dynamic and strictly enforced before access is allowed
- The enterprise collects as much information as possible about the current state of assets and uses it to improve security
Notice what is not on this list: firewalls, network segmentation, VPNs, or any specific product category. Zero Trust is about the decision-making logic for access, not the perimeter technology surrounding it.
Why You Cannot Buy Zero Trust
The marketing problem with Zero Trust is that almost any security product can claim to contribute to a Zero Trust architecture. And technically, many of them do — in the same way that a deadbolt contributes to a secure home. It is a necessary component, but having a deadbolt does not mean your home is secure.
What you cannot purchase is the architecture itself. That requires decisions about:
- What counts as a valid identity in your environment (and there are more types than you think)
- What contextual signals you evaluate before granting access (device posture, location, behaviour, risk score)
- How you define and enforce minimum necessary access for every identity type
- How you respond when the context changes mid-session
These are not product decisions. They are architectural decisions that a product can support — but not replace.
Why Identity Is the Foundation
If Zero Trust requires verifying every access request, the first question is: verify who?
The answer is identity. Not network address — IP addresses are trivially spoofable and change constantly in cloud environments. Not device certificate alone — a clean device can be operated by a compromised user. The authoritative answer to “who is making this request” is always an identity.
This is why every serious Zero Trust implementation begins with identity:
- Human identity: Consistent authentication and access policy for employees, contractors, and partners across all applications
- Machine identity: Verified identities for every service, workload, and automated process — not just assumed trust because a request came from an internal IP address
- Agentic AI identity: As AI agents proliferate, they need verified identities with defined scopes — the same principle applied to a new identity type
Without a unified, authoritative identity foundation, Zero Trust is aspirational rather than operational. You cannot apply consistent access policy to entities you cannot consistently identify.
What a Practical Zero Trust Foundation Looks Like
Building toward Zero Trust does not require a multi-year transformation programme before any value is delivered. A practical approach starts with what matters most:
Start with unified identity. Ensure every user, service, and workload has a verified, governed identity. Eliminate shared credentials and anonymous access.
Enforce least privilege. Right-size access for every identity type. Implement access certification to catch access that is no longer needed.
Add context to access decisions. Evaluate device posture, user behaviour, and risk signals — not just credential validity — before granting access.
Log everything. A complete, tamper-resistant audit trail is both an operational requirement and a compliance necessity.
Automate policy enforcement. Manual access review processes cannot keep pace with cloud-native environments. Policy enforcement must be automated and continuous.
Zero Trust is not a destination. It is a direction — and identity governance is how you start moving in it.