The policy decision point (PDP) is a central component in a dynamic authorization solution that evaluates access requests against policies to make authorization decisions. It serves as the “brain” of the access control architecture, determining whether access should be granted or denied based on a combination of attributes, rules, and contextual data.
Why is a PDP important?
As traditional perimeter-based security models become less effective, organizations need dynamic, fine-grained access control to protect resources. The PDP enables centralized and consistent policy enforcement across diverse applications, APIs, data sources, and cloud environments.
A PDP provides many powerful features such as:
- Ensures scalable, enterprise-wide policy evaluation.
- Helps reduce security risks by enforcing least privilege access.
- Supports compliance with data protection regulations.
- Enables Zero Trust by evaluating every access decision in real time.
How does a PDP work?
The role of the PDP is defined in both NIST SP 800-162 (Guide to Attribute-Based Access Control) and NIST SP 800-207, which outlines the Zero Trust architecture. In both models, the PDP is responsible for evaluating access requests based on real-time context and centrally defined policies. The diagram below illustrates how a PDP fits into the broader architecture and how it interacts with other key components.
- User Requests Access: A user initiates an action. For example, attempting to view a specific record (e.g., "View record #123"). This request is intercepted by the Policy Enforcement Point (PEP).
- PEP Sends Authorization Request: The PEP formulates an access request (e.g., “Can Alice view record #123?”) and sends it to the Policy Decision Point (PDP).
- PDP Evaluates Policies: The PDP checks the relevant policies, which are created and managed by the Policy Administration Point (PAP). These policies define the rules for who can access what, and under what conditions.
- PDP Gathers Contextual Data: If more information is needed, the PDP queries the Policy Information Point(s) (PIP) to retrieve additional attributes such as user roles, resource sensitivity, location, or time from connected data sources.
- Access Decision Issued: After evaluating the policies and attributes, the PDP returns a decision to the PEP. For example, “Permit: Alice can view record #123.”
- Access is Granted or Denied: Based on the PDP’s decision, the PEP allows or denies access to the requested resource.
PDP vs. PEP vs. PAP vs. PIP
A PDP does not operate alone. It works alongside several other components responsible for managing policies, supplying information, and enforcing authorization decisions. Together, these components separate authorization logic from the applications and resources being protected.
| Component | What It Does |
| Policy Decision Point (PDP) | Evaluates authorization policies and available attributes to determine whether an access request should be permitted or denied. |
| Policy Enforcement Point (PEP) | Intercepts access requests, sends authorization requests to the PDP, and enforces the resulting decision. |
| Policy Administration Point (PAP) | Provides the capability to create, manage, and maintain the authorization policies evaluated by the PDP. |
| Policy Information Point (PIP) | Provides additional attributes and contextual information that may be required by the PDP to evaluate a policy. |
What information does a PDP evaluate?
A PDP can consider much more than a user's identity or assigned role. It evaluates attributes and contextual information associated with the access request against authorization policies to determine whether access should be allowed.
These inputs typically fall into four categories:
- Subject attributes: Information about the person or machine requesting access. This could include a user's department, job title, security clearance, employment status, group membership, or assigned region. The subject could also be a service, workload, or AI agent rather than a human user.
- Resource attributes: Information about the resource being accessed, such as its owner, classification, geographic region, sensitivity level, record type, or business unit.
- Action attributes: Information about what the subject is attempting to do with the resource, such as view, create, edit, approve, download, share, or delete.
- Environmental and contextual attributes: Information about the circumstances surrounding the request, including time, location, device posture, network, authentication method, risk level, or other contextual signals.
When an access request is made, the PDP evaluates the available attributes against the applicable policy and returns an authorization decision. Because these attributes can change, the resulting access decision can adapt to the current context instead of relying solely on permissions assigned in advance.
Use Cases: Where a PDP Adds Value
Below are common use cases where a PDP provides measurable value by improving security, simplifying compliance, and enabling Zero Trust.
1. Access controls for APIs
Modern applications expose data and functionality via APIs and securing those APIs requires more than just authentication. A PDP enables dynamic authorization decisions based on user identity, role, request context, and API sensitivity.
Example: Only allow a sales manager to update opportunities for their assigned region and only during business hours.
2. Data-level security for analytics
Protecting sensitive data within analytics platforms and data lakes often requires row- or column-level filtering. A PDP can enforce policies that tailor query results to the user's attributes in real time.
Example: Analysts can only view customer records from countries where they are authorized to operate.
3. Conditional access in hybrid or multi-cloud environments
As organizations shift to hybrid and multi-cloud infrastructures, centralized authorization is key to maintaining consistent access control across diverse systems. A PDP ensures policies are enforced regardless of where the resource resides.
Example: Developers can access cloud logs only if they are on a corporate-managed device and connected via VPN.
4. Enforcing least privilege
Applications often rely on coarse role-based controls, leading to over-permissioning. A PDP allows teams to implement least privilege by evaluating contextual policies dynamically, therefore reducing risk without impacting productivity.
Example: A finance user can approve invoices only under a specified dollar threshold unless additional approval is granted.
5. Supporting Zero Trust initiatives
Zero Trust requires every access decision to be verified continuously and contextually. A PDP operationalizes this by evaluating policies in real time without relying on implicit trust.
Example: A remote user’s access to sensitive data is denied if their device posture fails a security check.
Axiomatics’ PDP
Axiomatics’ PDP is called the Access Decision Service (ADS) is a cloud-native authorization engine designed for flexible deployment across microservices, cloud, or hybrid architectures within the Axiomatics platform. It evaluates every access request against the policies and attributes defined in the Authorization Hub and returns a decision to the application through a REST API built on the XACML 3.0 standard.
Rather than embedding authorization logic directly into application code, organizations can externalize authorization decisions to ADS. Applications provide the relevant details of an access request, and the PDP evaluates those inputs against policy to determine what the requesting user, service, workload, or AI agent is allowed to do.
Policy evaluation at runtime
ADS evaluates authorization policies at runtime using attributes associated with the subject, resource, action, and environment.
For example, an authorization request might ask: Can Alice approve transaction #8472?
The PDP could evaluate attributes such as:
- Subject: Alice, Finance Manager, EMEA
- Action: Approve
- Resource: Transaction #8472, €25,000, Germany
- Environment: Managed device, corporate network
ADS evaluates these attributes against the applicable authorization policies and returns a decision to the requesting Policy Enforcement Point.
This allows authorization decisions to reflect the current context of the request rather than relying solely on static permissions or application-specific roles.