RBAC, ABAC and PBAC reveal the limits of static access control

At a glance

What this is: This is a comparative explainer of access control models, with the key finding that static role-based approaches struggle as infrastructure becomes more ephemeral and policy-driven.

Why it matters: It matters to IAM and NHI practitioners because service accounts, tokens and workloads often need context-aware access that outgrows coarse, manually managed role design.

👉 Read StrongDM's guide to RBAC, ABAC, PBAC, ACL and DAC

Context

Access control is not just about who can log in. For NHI governance, the harder question is how access should change as systems, workloads, and responsibilities change over time. Static models can work in stable environments, but they become brittle when service accounts, temporary infrastructure, and machine-driven workflows need rapid entitlement changes.

StrongDM frames the issue as a choice among RBAC, ABAC, PBAC, ACL and DAC, but the practitioner problem is broader: how to reduce privilege creep without creating an administrative bottleneck. That is the same pressure IAM teams face when human and non-human identities share the same access fabric. The underlying challenge is typical for modern cloud and platform operations, not an edge case.

Key questions

Q: How should organisations choose between RBAC and ABAC for non-human identities?

A: Use RBAC for stable, repeatable access patterns and ABAC when access must change with context, resource type, or environment. For non-human identities, ABAC is usually better when workloads are ephemeral or shared across teams. The practical test is whether the access rule needs to follow the identity alone or the identity plus the conditions around it.

Q: When does policy-based access control become better than role-based access control?

A: PBAC becomes better when roles are too broad, too numerous, or too hard to review. If your team is encoding many exceptions into roles, policy-based control usually produces clearer governance. It works best when access decisions need to be readable, auditable, and updated quickly without reshaping the entire role model.

Q: What is the difference between ACLs and RBAC in access governance?

A: ACLs attach permissions to specific objects or paths, while RBAC assigns permissions through roles that apply across many resources. ACLs are useful for narrow, object-level control, but RBAC is easier to govern at scale. For NHIs, RBAC usually provides better visibility, while ACL-heavy designs can hide access spread across many resources.

Q: Why do NHIs make access control harder to govern than human users?

A: NHIs are numerous, highly dynamic, and often tied to automation, which means access changes faster than manual review cycles. They also reuse tokens, keys, and certificates across systems, making ownership and offboarding harder. The result is more privilege drift and more blind spots unless access is designed around lifecycle events.

Technical breakdown

RBAC vs. ABAC: why role design breaks down in dynamic environments

RBAC assigns access through predefined roles, which makes it efficient when job functions are stable and resource boundaries are clear. ABAC changes the decision point from the person to the context, using attributes such as location, resource type, time, or clearance to decide access at runtime. That shift matters because modern environments are ephemeral, and the right entitlement may depend on where a workload is running or what data it touches. The architectural difference is not just granularity. It is whether authorization can react to state changes without recreating roles every time the environment shifts.

Practical implication: Use RBAC for stable baseline entitlements, then add ABAC where context and resource churn make role-only control too rigid.

Policy-based access control and the problem of human-readable governance

PBAC is often positioned as a more operationally readable way to express access rules, because the policy is the unit of control rather than the role or the raw attribute set. In practice, that means teams can author rules that combine conditions and exceptions without building a large role hierarchy. The risk is that policy sprawl can still produce hidden complexity if ownership, review, and testing are weak. For NHI governance, that matters because machine identities often depend on rules that must be precise, auditable, and fast to change when infrastructure is recreated or torn down.

Practical implication: Treat policy design as a governance discipline, with naming, review, and change control built into the access model itself.

ACLs and DAC: why object-level control does not scale well for NHI

ACLs attach permissions directly to objects or network paths, while DAC lets resource owners decide who else can access their data. Both can be useful at the edge of a system, but neither provides strong central visibility when machine identities proliferate. The operational weakness is mapping. As resources multiply, teams lose a reliable view of who can reach what, and that makes entitlement review harder. For NHI programs, this is where unmanaged access becomes a lifecycle problem, not just a permissions problem.

Practical implication: Reserve ACL and DAC style controls for narrow use cases and avoid using them as the primary model for broad NHI governance.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Static access models fail first at the edges, not at the core. RBAC works until roles become a proxy for everything the business wants to do, and then privilege creep starts to hide inside the model. That pattern is common in both human and non-human access programs. Practitioners should expect the first failure to appear in exception handling, not in the initial design.

