Policy Decision Point (PDP)

The PDP does not operate in a vacuum. It dynamically fetches real-time context from external Policy Information Points (PIPs) to build a comprehensive risk picture before deciding.

• User Attributes: Group membership, role, clearance level from an identity provider.
• Device Posture: OS patch level, disk encryption status, presence of endpoint detection.
• Environmental Signals: Geolocation, network zone, time of day, threat intelligence feeds.

The execution counterpart to the PDP. While the PDP makes the logical allow/deny decision, the PEP is the network component that activates and enforces that decision on the wire. The PEP intercepts every access request, forwards the authorization query to the PDP, and then opens or blocks the connection based on the response. In a service mesh, the sidecar proxy typically functions as the PEP, enforcing mTLS identity and applying the PDP's verdict to each east-west packet flow.

The policy evaluation paradigm that powers modern PDPs. ABAC makes authorization decisions by evaluating attributes across four dimensions:

• Subject attributes: User role, department, clearance level, device posture
• Resource attributes: Data classification, file type, owner, creation date
• Action attributes: Read, write, delete, execute
• Environmental attributes: Time of day, geolocation, network zone, threat level The PDP combines these attributes against a policy-as-code ruleset to issue a dynamic, context-rich decision rather than relying on static role assignments.

The operational principle that distinguishes zero-trust from perimeter-based security. Unlike traditional models that authenticate once at session start, continuous verification requires the PDP to re-evaluate trust throughout the entire session lifecycle. If a user's device posture degrades, geolocation shifts, or behavior becomes anomalous, the PDP can revoke access mid-session. This is implemented through short-lived tokens, streaming telemetry feeds into the PDP, and real-time risk scoring engines that trigger re-authentication challenges.

The engineering practice of defining PDP authorization rules in machine-readable, version-controlled languages rather than GUI-configured firewall rules. Common policy languages include:

• Open Policy Agent (OPA) Rego: Declarative policy language for cloud-native stacks
• XACML: XML-based standard for ABAC policy expression
• Cedar: AWS's open-source policy language for verified permissions PaC enables CI/CD integration, automated testing of policy changes, and audit trails showing exactly who modified which access rule and when—critical for compliance frameworks like SOC 2 and FedRAMP.

The risk-signal feed that enriches PDP decision-making. UEBA systems apply machine learning models to establish behavioral baselines for every user and service account, then flag deviations as risk scores. These scores become environmental attributes consumed by the PDP. For example, if a user who typically accesses resources from Chicago during business hours suddenly attempts access from a foreign IP at 3 AM, the UEBA system raises the risk score, and the PDP can dynamically escalate authentication requirements or deny the request outright.

A pre-authentication security protocol that hides the PDP and protected resources from unauthorized scanners. Before any TCP connection is established, the client must transmit a cryptographically signed packet containing authentication credentials. The SPA gateway validates this packet and only then dynamically opens the firewall port for the authenticated client's IP. This makes the PDP and all backend services invisible to port scans and unauthenticated reconnaissance, implementing a 'dark' network posture where infrastructure cannot be attacked if it cannot be seen.