You start with the inventory. The first question is not "which Zero Trust product". It is "what resources are we protecting, who can access them, from where, and what evidence supports that access." The inventory surfaces the implicit trust relationships that the perimeter is hiding. From there, the highest-value moves are identity-first (because identity is the substrate of every other decision) and the highest-friction assets first (because the cost of the per-request model is proportional to request volume, and a single crown-jewel application is a contained experiment).
Zero Trust Architecture
Zero Trust is a per-request authorisation model, not a product category. The architecture is the discipline of making every decision provable from evidence, every time.
On this page
§ 01 ·
What Zero Trust is
Zero Trust is a way of thinking about authorisation, not a piece of software. The most cited definition is NIST SP 800-207: "Zero trust is a set of cybersecurity principles that assume no implicit trust is granted to assets or user accounts based solely on their physical or network location." The deeper point is the per-request authorisation model: every access decision is evaluated against the identity of the requester, the state of the device, the sensitivity of the resource, and the current threat context, every time.
This sounds expensive. It is. The cost is the point. A perimeter-only model makes a small number of decisions expensively (at the boundary) and a very large number of decisions cheaply (implicitly, inside the network). Zero Trust inverts the ratio: many small decisions, each one provable from evidence. The result is not "more security"; it is auditable security.
The two architectural primitives that make this practical are the policy decision point (PDP) and the policy enforcement point (PEP). The PDP evaluates a request and returns a decision; the PEP intercepts the request and enforces the decision. The architecture is the relationship between the two, the identity of the requester, the signal about the request context, and the inventory of resources being protected. Everything else (agents, brokers, control planes, identity-aware proxies) is implementation.
§ 02 ·
What Zero Trust is not
Three things Zero Trust is often confused with, that it is not.
It is not a vendor category. The phrase is on every security product's marketing page. The products are real and many of them are useful, but buying the product is not the same as adopting the architecture. A Zero Trust architecture can be implemented with no new products at all, and many Zero Trust products are sold into architectures that are not Zero Trust in any meaningful sense. The test is the model, not the procurement list.
It is not "no firewall, no VPN, no perimeter." The perimeter changes shape: it moves from the network boundary to the resource boundary, but perimeters remain. Every Zero Trust architecture has boundaries; the difference is what they enclose and what evidence is required to cross them.
It is not a one-time migration. The architecture is a discipline of maintaining a current model of identity, device state, and resource sensitivity. Like any model, it goes stale. The work is the operating model that keeps it current, not the project that implemented it.
§ 03 ·
State of the practice
~10 years
Since the first public Zero Trust reference architecture (Google BeyondCorp, 2014-2017)
Google, 'BeyondCorp: A New Approach to Enterprise Security', USENIX ;login:, 2014
5
CISA Zero Trust Maturity Model pillars — Identity, Devices, Networks, Applications & Workloads, Data
CISA Zero Trust Maturity Model v2.0, 2023
0
Zero Trust products that are a complete Zero Trust architecture on their own
Industry observation; the architecture is always composite
§ 04 ·
Questions we get asked
ZTNA is a product category: a particular way of implementing the per-request authorisation model for network-layer access. It is one of several implementations. A Zero Trust architecture typically uses ZTNA products for some workflows (often workforce access to internal applications) and other implementations for others (service-to-service authorisation, customer identity, data access). The architecture is the model; ZTNA is one tool.
The trust algorithm is the function that maps a request's signals (identity, device, context, resource sensitivity) to a decision (allow, deny, step-up, deny with reason). The algorithm can be a simple lookup table or a complex risk-score; the property that makes it auditable is that the inputs are explicit, the function is documented, and the outputs are reproducible. The "algorithm" framing is from NIST SP 800-207 and is useful because it makes clear that trust is a calculation, not a state.
By the proportion of access decisions that are evaluated against explicit, current evidence. The starting line is whatever decisions are currently being made implicitly (by network location, by stale group membership, by configuration file that has not been reviewed in years). The destination is the per-request model. The metric is the percentage of decisions that pass through a documented PDP and PEP, which is something you can measure. The metric that matters more is the time it takes to detect and correct a wrong decision, which is the audit loop closing.
Yes, with caveats. The same principles apply, but the device inventory, the sensitivity classifications, and the request volume are different. OT environments often have legacy equipment that cannot host agents and long-lived sessions that the per-request model would re-authorise too often. The architecture is the same; the implementation is bespoke. CISA's OT-specific guidance is the right starting point.
Yes, and the per-request model is exactly the right discipline for agentic access. The signals are different (the "identity" is a service account, the "device" is the runtime, the "context" includes the agent's task and the trust the user delegated to it) but the architecture is the same. The harder question is the audit loop: who reviews the agent's access decisions, and what evidence do they have. This is an emerging practice area, not a solved problem.
§ 05 ·
Patterns we design our practice to avoid
Anti-patterns are behaviours that look like progress and produce a worse architecture than the one they replaced.
A Zero Trust architecture is a model, not a SKU. Buying a ZTNA product and pointing it at the workforce does not produce a Zero Trust architecture; it produces a ZTNA product pointed at the workforce. The architecture is the model, the operating model that keeps the model current, and the evidence that the model is being followed. The product is an implementation, and a well-implemented ZTNA product in a non-Zero-Trust architecture is worse than no product, because it creates the appearance of progress without the substance.
Identity is a necessary but not sufficient input to every authorisation decision. An identity-only model (authenticate the user, then allow) makes one decision expensively and many cheaply, the same perimeter pattern. The Zero Trust architecture evaluates every request, not just the first one. A strong identity system is the substrate; it is not the architecture.
Microsegmentation is the implementation of the trust algorithm at the network layer. Without a model of what segments are meaningful (which workloads trust which other workloads, on what evidence, for what duration), the segmentation is arbitrary and the operational cost is unsustainable. The model comes first; the segmentation implements it.
A trust algorithm that lives in a configuration file nobody has reviewed in two years is folklore, not architecture. The algorithm has to be documented, the documentation has to be current, and the model has to be testable: input signals, expected outputs, failure modes. The algorithm is a piece of code or a piece of policy; either way, it has to be readable.
The model goes stale. Devices change, identities change, resource sensitivity changes, threat context changes. The work is the operating model: who reviews the trust algorithm, how often, against what evidence not the project that put the initial PDP in place. A Zero Trust architecture with no operating model is a perimeter model with extra steps.
§ 06 ·
Evidence & references
Public frameworks and writing that inform our practice.
NIST SP 800-207, 2020
The canonical reference architecture and the source of the "trust algorithm" framing. The five-pillar decomposition (identity, device, network, application, data) is the vocabulary the rest of the practice uses.
CISA, v2.0, 2023
The maturity model the CISA published is the most useful instrument for measuring where an organisation is on the journey. The four maturity levels (Traditional, Initial, Advanced, Optimal) are concrete enough to map against actual evidence from a programme.
BeyondCorp: A New Approach to Enterprise Security
Google ;login: magazine, 2014 (and subsequent papers)
The original public reference architecture. The papers describe the model and the migration; the value for practitioners is the discipline of the inventory (devices, users, access patterns) that the migration depends on. The Google BeyondCorp paper series is the closest thing to a published "how we did it" for a large organisation.
U.S. Department of Defense, v2.0, 2022
The DoD reference architecture is heavier than most commercial organisations need, but the capability pillars map cleanly to the NIST model and the documents include implementation patterns that are useful in any large regulated environment.
Google Cloud, 2019
The service-to-service counterpart to BeyondCorp. Same per-request discipline, different trust boundaries (workload identity, not user identity). The model generalises to any environment where one workload calls another, which is most modern architectures.
OAuth 2.0 in Action
Justin Richer, Manning, 2017
The clearest end-to-end treatment of the authorisation layer as a contract, not a protocol. The conformance approach the book describes is the same approach the trust algorithm needs: explicit inputs, explicit outputs, testable behaviour.
Working on a Zero Trust programme?
If you are weighing a Zero Trust initiative, evaluating a ZTNA product, or trying to make an existing programme more than a procurement exercise, we are useful at the boundary between the model and the implementation. A short conversation is the right next step.
Learn more