Skip to main content
Identity Authority
Category: Access Control Models

Policy-Based Access Control

Also known as:
Simply put

Policy-Based Access Control (PBAC) is a way of deciding who can access systems, applications, or resources based on centrally defined rules, or policies, set by an organization. Instead of hardcoding permissions individually, access decisions are evaluated dynamically against these policies. This approach is intended to give organizations a more flexible and centralized way to govern access.

Formal definition

PBAC is an access control model in which permissions are expressed as policies that determine which principals may access which resources, with access decisions evaluated dynamically against centrally defined organizational rules. In many deployments, PBAC combines the business roles of users with policy conditions to determine access privileges, positioning it as a strategy that can incorporate role information alongside policy logic. As an authorization model, PBAC governs what a principal is permitted to do and is distinct from authentication; the specific policy language, attributes considered, and enforcement architecture vary by vendor and deployment.

Why it matters

As organizations scale, permissions managed through static assignments or embedded application logic become difficult to audit, reason about, and change consistently. PBAC addresses this by expressing access rules as centrally defined policies that are evaluated dynamically at decision time, which can reduce the drift and inconsistency that accumulate when permissions are hardcoded across many systems. For security architects and identity governance leads, centralizing authorization logic also creates a clearer surface for review and change control, since policies can be inspected and updated in one place rather than reverse-engineered from scattered configuration.

PBAC is particularly relevant where access decisions need to reflect organizational context rather than fixed grants alone. Because many PBAC deployments combine the business roles of users with policy conditions, the model can incorporate role information while still allowing access to be governed by broader organizational rules. This flexibility is valuable in environments where the same role should yield different outcomes depending on circumstances defined by policy. It is worth noting that PBAC governs authorization only, what a principal is permitted to do, and does not perform authentication; verifying who a principal is remains a separate step handled elsewhere in the access flow.

Who it's relevant to

Security architects
Architects designing authorization systems use PBAC to centralize access logic as policies rather than embedding permissions across applications. This supports a more flexible and consistent authorization strategy, though the enforcement architecture and policy language must be chosen to fit the specific deployment.
IAM engineers
Engineers implementing PBAC work with the dynamic evaluation of access requests against centrally defined policies, and often with models that combine business roles and policy conditions. They must account for how a given vendor expresses policies and evaluates them at decision time.
Identity governance leads
Because PBAC centralizes access rules as inspectable policies, governance leads gain a clearer basis for reviewing how access is granted. Note that PBAC concerns runtime authorization decisions and is distinct from governance lifecycle activities such as access reviews and certification, which remain separate concerns.
Compliance officers
Centrally defined policies provide a documented, reviewable expression of who may access which resources, which can support demonstrating that access is governed by organizational rules. The degree of auditability depends on the specific implementation and its policy tooling.

Inside PBAC

Policy
A declarative rule set that expresses access decisions in terms of conditions, subjects, resources, actions, and context. Policies are typically defined centrally and evaluated at runtime rather than being hard-coded into applications.
Policy Decision Point (PDP)
The runtime component that evaluates applicable policies against a request and its context to render a permit or deny decision. This is an enforcement-time concern, distinct from governance activities such as certification or provisioning.
Policy Enforcement Point (PEP)
The component that intercepts an access request, delegates the decision to the PDP, and enforces the returned decision. The PEP enforces but does not itself decide.
Policy Information Point (PIP)
A source that supplies additional attributes or contextual data (for example subject attributes, resource metadata, or environmental signals) that the PDP needs to evaluate a policy.
Policy Administration Point (PAP)
The interface or component used to author, manage, and maintain policies. Depending on the deployment, this is where policy authors define and version the rules the PDP later evaluates.
Attributes and context
The subject, resource, action, and environmental values that policies reference at decision time. Because PBAC policies often consume attributes, it overlaps in practice with ABAC concepts, though PBAC centers the policy as the primary abstraction.

Common questions

Answers to the questions practitioners most commonly ask about PBAC.

