What Is Zero Trust Architecture? Components Explained

A request arrives: a user on a laptop wants to open an internal application. Before any packet reaches that application, a component evaluates the request against policy, identity, and device state, decides allow or deny, and then a separate component configures the gateway in front of the application to open or refuse the connection. The user never touches the application directly. They touch an enforcement point that asks a decision point for permission first.

That arrangement is zero trust architecture. It is the set of components, and the way they are wired together, that turns the "never trust, always verify" model into something that actually gates traffic. The model is the principle. The architecture is the machinery.

This article stays on the machinery. It covers the logical components defined in NIST SP 800-207, how the policy decision point and policy enforcement point split the work, the data sources that feed an access decision, the architecture approaches, and the deployment models you choose between when you build one. For the model itself, its history, principles, and the seven NIST tenets, see the companion article on zero trust security.

What is zero trust architecture?

Zero trust architecture (ZTA) is the way network components and services are structured to enforce a zero trust security model. Where the model says "verify every request," the architecture is the concrete design that performs the verification: which component decides, which component enforces, what signals feed the decision, and where the boundary sits between deciding and enforcing.

NIST SP 800-207, titled "Zero Trust Architecture" and published in August 2020, is the vendor-neutral standard that formalizes this design. It defines an abstract model of logical components and their interactions, then describes the real-world variations you can build from it. The standard is deliberately not a product spec. It names the roles a working zero trust system must fill and leaves the implementation open.

The defining structural idea is the separation of the access decision from the access path. One component decides whether a request is allowed. A different component opens or closes the actual connection. They communicate over a dedicated control channel, kept apart from the application traffic itself. That split is what makes the architecture enforceable and auditable.

The core logical components

NIST SP 800-207 reduces the architecture to three core logical components. Two of them form the brain, the policy decision point. The third is the muscle, the policy enforcement point.

Policy engine (PE)

The policy engine is responsible for the ultimate decision to grant access to a resource for a given subject. It takes enterprise policy plus input from external sources, runs that input through a trust algorithm, and produces a verdict: grant, deny, or revoke. The PE makes and logs the decision. It does not carry it out. That separation, decide here, act there, is why the PE can be a pure decision service with a complete audit trail of every allow and deny.

Policy administrator (PA)

The policy administrator establishes or shuts down the communication path between a subject and a resource. When the policy engine approves a request, the PA generates any session-specific authentication token or credential the client needs and signals the enforcement point to open the session. When the engine denies a request, or countermands a previous approval, the PA tells the enforcement point to tear the connection down. The PA executes; the PE decides. They are tightly coupled and together they make up the policy decision point (PDP).

Policy enforcement point (PEP)

The policy enforcement point enables, monitors, and eventually terminates the connection between a subject and an enterprise resource. It is the gate. The PEP forwards requests to the policy administrator and receives policy updates back. Critically, the PEP can be one logical thing split into two pieces: a client-side agent (for example, software on a laptop) and a resource-side component (for example, a gateway in front of the application), or a single portal that brokers every path. Beyond the PEP sits the trust zone that hosts the actual resource. Nothing reaches that zone without passing the PEP.

Control plane and data plane

The components talk over a control plane. Application data moves on a separate data plane. The PA and PEP coordinate on the control plane to set up or tear down a session. Once a session is authorized, the subject's actual traffic to the resource flows on the data plane. Keeping the two planes apart means the decision-making traffic is never mixed with, or reachable from, the application traffic it governs. This is one of the architecture's structural defenses against lateral movement: an attacker on the data plane cannot reach the machinery that grants access.

The data sources that feed a decision

A policy engine is only as good as the signals it can see. SP 800-207 lists the data sources that feed input and policy rules into the PE when it makes an access decision. Some are local to the enterprise, some are external. None of them is the decision; together they are the evidence the trust algorithm weighs.

The takeaway is that an access decision is not a binary credential check. The PE folds device health, identity, threat state, and policy into one verdict, and it re-evaluates as those signals change. That is the difference between access control at the perimeter, which checks once, and zero trust access control, which checks continuously against live state.

Three architecture approaches

SP 800-207 describes three ways to assemble these components into a working architecture. They are not exclusive. A mature deployment usually blends all three, leaning on whichever fits a given resource. The difference is which capability does the heavy lifting.

Enhanced identity governance

Identity is the primary policy input. Access to resources is granted based on the identity and assigned attributes of the requesting subject, with device state and other factors as secondary signals. This approach leans on a strong identity provider, multi-factor authentication, and rich attribute data. It suits open network models where you cannot put a gateway in front of everything but you can demand that every subject prove who they are.

Micro-segmentation

The enterprise places individual resources, or small groups of related resources, behind their own enforcement points. SP 800-207 names intelligent switches, next-generation firewalls (NGFWs), and special-purpose gateway devices as the PEPs that protect each segment. The enterprise can also implement host-based micro-segmentation with software agents or endpoint firewalls. Each gateway dynamically grants access to individual requests. This is network segmentation taken to its logical end: the segment of one. A foothold on a single resource buys an attacker nothing, because every other resource is behind its own gate. This approach requires an identity governance program to function and relies on the gateways being centrally managed so they can reconfigure in response to threats.

