A policy decision point (PDP) is the component that evaluates an access request against policy and returns an authorization decision. It receives a description of the requester, the action, the target resource and the surrounding conditions, evaluates the applicable rules, and answers allow or deny. The PDP never touches the resource itself. A separate policy enforcement point (PEP) sits in the request path and carries that answer out. Decision in one place, enforcement in another: that separation is the structural idea behind dynamic authorization and the organizing principle of zero trust architecture.
Where the policy decision point sits in NIST SP 800-207
NIST Special Publication 800-207, Zero Trust Architecture, published in August 2020, names three core logical components.
The policy engine (PE) is responsible for the ultimate decision to grant access to a resource for a given subject, combining enterprise policy with external input through what SP 800-207 calls a trust algorithm. The policy administrator (PA) establishes or shuts down the communication path between a subject and a resource, and generates the session-specific credential the subject uses. The policy enforcement point (PEP) enables, monitors and eventually terminates the connection between a subject and an enterprise resource.
SP 800-207 states directly that the policy decision point is broken into two logical components: the policy engine and the policy administrator. The PDP is therefore an architectural role, not a single product. SP 800-207 also keeps the control plane, where these components exchange decisions, logically separate from the data plane carrying application traffic. NIST published SP 1800-35, Implementing a Zero Trust Architecture, as a build-level companion, final on 10 June 2025.
The XACML lineage of PDP and PEP
Policy decision point and policy enforcement point are XACML terms. The eXtensible Access Control Markup Language reached OASIS Standard status at version 3.0 on 22 January 2013, with earlier versions from the early 2000s.
| Entity | XACML definition |
|---|---|
| Policy decision point (PDP) | The system entity that evaluates applicable policy and renders an authorization decision |
| Policy enforcement point (PEP) | The system entity that performs access control by making decision requests and enforcing authorization decisions |
| Policy administration point (PAP) | The system entity that creates a policy or policy set |
| Policy information point (PIP) | The system entity that acts as a source of attribute values |
| Context handler | The entity that converts native request formats into canonical form and retrieves attributes from PIPs |
XACML also fixes a detail informal usage drops: a PDP returns one of four values, not two. Permit and Deny are answers. NotApplicable means no policy matched. Indeterminate means the PDP could not evaluate, typically because an attribute was missing or a source failed. A fail-closed deployment treats both as deny; a deployment that treats them as permit has a policy gap shaped exactly like a working system.
XACML separates obligations, which the PEP must perform alongside enforcement, from advice, which the PEP may ignore. The XML encoding of XACML has largely fallen out of use. The architecture it named did not.
What an authorization decision contains
An authorization decision is a data structure, and what it carries determines what can be done with it. The minimum is an effect: allow or deny. A decision safe to transport, cache and audit carries more.
Binding fields name the subject, action and resource the decision was made about; a decision that does not name the exact object cannot be replayed safely. Reasons record which rule produced the effect. A policy version identifier pins the policy state evaluated. A validity window bounds how long the decision may be relied on. Obligations list actions the enforcement point must perform. Integrity protection, normally a signature, proves the decision came from the PDP unaltered.
The OpenID Foundation's AuthZEN Authorization API 1.0, approved as a Final Specification on 12 January 2026, encodes the common case: a required boolean decision plus an optional context object conveying reasons and obligations.
How an authorization decision is transported to the enforcement point
An authorization decision has to travel from the policy decision point to the policy enforcement point. Three transport patterns dominate, and each buys freshness or availability at the other's expense.
| Transport pattern | How the decision reaches the PEP | What it trades |
|---|---|---|
| Remote evaluation per request | The PEP calls the PDP over the network for every request | Freshest attribute values; adds latency and a hard availability dependency |
| Co-located or embedded PDP | A PDP instance runs alongside the PEP, with policy and attribute data distributed to it | Low latency and local survivability; decisions reflect the last distribution, not the current instant |
| Signed decision token | The PDP issues a short-lived signed decision the PEP validates without calling back | Works disconnected and at the edge; access persists until expiry, setting a floor on revocation latency |
AuthZEN standardizes the first pattern as an HTTP interface: an access evaluation request carrying subject, action and resource objects plus an optional context object for environmental attributes such as time and location, with a batch endpoint for several requests at once. A standard wire format lets enforcement points and decision points from different vendors interoperate.
How long an authorization decision lives
The lifetime of an authorization decision is the interval during which an enforcement point acts on it without asking again. That interval is an engineering choice, and it is the same number as the worst-case revocation delay.
Session-scoped decisions authorize once at login, then permit every subsequent action inside the session; lifetime runs to hours, and an attribute change during that window has no effect on work in progress. Short-lived decisions invert the default: validity of seconds or minutes means a withdrawn clearance or a changed device posture takes hold on that timescale, at the cost of more evaluations. Per-action decisions push the interval to zero.
There is no correct value in the abstract, only an explicit trade between evaluation cost and revocation latency. Systems that never state the number have chosen the longest one by accident.
How revocation works when authorization is decided dynamically
Revocation in a dynamic authorization system means the next evaluation returns deny. No message reaches out and reverses access already granted. Three conditions have to hold.
First, the attribute change has to reach the sources the PDP reads; a clearance withdrawn in a system the PDP never queries revokes nothing. Second, a new evaluation has to occur before further access. A session-scoped design continues until the session ends or is terminated, which is why SP 800-207 gives the policy administrator the job of shutting down the communication path. Third, cached and token-carried decisions have to expire. The longest-lived cached decision defines actual revocation latency, whatever the PDP now says.
Enforcement placed at decrypt time changes the arithmetic, because every attempt to open an object is a new request rather than a continuation of an old session. That placement is covered in How TDF Enforces Policy at Decrypt Time, and the limit of network-scoped enforcement in Why Network Zero Trust Stops at the Data Boundary.
What dynamic authorization is
Dynamic authorization decides access at request time from current attribute values, rather than at provisioning time from a stored grant. A static model computes the answer in advance as a list entry, a group membership or a role assignment, and that answer persists until someone edits it. A dynamic model computes the answer when the request arrives.
Dynamic authorization requires five things: attributes describing subjects, resources and conditions; policy written against those attributes; a decision point that evaluates it; an enforcement point positioned to withhold access; and a record of each decision. Remove any one and the model degrades to a static grant with extra steps. Which policy model the decision point evaluates is a separate question, set out in ABAC, RBAC and ReBAC: Which Model Answers Which Question.
What a policy decision point does not do
A policy decision point does not authenticate. It consumes an already-authenticated subject identity, so a compromised authentication path produces correct decisions about the wrong subject.
A policy decision point does not enforce. A decision no enforcement point acts on is a recommendation, and placement of the PEP determines what the control actually covers.
A policy decision point does not correct bad attributes. Policy evaluated against a stale clearance or a wrong classification is enforced faithfully and wrongly.
A policy decision point does not govern content after release, and it does not remove the availability dependency. Fail-closed defaults mean an unreachable decision point denies access, which is correct behavior and is still an outage.
Frequently asked questions
What is a policy decision point in zero trust architecture?
In zero trust architecture, the policy decision point evaluates each access request against policy and returns allow or deny. NIST SP 800-207 divides it into a policy engine, which makes the decision using a trust algorithm over enterprise policy and external input, and a policy administrator, which establishes or tears down the session path. A separate policy enforcement point carries the decision out.
How do zero trust systems make real-time authorization decisions?
A zero trust system sends the subject, the action, the resource and the current conditions to a policy decision point at the moment of the request. The decision point reads attribute values from policy information sources, evaluates the applicable rules, and returns an effect with reasons. The enforcement point then allows or blocks the operation. Nothing is precomputed at provisioning time.
What is dynamic authorization?
Dynamic authorization decides access at request time from current attribute values rather than from a grant recorded in advance. A static access control list answers from what was written when the entry was created. A dynamic system answers from what is true now, including device posture, location, purpose of use and object sensitivity. Revoking an attribute changes the next answer without editing any list.
What is the difference between a policy decision point and a policy enforcement point?
A policy decision point evaluates policy and produces an answer; it sits outside the request path and touches no resource. A policy enforcement point sits inside the request path, asks for that answer, and allows or blocks the operation accordingly. A decision point can be wrong and the system still fails safely if the enforcement point is correctly placed. The reverse is not true.
What happens when the policy decision point is unreachable?
Behavior on an unreachable decision point is a configuration choice with two options. Fail-closed denies access, preserving the security property and creating an availability outage. Fail-open permits access, preserving availability and voiding the control precisely when the system is least healthy. Deployments that must keep working while disconnected pre-distribute short-lived signed decisions rather than failing open.
How Lattix implements a policy decision point
The Lattix policy decision point evaluates attribute-based access control (ABAC) across subject, device, environment and geography, purpose of use, network posture, risk and data-object attributes. It returns a signed, short-lived decision carrying allow or deny, the reasons, the policy version hash and the object identifier. The Lattix policy enforcement point acts at decrypt time, placing enforcement below whatever application, gateway or storage service sits in the path. Defaults are fail-closed and revocation propagates to deny. Content identifiers and Merkle-tree lineage records make decision history queryable. The same posture deploys across cloud, regional hub, tactical edge and air-gapped environments. Governing non-human requesters is covered in How to Give an AI Agent Access to Sensitive Data Safely.