Ephemeral infrastructure makes access decisions a runtime problem. When systems spin up and tear down quickly, access cannot depend entirely on manually curated roles. Attributes, policies, and time-bounded decisions become more useful because they track the environment rather than the org chart. The practical conclusion is that modern IAM for NHIs needs runtime awareness, not just entitlement catalogs.

ACLs and DAC create governance blind spots when machine identities scale. These controls can be precise, but precision is not the same as oversight. Once service accounts, tokens, and workload permissions spread across many resources, decentralized control weakens review and offboarding. Teams should treat visibility into object-level permissions as a governance requirement, not an audit afterthought.

Policy-based control is the real bridge between IAM and NHI governance. The strongest access models in dynamic environments are the ones that can be explained, reviewed, and automated. That makes policy design a security function as much as an access function. Practitioners should build controls that can survive rapid infrastructure change without creating standing privilege.

Identity blast radius is the right concept for comparing these models. The question is not which model sounds most flexible, but which one limits the damage when an identity is misused. A role-heavy design can widen blast radius quietly if permissions accumulate over time. Teams should use this lens when deciding where RBAC ends and policy-driven governance begins.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• The Ultimate Guide to NHIs , Key Challenges and Risks explains why visibility gaps and role creep keep widening even when access is formally documented.

What this signals

Identity blast radius is the signal practitioners should watch. When access is modeled mainly through static roles, machine identities can accumulate permissions faster than review cycles can remove them. That means IAM teams need to think in terms of containment, not just assignment.

The governance trend is toward policy-driven access that can adapt to ephemeral infrastructure without creating a new role for every workload. That is especially relevant where service accounts and workload identities move through short-lived environments and need controls that can be evaluated at runtime.

With 96% of organisations storing secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, the control model cannot stop at authorization alone. Teams need to pair access policy with secrets hygiene, lifecycle review, and offboarding discipline.

For practitioners

• Map access decisions to identity type Separate human, service account, workload, and application access patterns before choosing a control model. Use RBAC for stable job-based access, but apply ABAC or policy-based controls where context changes quickly.
• Review role growth for privilege creep Inventory roles that have accumulated exceptions, broad resource scope, or ad hoc approvals. Rework those cases into smaller policy sets so that access stays aligned to actual operational needs.
• Limit direct ACL and DAC use Use object-level ACLs and owner-driven DAC sparingly, especially for shared platforms and machine identities. Centralise review wherever possible so offboarding and entitlement audits do not depend on local resource owners.
• Build access around ephemeral resources Design controls so permissions follow tags, context, or workload attributes when systems are recreated. That reduces the risk that a new instance inherits stale access from an older environment.
• Automate review of non-human entitlements Tie entitlement reviews to service account lifecycle events such as provisioning, rotation, and decommissioning. This is where NHI exposure usually accumulates fastest.

Key takeaways

• RBAC remains useful for stable access patterns, but it becomes brittle when roles are forced to carry dynamic context.
• ABAC and PBAC reduce privilege creep by moving decisions closer to runtime conditions, which is better suited to ephemeral infrastructure.
• NHI governance improves when teams treat access as a lifecycle problem, not just a permissions model choice.

Key terms

• Role-Based Access Control: A model that grants access based on predefined job roles rather than individual requests. It is efficient for stable organisations, but it can create privilege creep when roles absorb exceptions and stop reflecting how systems actually operate.
• Attribute-Based Access Control: A model that decides access using attributes such as context, resource type, location, or clearance. It is better suited to dynamic environments because the decision can change when the situation changes, not just when a role is reassigned.
• Policy-Based Access Control: A model that uses human-readable rules to determine who or what can access a resource. It sits between rigid role structures and raw object permissions, and it is often used when teams need clearer governance over dynamic or contextual access.
• Access Control List: A list attached to a resource or network object that specifies who can access it and what they can do. ACLs are precise, but at scale they can fragment visibility and make central review harder for security teams.

Deepen your knowledge

RBAC, ABAC, PBAC and NHI lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building access controls for ephemeral infrastructure and machine identities, it is worth exploring.

This post draws on content published by StrongDM: Difference between RBAC vs. ABAC vs. ACL vs. PBAC vs. DAC. Read the original.