Is PBAC just a newer name for ABAC?
No, though the two are closely related and often overlap in practice. ABAC (attribute-based access control) makes decisions by evaluating attributes of the subject, resource, action, and environment. PBAC (policy-based access control) centers on expressing access rules as centrally managed policies that a policy engine evaluates at runtime. Those policies frequently consume attributes, so many PBAC implementations are effectively ABAC expressed through a policy language and central policy management. The distinction people typically draw is one of emphasis: PBAC foregrounds the policy as the unit of authoring, governance, and versioning, while ABAC foregrounds the attributes that policies evaluate. Depending on the vendor and how terms are used, the line between them can blur, and neither should be presented as universally superior to the other or to RBAC.
Does adopting PBAC mean we should get rid of roles and RBAC entirely?
Not necessarily. PBAC does not inherently replace RBAC; in many deployments a role is simply one attribute among several that a policy evaluates. Policies can reference roles, group memberships, attributes, and relationships together. Some organizations move toward policy-based decisions to handle context and fine-grained conditions that roles alone express awkwardly, but roles often remain a useful and auditable construct. Which model fits best depends on your access requirements, governance needs, and operational maturity rather than a general claim that one model supersedes another.
Where does PBAC fit in the PDP/PEP/PIP architecture?
PBAC is typically implemented through the policy decision point (PDP) that evaluates policies, the policy enforcement point (PEP) that intercepts an access request and enforces the PDP's decision, and one or more policy information points (PIP) that supply the attributes or contextual data a policy needs. In this pattern the PEP forwards a request to the PDP, the PDP evaluates applicable policies, retrieving additional data from PIPs as required, and returns a decision the PEP enforces. The exact division of responsibilities and whether these components are separate services or collapsed into one runtime varies by product and deployment.
How does PBAC relate to identity governance concerns like access reviews and segregation of duties?
PBAC is primarily a runtime enforcement approach: it determines whether a given request is permitted at the moment it is made. Identity governance and administration (IGA) concerns such as provisioning, access certification, periodic reviews, and segregation-of-duties analysis are generally separate from that real-time decision. That said, the same policies and attributes can inform governance processes, and centrally managed policies can make access logic more transparent for review. Treat the two as complementary but distinct: authoring and enforcing runtime policy is not the same as certifying entitlements or attesting to appropriate access over a lifecycle.
What makes attribute quality and PIP reliability critical to a PBAC deployment?
Because PBAC decisions depend on the attributes and contextual data supplied at evaluation time, the correctness, freshness, and availability of that data directly affect authorization outcomes. Stale, missing, or inconsistent attributes from a policy information point can cause a policy to grant or deny access incorrectly. In most deployments this means teams must consider attribute sourcing, caching behavior, latency, and what the PDP does when a required attribute is unavailable. These operational characteristics vary by implementation and are worth validating explicitly rather than assuming.
How should policies be tested and managed as they change over time?
Because policies are the primary unit of authoring in PBAC, most mature deployments treat them like other critical configuration or code: version them, review changes, and test them against representative request scenarios before deployment. Policy changes can alter access decisions broadly, so testing typically covers both intended grants and intended denials, including edge cases where attributes are missing. The specific tooling for authoring, simulating, and versioning policies depends on the vendor or policy language in use, and the availability of such capabilities should be confirmed for your chosen implementation rather than assumed.

Common misconceptions

PBAC is just a rebranding of RBAC with a different name.
PBAC expresses access decisions as declarative policies that can reference attributes, relationships, and context, whereas RBAC assigns permissions through roles. RBAC role assignments can be one input to a PBAC policy, but the models are distinct and neither is universally superior; the right choice depends on the deployment.
PBAC handles the full identity lifecycle, including provisioning and access certifications.
PBAC is fundamentally a runtime authorization approach centered on policy evaluation and enforcement (PDP, PEP, PIP). Provisioning, access reviews, certification, and segregation-of-duties belong to identity governance and administration and are typically separate from PBAC's decision-time enforcement.
Adopting PBAC means the application no longer performs authentication.
PBAC governs authorization, that is what a principal may do. Authentication, verifying who the principal is, remains a separate and prior step. A PBAC policy typically consumes the already-authenticated identity and its attributes as inputs rather than establishing that identity.

Best practices

Externalize authorization logic from application code into centrally managed policies so decisions can be updated without redeploying applications, keeping authoring in a PAP and evaluation in a PDP.
Keep the PEP and PDP responsibilities separate so enforcement points delegate decisions rather than embedding rule logic, which improves consistency across services.
Define clearly which attributes and context sources the PIP will supply, and validate their trustworthiness and freshness, since policy decisions are only as reliable as their inputs.
Keep authorization policies distinct from authentication and identity governance workflows, treating PBAC as a runtime enforcement concern rather than a mechanism for provisioning or certification.
Version, test, and review policies as controlled artifacts, and evaluate default-deny behavior so an absent or unevaluable policy does not inadvertently grant access.
Assess whether a policy-centered model fits your requirements versus RBAC, ABAC, or ReBAC for a given use case, and combine models where appropriate rather than assuming PBAC replaces all of them.
a promotional banner asking how ready are you for PCI DSS 4.0? With a call-to-action to get the checklist now.