A contractor joins for two weeks to fix a reporting dashboard. Someone in IT provisions a VPN account, the contractor connects, and the laptop picks up an address inside the corporate range. The dashboard loads. So does everything else.
From that laptop the build servers answer. So does the internal wiki, the file share holding three years of payroll exports nobody archived, the printer management console, and a Jenkins instance last patched in 2023. Nobody approved any of that. The request was for one dashboard; what was granted was the network.
That gap between the access you meant to give and the access the network actually gives is the problem zero trust exists to close.
Run the same scenario with an attacker instead of a contractor and the shape does not change. A phished credential produces a session on a corporate address, and the interesting part of the incident begins. In most breach write-ups the entry point is unremarkable; the damage comes from the days of quiet movement afterwards, through a network that had already decided this traffic was friendly.
Zero trust is not a product and not a network topology. It is a set of principles about where trust is granted and how often it is re-checked. The vendor-neutral reference most organizations build against is NIST Special Publication 800-207, published in 2020, which names the components this post walks through: the enforcement point, the decision point, the administration point, and the signal sources that feed them.
The implicit trust zone
The old model has a name in the literature: the implicit trust zone. It is the region of the network where packets are assumed benign because of where they came from rather than what they are asking for. Authentication happens once, at the boundary. Everything after that is a matter of routing.
This was a reasonable design when it was invented. Employees sat in buildings you owned, on cables you owned, using machines you imaged. The boundary between inside and outside was a physical fact, so encoding it as a security boundary cost nothing.
Four things dismantled that. Applications moved to infrastructure you rent and SaaS you do not run at all. Workforces became remote by default. Devices became personal, contracted, or acquired through a merger you had no say in. And services stopped being monoliths, so the traffic that matters most is now east-west between workloads rather than north-south through a firewall.
The perimeter still exists. It just stopped being a useful trust boundary. A firewall that sees an authenticated VPN session from a corporate address cannot tell you whether the device is patched, whether the credential was phished this morning, or whether the account has any business reason to touch the payroll share.
Zero trust removes the assumption rather than the boundary. Network location becomes one weak signal among many, and the decision moves from the door to every individual resource, on every individual request.
The tenets, in one place
NIST frames zero trust as seven tenets rather than a blueprint. They are worth stating plainly because every architectural choice later in this post traces back to one of them. Paraphrased:
- Every data source and computing service counts as a resource, including personal devices doing enterprise work.
- All communication is secured regardless of network location. Traffic on the internal network gets the same treatment as traffic from a hotel lobby.
- Access is granted per session, and grants are as narrow and short-lived as the task allows.
- Access is determined by dynamic policy that considers identity, the requesting asset, and behavioral and environmental attributes, not by a static access control list.
- The organization monitors the integrity and posture of every asset it owns or associates with. No device is trusted because it was trusted last month.
- Authentication and authorization are dynamic and strictly enforced before access is allowed, and they are re-checked during the session.
- The organization collects as much data as it can about assets, infrastructure, and traffic, and feeds that data back into policy.
The last tenet is the one people skip, and it is the one that makes the rest work. A dynamic policy engine with no telemetry is a static policy engine with extra latency.
The big picture: control plane and data plane
The single most useful idea in the architecture is the split between two planes. The control plane is where decisions are made and configuration is pushed. The data plane is where application traffic actually flows. They are separate systems on separate channels, and the data plane carries nothing the control plane has not already authorized.
Three components form the core. The Policy Enforcement Point (PEP) sits in the data path and is the only thing a subject can reach directly. The Policy Engine (PE) makes the decision. The Policy Administrator (PA) turns that decision into a real instruction that the PEP can execute. NIST groups the PE and PA together as the logical Policy Decision Point (PDP).
Around that core sit two supporting roles. The Policy Administration Point (PAP) is where humans author and manage the policy in the first place. The Policy Information Points (PIPs) are the systems supplying the live signals the engine reasons over: identity, device posture, threat intelligence, logs, data classification.
Note the word "logical" throughout. None of these have to be separate servers. In a real deployment the PE and PA are usually one clustered service, and the PEP is frequently two cooperating pieces: an agent on the device and a gateway in front of the resource. The separation matters as a set of responsibilities, not as a bill of materials.
The Policy Enforcement Point
The PEP is the component that actually stops things. It sits in the traffic path, terminates the subject's connection, and refuses to forward anything until the PDP has said yes. If the PDP is the brain, the PEP is the hand on the valve.
In practice a PEP is rarely one box. The common pattern is a split: a client-side component such as a device agent or a local proxy, and a resource-side component such as a reverse proxy, an API gateway, or a service mesh sidecar. The client side supplies device context that no network device could see; the resource side guarantees that nothing bypasses the check by finding another route.
The property that makes a PEP useful is that it is the only reachable path. If the resource still has a listening port that accepts a direct connection from the network, the PEP is a suggestion. This is why zero trust deployments so often pair the PEP with some form of concealment: the resource is bound to `localhost` or a private segment, and the gateway makes an outbound connection, so there is no exposed port for anyone to scan.
PEPs also carry the session after the grant. A decision is not a one-time gate. The PEP holds the connection open with a time-to-live and a set of conditions attached, and tears it down or re-authorizes when the PA tells it the conditions changed. Session termination is an enforcement action, not an error.
Finally, the PEP is the richest telemetry source in the architecture. It sees who asked for what, how often, from where, and with what result. Those logs feed straight back into the signal layer, which is the loop that makes policy adaptive rather than merely dynamic.
The Policy Decision Point: the Policy Engine
The Policy Engine answers exactly one question: should this subject be granted access to this resource, right now, under these conditions? It does not implement the answer. It computes it, records it, and hands it to the Policy Administrator.
The logic it uses is called the trust algorithm. Inputs fall into a few families. Identity and entitlement from the directory. Device posture from endpoint management: is it enrolled, patched, encrypted, running the agent? Resource sensitivity from data classification. Threat intelligence, both external feeds and internal indicators. Historical behavior, meaning what this account normally does at this hour from this place. And environmental context such as time, geography, and network path.
NIST describes two useful axes for how those inputs get combined. The first is criteria-based versus score-based. A criteria-based algorithm requires a fixed set of conditions to be true, which is predictable and easy to audit but brittle at the edges. A score-based algorithm produces a confidence value and compares it against a threshold, which handles ambiguity gracefully but can be hard to explain when it denies a legitimate request at 3 a.m.
The second axis is singular versus contextual. A singular evaluation treats each request as independent. A contextual evaluation considers request history, so a subject that has just pulled four thousand records from a database gets scored differently on the fifth thousand than it did on the first. Contextual evaluation catches slow exfiltration that no single request would ever trip.
Most mature deployments end up with a hybrid: hard criteria that must be met for the request to be considered at all, then a score that determines how much access is granted and for how long. The output is rarely binary. Allow, allow with reduced scope, allow after step-up authentication, and deny are all normal results.
The Policy Decision Point: the Policy Administrator
The Policy Administrator is the component people most often forget, because on a whiteboard it looks like a message bus. Its job is to convert a decision into something operational: establishing the communication path, issuing the session credential or token the PEP will honor, and later revoking it.
Separating this from the Policy Engine buys two things. First, the engine can be replaced, tuned, or run in shadow mode without touching the machinery that actually opens and closes connections. Second, credential issuance becomes a single choke point that can be audited independently of policy logic, which matters enormously when you are trying to answer "who authorized this session" after an incident.
The PA is also the component that makes revocation real. When the engine re-evaluates a session and the answer changes, the PA instructs the PEP to tear the connection down. Without that channel, a fifteen-minute token means an attacker keeps access for up to fifteen minutes after you have detected them, which is a long time.
The PA communicates with PEPs over the control channel, which must be separate from application traffic and independently secured, usually with mutual TLS and certificates from an internal PKI. If an attacker can forge control-plane messages, they do not need to attack anything else.
The Policy Administration Point, and a note on vocabulary
The term PAP does not come from NIST SP 800-207. It comes from `XACML`, the OASIS standard for attribute-based access control that predates zero trust by more than a decade. Because most commercial zero trust products borrowed the XACML vocabulary, engineers routinely mix the two sets of terms in the same sentence, which is why this part gets confusing.
The Policy Administration Point is where policy is authored, versioned, tested, and published. It is the console, the API, or the Git repository holding policy-as-code. Nothing in the request path touches it. It is a management surface, and it feeds the decision point rather than participating in decisions.
XACML also defines the Policy Information Point (PIP), which supplies attribute values at evaluation time, and the Policy Retrieval Point, which stores the policies the decision point loads. NIST does not name these separately; it lumps them into "supporting components" and "data sources." The mapping is straightforward once you see it:
| XACML term | NIST SP 800-207 equivalent | What it actually does |
|---|---|---|
| PEP | Policy Enforcement Point | Sits in the traffic path, allows or blocks, holds the session |
| PDP | Policy Engine plus Policy Administrator | Decides, then issues and revokes the credential that carries the decision |
| PAP | Not named; part of policy management | Where humans write and publish policy |
| PIP | Data sources and supporting components | Supplies live attributes at evaluation time |
| PRP | Policy database | Stores published policy for the engine to load |
The PAP deserves more security attention than it usually gets, because it is the highest-value target in the entire architecture. An attacker who compromises a PEP gets one path. An attacker who compromises the PAP writes themselves a policy that grants everything and looks legitimate to every audit downstream. Treat policy changes like production deployments: version control, peer review, staged rollout, and a separate identity system for administrators.
Policy Information Points: where the signal comes from
Dynamic policy is only as good as the attributes available at evaluation time. NIST enumerates the usual suppliers, and each one answers a different question.
The identity management system answers who this is and what they are entitled to, including group membership, employment status, and the strength and recency of authentication. The continuous diagnostics and mitigation (CDM) system answers what state the device is in: enrolled, patched, encrypted, running approved software, or flagged. The enterprise PKI answers whether the certificates presented by subjects, devices, and services are valid and unrevoked.
Then come the risk sources. Threat intelligence feeds supply external context such as known-malicious infrastructure and newly weaponized vulnerabilities. The SIEM and raw activity logs supply internal context: what this account has been doing, what the PEPs have been seeing, and which alerts are currently live. Data access policies and classification supply the sensitivity of what is being requested, and industry compliance systems supply the regulatory constraints that must hold regardless of what anyone approves.
A policy that draws on these looks less like a firewall rule and more like a small declarative document. Here is an illustrative one in JSON, of the kind a PAP would publish and a PE would evaluate:
{
"resource": "reporting-dashboard.internal",
"allow_if": {
"subject.group": "contractors-2026q3",
"subject.auth": "mfa_within_8h",
"device.managed": true,
"device.patch_level": "current",
"device.disk_encryption": true,
"risk.score_max": 40,
"network.geo": ["US", "PH"]
},
"grant": {
"scope": "read",
"session_ttl": "15m",
"reevaluate_on": ["risk_change", "posture_change", "new_resource"]
}
}Every key in `allow_if` is answered by a different PIP at evaluation time, and none of the values are stored in the policy itself. The `grant` block is what the Policy Administrator implements: a read-only session lasting fifteen minutes that gets re-checked the moment the device falls out of compliance or the risk score moves. Compare that to the VPN account from the opening scenario, which granted network reachability with no scope, no expiry, and no conditions.
A request, end to end
Follow one request through the whole system. The contractor from the opening opens the reporting dashboard.
The device agent intercepts the request before it reaches the network, because the dashboard's hostname resolves to the local PEP rather than to a routable address. The PEP has no standing authorization for this subject and this resource, so it does not forward anything. It packages the context it can see: the subject's identity assertion, the device identity and posture attestation, the target resource, and the request metadata.
That context goes to the PDP over the control channel. The Policy Engine loads the applicable policy and queries its information points: the directory for group membership and authentication recency, the CDM system for patch and encryption state, the threat feeds and SIEM for anything current against this account or this source. The trust algorithm evaluates the hard criteria first, then computes a score against the resource's sensitivity.
The decision is allow, with constraints: read scope, fifteen-minute session, re-evaluation on posture change. The Policy Administrator implements it by issuing a short-lived session credential and instructing the resource-side gateway to accept a connection carrying that credential. Only now does a path exist.
The PEP establishes the session, and traffic flows encrypted end to end. Throughout the session the PEP streams telemetry back, and the PDP keeps evaluating. When the contractor's laptop misses a patch deadline mid-afternoon, the CDM system's state changes, the engine re-runs, the answer flips, and the PA tells the PEP to drop the session. No human is involved, and the contractor's next request is denied at the same enforcement point that granted the last one.
Where to put the enforcement point
The decision logic is the same everywhere. What varies is where the PEP physically lives, and that choice is usually forced by what the resource can support. NIST describes four deployment variants, and most organizations run all four at once.
The device agent and gateway model puts half the PEP on the endpoint and half in front of the resource. It gives the richest device signal and the tightest control, and it requires managed devices, which rules it out for contractors and personal hardware.
The enclave gateway model puts one gateway in front of a group of resources that cannot be individually fronted, typically a legacy application suite or a data center segment with hard-coded internal dependencies. It is a compromise: everything inside the enclave shares one enforcement boundary, so you get zero trust up to the enclave and implicit trust within it.
The resource portal model puts a single reachable gateway in front of everything and requires no client software at all. This is what makes contractor and BYOD access workable. The trade-off is visibility: without an agent, you cannot see much about the device beyond what the browser volunteers.
The application sandboxing model runs the approved application in an isolated container on the device, so enterprise data never touches the rest of the machine. It protects against a compromised endpoint better than the others, and it costs the most in packaging and maintenance.
Failure modes and fault tolerance
The decision point becomes the new perimeter
Every access request in the organization now depends on the PDP. If it is unavailable, nobody works. This is the single largest operational objection to zero trust, and it is a real one.
The mitigations are conventional distributed systems practice applied somewhere unusually sensitive. Run the PDP as a replicated, regionally distributed service. Cache decisions at the PEP with a short TTL so a brief control-plane outage degrades rather than halts. Decide deliberately whether each PEP fails closed or fails open, and accept that the answer differs by resource: a payroll database should fail closed, a status page probably should not.
Subversion of the decision process
Whoever controls policy controls the organization. An attacker with PAP access does not need to defeat any enforcement; they write a rule that grants themselves access and it will look correct to everything downstream. Administrator accounts for the control plane should be separated from ordinary accounts, protected with phishing-resistant authentication, and subject to dual authorization for policy changes. Policy history must be immutable and monitored, since a diff is often the only evidence you will get.
Denial of service and route manipulation
If the PDP or a PEP can be flooded or its traffic can be redirected, access stops. Cloud-hosted decision points spread across providers reduce the blast radius, and traffic to the control plane should be filtered well before it reaches the decision logic. Route hijacking against the control channel is harder to fix, which is one more argument for mutual authentication on every control message rather than reliance on network path.
Stolen credentials and the insider
Zero trust reduces the value of a stolen credential; it does not zero it out. Multi-factor authentication makes theft harder, and per-session, least-privilege grants shrink what a stolen session reaches. What actually catches the well-credentialed attacker is contextual evaluation: an account behaving unlike itself, at an unusual hour, pulling unusual volume. That detection only exists if the behavioral signals in the earlier section are actually wired into the engine.
Loss of network visibility
When everything is encrypted end to end, traditional deep packet inspection stops working. You are left with metadata: who talked to what, when, how much, and how often. Some organizations respond by terminating TLS at the gateway, which restores visibility and creates a very attractive target holding plaintext for the entire enterprise. Machine learning over encrypted traffic metadata is the alternative most large deployments settle on.
The signal stores become the crown jewels
To make good decisions the organization now holds a detailed, centralized picture of every asset, every subject, and every access pattern. That store is a superb reconnaissance target. It needs the same protection as the most sensitive resource it guards, and access to it should itself run through a PEP.
Non-person entities
Service accounts, automation, CI pipelines, and increasingly autonomous agents are all subjects, and they authenticate without a human to challenge. They need workload identity rather than shared secrets, which is what standards like `SPIFFE` address, and their credentials should be short-lived and automatically rotated. They also break behavioral analytics in a specific way: automated subjects are supposed to behave repetitively, so anomaly detection tuned for humans produces noise. Tune separately, and be careful about letting automated processes approve access for other automated processes.
Lock-in and interoperability
If policy is expressed in a proprietary format and signals arrive through proprietary APIs, changing vendors means rewriting the security model. Prefer standard identity protocols such as `OIDC` and `SAML`, keep policy in a portable declarative form under version control, and treat any component that cannot export its state as a liability.
Getting there from here
Nobody deploys this all at once, and the organizations that try usually stall. The sequence that works starts with inventory: which subjects exist, which assets exist, and which workflows actually matter to the business. You cannot write per-resource policy for resources you cannot enumerate.
From there, pick one workflow with a contained blast radius and real value, usually remote access to a single internal application. Deploy the enforcement point in monitoring mode first, so the engine evaluates and logs decisions without acting on them. That produces the data needed to tune policy before anyone gets locked out of anything.
Then expand by workflow rather than by technology. Each iteration adds resources behind enforcement points and removes another reason for the old flat network to exist. The perimeter shrinks as a byproduct rather than as a project.
The complete picture
Assembled, the architecture is a small number of parts wired in a specific order: signals feed the engine, the engine decides, the administrator issues, the enforcement point acts, and the enforcement point's observations become signals again.
Summary
The components are easy to memorize and easy to misread. PEP enforces, PE decides, PA implements and revokes, PAP is where policy is written, PIPs supply the facts. Draw them once and the architecture looks like an authorization system with extra steps.
The insight that makes it more than that is the treatment of trust as perishable. In the perimeter model, trust is a state you enter and remain in until you leave the building. In zero trust, trust is a computed value with an expiry, recomputed continuously against evidence that keeps arriving. That is why the feedback loop from PEP telemetry back to the signal layer is not an operational nicety but the load-bearing part of the design; remove it and you have rebuilt a firewall with a directory attached.
It also reframes what a breach costs. If a credential is stolen, the attacker inherits one narrow, short-lived, continuously re-evaluated grant instead of a network address. The contractor's laptop from the opening still reaches the reporting dashboard. It reaches nothing else, and only for as long as it stays compliant.
Related on this blog: Architecture series