Network infrastructure and software-defined perimeters

The enforcement is implemented at the network layer, often using software-defined networking concepts. A control plane component instructs the data plane to set up paths only between authorized subjects and resources, and the resources stay invisible to anyone not authorized to see them. The PEP and the path it controls are programmable, so the architecture can reshape connectivity per request rather than relying on static network topology.

Three deployment models

The approaches above describe how policy is enforced. The deployment models below describe where the enforcement point physically lives. SP 800-207 frames the PEP as splittable, and these are the three ways it gets split in practice.

The device agent/gateway model gives the tightest control because the enterprise owns both ends of the connection, agent and gateway. The enclave model trades granularity for compatibility: it can front a cluster of legacy systems that could never run a modern agent, at the cost of not gating movement inside the enclave. The resource portal model is what lets unmanaged and bring-your-own devices participate at all, since nothing needs to be installed on the client. Real deployments mix them by resource.

How the pieces work in one request

Put the components in motion and the flow is consistent regardless of approach:

1. A subject requests access to a resource. The request hits the policy enforcement point, not the resource.
2. The PEP forwards the request to the policy administrator on the control plane.
3. The policy engine pulls its data sources (identity, device posture from CDM, threat feeds, activity logs, data access policy) and runs the trust algorithm.
4. The PE returns a verdict to the PA and logs it. Grant, deny, or revoke.
5. On grant, the PA issues a session credential and signals the PEP to open the path on the data plane. On deny, the PA signals the PEP to refuse.
6. The session is monitored. If signals change, the PE can revoke, and the PA tells the PEP to terminate the live connection.

The property that matters is step 6. Authorization is not spent at connect time. The decision point can revoke an in-flight session when a device falls out of compliance or a threat feed lights up, and the enforcement point cuts it. Continuous enforcement is the architectural payoff. A compromised credential or a privilege escalation attempt that changes a subject's risk posture can lose access mid-session, not just at the next login.

Building toward this architecture

You do not flip a switch to a full zero trust architecture. SP 800-207 frames migration as an iterative process, and most enterprises run a hybrid of zero trust and perimeter-based architecture for years. The practical sequence:

• Identify the actors. Enumerate the subjects, human and non-human, that need access, and the attributes that describe them.
• Identify the assets. Catalog the resources, devices, and data the enterprise owns. You cannot protect what you have not inventoried.
• Map the key processes and their risk. Understand how subjects use resources so policy reflects real workflows, not guesses.
• Formulate policy. Write the access rules for each candidate resource, expressed in terms of identity, device state, and context.
• Select and deploy. Choose the approach and deployment model per resource, instrument a PEP, and start enforcing.
• Monitor and expand. Watch the decisions, tune the policy, and extend coverage to the next set of resources.

The architecture grows resource by resource. The first PEP in front of one high-value application is a real zero trust deployment, just a small one. The work is widening it without breaking the workflows people depend on.

Frequently asked questions

What is zero trust architecture?

Zero trust architecture is the design of components and services that enforces a zero trust security model. Defined in NIST SP 800-207, it centers on a policy decision point (the policy engine and policy administrator) that decides access and a policy enforcement point that opens or closes the connection, communicating over a control plane separate from application data.

What is the difference between zero trust and zero trust architecture?

Zero trust is the security model: the "never trust, always verify" principle and its tenets. Zero trust architecture is the technical implementation of that model, the policy engine, policy administrator, enforcement points, and data sources that actually perform the verification. One is the strategy, the other is the machinery that runs it.

What are the components of zero trust architecture?

The three core logical components in NIST SP 800-207 are the policy engine (PE), which decides; the policy administrator (PA), which executes the decision; and the policy enforcement point (PEP), which gates the connection. The PE and PA together form the policy decision point. Several data sources, including CDM, threat intelligence, PKI, and SIEM, feed the policy engine.

What is the difference between the policy decision point and the policy enforcement point?

The policy decision point (PDP) decides whether access is allowed; it is the policy engine plus the policy administrator. The policy enforcement point (PEP) carries out that decision by opening, monitoring, or terminating the actual connection. The PDP and PEP coordinate on the control plane, while the subject's data flows on a separate data plane.

How does micro-segmentation fit into zero trust architecture?

Micro-segmentation is one of the three architecture approaches in SP 800-207. It places individual resources or small groups behind their own enforcement points, such as next-generation firewalls or host-based agents, so each request is gated at the segment. It shrinks segments toward the size of a single resource, which removes the flat internal network an attacker would otherwise traverse.

Does zero trust architecture replace firewalls and VPNs?

It changes their role rather than removing them outright. Firewalls can serve as policy enforcement points in a micro-segmentation approach, so they remain useful as gates rather than as a single perimeter. A VPN, which grants broad network access after one check, runs counter to per-request enforcement, and many organizations phase them out in favor of brokered, per-resource access.