RBAC, ABAC, PBAC: Choosing an Access Model That Survives Contact with Reality

Every access control debate eventually collapses into acronym warfare. Having designed enterprise access frameworks across RBAC, ABAC and PBAC - and owned the enforcement architecture underneath them - my view is that the acronyms matter far less than two questions: where are decisions made, and what signals feed them.

What each model is actually for

• RBAC answers “what does this job need?” It is auditable, explainable to the business, and maps cleanly to IGA certification campaigns. Its failure mode is role explosion - which is almost always a symptom of encoding attributes (country, department, seniority) into role names instead of treating them as attributes.
• ABAC answers “what is true right now?” Decisions combine subject, resource, action and environment attributes. It scales without role explosion, but it is only as trustworthy as attribute hygiene - and attribute hygiene is an HR data quality programme wearing a security costume.
• PBAC is ABAC with governance: policy as the first-class, centrally administered, versioned artefact, evaluated by a PDP and enforced by distributed PEPs. This is where XACML-style thinking, and modern policy engines, live.

Layer them, do not pick one

The pattern I deploy in practice is a hybrid: coarse-grained RBAC for entitlement assignment and certification (roles are what the business can review), attribute conditions layered on top for context (an entitlement is active only when device compliance, location and risk conditions hold), and policy-based evaluation for fine-grained, high-value decisions inside applications and data platforms. Birthright access flows from the authoritative HR source through JML automation; everything above birthright is requestable, approvable, time-bound and recertifiable.

The architecture underneath

Whichever blend you choose, insist on the separation of duties between PAP, PDP and PEP. Policy authored in one governed place; decisions made by an engine you can test; enforcement pushed to the edges - the token issuance path, the API gateway, the application, the data layer with row and field filters derived from decision obligations. If enforcement logic is hand-coded per application, you do not have an access model, you have a thousand small ones.

A test for your model

Take your highest-risk scenario - say, a contractor in a sanctioned country requesting access to a regulated dataset from an unmanaged device - and trace exactly which component denies it and on which signal. If the answer involves the phrase “the application checks”, keep designing.