PBAC (Policy-Based Access Control)
Policy-Based Access Control (PBAC) is an access control model in which a policy decides each request at the moment it is made, instead of the application checking an entitlement that someone granted in advance. The rules live in one governed place rather than in the code of every application, and they can combine roles (Role-Based Access Control, RBAC), attributes of the user, the resource and the context (Attribute-Based Access Control, ABAC), and relationships between them (Relationship-Based Access Control, ReBAC). Organizations turn to PBAC when role-based access has grown into more roles than anyone can review, and it moves the hard part of authorization from granting access to keeping accurate the attributes that policies read.
The model separates four functions, which NIST SP 800-162 names and policy engines' documentation uses. A policy enforcement point (PEP) in the application or gateway intercepts a request and asks. A policy decision point (PDP) evaluates the policy and answers permit or deny. A policy information point (PIP) supplies the attributes the policy refers to, from the directory, the HR system or device management. A policy administration point (PAP) is where policies are written and published, which Policy as Code turns into a repository and a pipeline. OpenID AuthZEN standardizes the call between enforcement and decision point, so applications do not have to change when the decision engine does.
When a Policy Beats a Role
RBAC grants access by job function. A user is assigned roles, the roles carry permissions, and the application checks whether the user holds the permission. That works while access follows the organization chart. It stops working when access depends on something a role cannot express: whether this claims handler is assigned to this claim, whether the document is classified above the reader's clearance, whether the request comes from a managed device, whether the customer has consented. Each such condition becomes another role, and the roles multiply along every dimension at once, one per job, region, business unit and data classification. The result is role explosion, and it turns recertification into a rubber stamp, because no reviewer can tell what EMEA-Claims-Senior-Restricted-RW grants or whether its holder still needs it.
A policy states the condition once. "A claims handler may read a claim assigned to their team, in their region, from a managed device" is one rule over three attributes, and it stays correct as people change teams, provided the attributes change with them. Relationship-based models go further for data whose sharing follows ownership and hierarchy, such as documents in folders, projects in portfolios or accounts held by a household: the policy asks whether a path of relationships connects the subject to the resource, which Zanzibar-style engines answer from a graph of relationship tuples. Roles survive in all of these models. Job function remains one attribute among several, and most deployments are hybrids in which a coarse role decides which application a user reaches and a policy decides what they may do inside it.
RBAC remains the better choice where access follows stable job functions, where the number of roles stays manageable, and where the target system cannot ask anyone for a decision, which is true of many packaged applications, databases and operating systems. There, PBAC costs more than it saves. It needs a decision point in the path of every request, attribute feeds that have to be accurate and current, people who can write and test policies, and an audit that works differently. These costs pay off where decisions depend on data about the resource or the context, where the same rules have to hold across many applications, and where subjects change faster than anyone can administer roles for them. Workloads and AI agents are that case. An agent acting for a user needs a decision that combines what the agent may do with what the user may do, for this action on this resource, and the token exchange that carries both identities to the resource only helps if a policy reads both.
Migrating Away from Role Explosion
Few organizations start with PBAC. They arrive at it from an RBAC estate that no longer scales, and the migration that works goes one application at a time. It starts where the explosion is worst, usually a business application with hundreds of roles whose names encode region, unit or data class. Those roles are taken apart: the part that describes a job function stays a role, and each qualifier becomes an attribute with a named source. A policy is then written to reproduce today's decisions from those attributes and run in shadow mode, evaluated on every request alongside the existing entitlement check, with every disagreement logged. Each disagreement is either an entitlement nobody should have had, which is a finding for the access review, or an attribute that is wrong or missing, which is a finding for whoever owns it. Enforcement follows once the disagreements are understood, and the old roles are retired after that.
Two limits shape the plan. PBAC covers only the systems that call the decision point. An application that checks its own entitlement table keeps its standing entitlements however good the central policy is, so the share of applications that ask the PDP is a coverage figure worth reporting, and Zero Standing Privileges in such a system still needs a mechanism that grants and revokes. The policies are also code from the first application on, and they need tests, review and a release process before the second application depends on them.
Attributes Are Where PBAC Fails
A policy is only as correct as the attributes it reads. A department that HR updates a week after a transfer keeps the old department's data open for that week, and the decision log records a correct permit. A missing manager for a cost center breaks every rule that depends on one. A device compliance flag that the endpoint service stopped sending makes a condition always true or always false, depending on how the policy treats an absent value. None of this raises an error. The decisions follow the policy exactly and are still wrong.
Every attribute a policy uses therefore needs what a role used to have: an owner, one authoritative source, a defined freshness and a rule for what happens when the value is missing. Most of the delivery is plumbing the IAM team already runs. SCIM carries attributes to directories and applications, and the Shared Signals Framework pushes the changes that cannot wait for the next synchronization, such as a revoked session or a device that fell out of compliance. For agents, the subject data comes from the agent registry that records their owner and purpose.
Once policies read an attribute, the right to change it is a right to grant access. Whoever can set the department or the clearance in the HR system or the directory can bring a person into scope of every policy that tests it, without filing a single access request. Write access to policy-relevant attributes belongs under the same governance as administrative roles, reviewed and logged, and a change without a matching business event is a signal for Identity Threat Detection and Response. Attributes the subject asserts about itself, such as a location reported by the client, deserve less weight than attributes from an authoritative source, and the policy has to be able to tell them apart.
What an Auditor Can See
RBAC gives an auditor a list. Who holds a role, who approved it and when it was last reviewed are rows in a table, and an access review walks the table. PBAC answers one audit question much better than a table can and another one worse.
The better one is "why was this allowed?" A PDP decides every request and can log every decision with the subject, action and resource, the result, the policy version that produced it and the attribute values it read. That record explains a single request in a way an entitlement table never could, including a request an attacker made with a valid account. It only works if the log keeps the policy version and the attribute values, since a log of bare permits cannot be replayed once either has changed. The log also holds personal data at a volume entitlement tables never did, so its retention period has to be set on purpose instead of left at the logging pipeline's default.
The worse one is "who can access this?" There is no list to hand over. The answer is computed from the policy and the current attributes, and it changes whenever an attribute does. Producing it takes a PDP that can search, which AuthZEN specifies as optional endpoints, or an analysis of the policy itself. Access reviews change shape with it: reviewers certify the policies, through the change review that Policy as Code provides, and the attribute assignments that feed them, such as who is recorded as manager of which cost center or who holds a clearance. Reviewing people against roles remains for whatever access is still granted by role. Agree this change with the auditors before the first application goes live, since a review cycle that goes looking for a list to sample will not find one.
When the Decision Point Is Down
Externalizing decisions puts the PDP in the path of every protected request, so its availability becomes the availability of every application that asks it. The architecture follows from that. Decision points run close to the enforcement points, as a local service or a sidecar, and receive policy as versioned bundles, so that requests are still decided when the central administration point is unreachable. Where the policy allows it, decisions can be cached for a short, fixed time, at the price of acting on attributes that may have changed in the meantime.
What an enforcement point does when no decision arrives is a policy choice, made per application, and not the default of whichever enforcement library was installed. Failing closed, denying when the PDP cannot answer, is the safe default and the right one for writes, privileged actions and sensitive data. Failing open is defensible only for named low-risk actions where an outage would do more harm than an unauthorized read, and each permit granted that way should be logged as such. The same choice recurs one level down, when the PDP answers but an attribute source does not: deny, or use the last known value up to a stated age. A design that fails closed also needs a way in when it fails, which means break-glass access to the systems that run the PDP, held outside the policy it enforces and monitored like any other privileged account.