RBAC vs ABAC: where authorization models break down

At a glance

What this is: This is an IAM comparison of RBAC, ABAC, and ReBAC that finds most production systems need layered authorization rather than a single model.

Why it matters: It matters because access models shape how practitioners govern human, NHI, and workload access as systems grow, and the wrong abstraction creates audit pain, policy drift, and brittle authorization.

👉 Read Ory's explanation of RBAC, ABAC, and ReBAC differences

Context

Authorization models define how a system decides who or what can do what. RBAC, ABAC, and ReBAC are often presented as competing options, but in production they usually appear as layers that solve different decision problems at different levels of granularity. That distinction matters for IAM because human users, service accounts, and AI-driven workloads do not all fit the same access pattern.

The article’s real contribution is the reminder that model choice is a governance decision as much as a technical one. RBAC is easiest to explain and audit, ABAC is better for contextual control, and ReBAC becomes necessary when relationships, not just roles or attributes, define access. For teams managing NHI and workload identity, that layered view aligns more closely with the lifecycle and privilege realities discussed in the [Ultimate Guide to NHIs](https://nhimg.org/the-ultimate-guide-to-non-human-identities) and the OWASP Non-Human Identity Top 10.

The article also points to a familiar failure pattern: when access needs multiply faster than governance can keep up, teams start creating exceptions that outgrow the original model. That is why the practical question is not whether RBAC or ABAC is superior, but which model can carry the current system shape without producing hidden policy debt.

Key questions

Q: When should organisations move from RBAC to ABAC?

A: Move to ABAC when role alone no longer captures the access rule, such as ownership, time of day, or transaction amount. The trigger is not maturity for its own sake, but a real decision need that RBAC cannot express without creating exceptions in application code. ABAC should add precision, not noise.

Q: Why does role explosion make RBAC harder to govern?

A: Role explosion turns a simple model into a long list of exceptions that nobody can fully explain, test, or review consistently. Once roles are created to solve one-off cases, permission drift becomes easier to hide inside the role catalogue. The governance problem is not the number of roles alone, but the loss of clarity about what each role actually means.

Q: How do RBAC and ABAC work together in mature systems?

A: Most mature systems use RBAC to define broad access boundaries and ABAC to apply finer rules inside those boundaries. RBAC answers whether someone belongs in a general access class. ABAC answers whether the current request satisfies context-specific conditions. That layering keeps the model explainable while still supporting dynamic decisions.

Q: What is the difference between RBAC and ReBAC for collaborative systems?

A: RBAC ties access to the user’s role, while ReBAC ties access to relationships such as team membership, ownership, sharing, or nested group structure. ReBAC is better when permissions depend on how resources are connected rather than on a fixed job function. In collaborative systems, relationship logic often matches real access patterns more closely than roles do.

Technical breakdown

RBAC permission drift and role explosion

RBAC assigns permissions through predefined roles, which makes it simple to understand and audit. The weakness appears when teams keep adding narrowly tailored roles to cover exceptions, creating role explosion. At that point, permission mapping becomes harder to reason about than the original access problem. RBAC still works well when job functions are stable and access patterns change slowly, but it becomes fragile when the organization starts encoding exceptions into role names instead of policy.

Practical implication: track role count growth, duplicate permission sets, and exception-driven role creation as early warning signs that RBAC is reaching its ceiling.

ABAC runtime evaluation and attribute governance

ABAC decides access by evaluating attributes about the user, resource, action, and environment at request time. That makes it more precise than RBAC for context-sensitive controls such as device posture, location, time, or data sensitivity. The trade-off is that attribute quality becomes part of the security model. If attributes are stale, inconsistent, or poorly governed, ABAC can become harder to trust than the static roles it replaces. Its strength is flexibility, but only when the attribute sources are reliable and policy logic is testable.

Practical implication: define authoritative attribute sources first, then test policies against edge cases before using ABAC for production access decisions.

ReBAC relationship graphs and collaborative access

ReBAC expresses authorization through relationships between subjects, objects, and containers rather than through roles or standalone attributes. That matters in collaborative systems where access is inherited through teams, folders, projects, or shared resources. Google-style permission structures are difficult to model cleanly in pure RBAC or ABAC because the decision depends on graph traversal, not just one identity or one resource record. ReBAC is not a replacement for the other models. It is the layer that handles relationship-heavy access where graph structure is the real policy input.

Practical implication: use ReBAC when access inheritance, sharing, and nested ownership are the primary drivers of authorization complexity.

NHI Mgmt Group analysis

RBAC vs ABAC is not a contest between old and new. It is a question of which governance debt appears first. RBAC tends to fail through role explosion, while ABAC tends to fail through attribute sprawl and policy complexity. Mature identity programmes usually end up layering the two because each covers a different control problem. The practitioner conclusion is that the model should follow the shape of access, not fashion.

ReBAC belongs in the same conversation because relationship-driven access breaks both static roles and pure attributes. Collaboration platforms, shared folders, nested teams, and delegated permissions all create structures where the relationship graph is the access policy. That makes ReBAC especially relevant where human IAM and workload governance intersect with collaborative systems. The practitioner conclusion is that the decision framework should include relationship inheritance, not just role count and attribute count.

For NHI governance, the layer choice becomes even more consequential because service accounts and workloads rarely fit org-chart logic cleanly. Static roles often over-grant to keep pipelines working, while dynamic attributes can be hard to source reliably for machine identities. That is why workload access control often ends up combining RBAC for baseline entitlements with tighter policy layers for context. The practitioner conclusion is to treat machine access as a separate governance shape, not a human-role clone.

Policy complexity is now the real authorisation risk, not model purity. Teams that insist on a single model often create hidden workarounds, and those workarounds are what auditors and incident responders eventually inherit. The useful question is whether the access model can be explained, tested, and recertified at the pace the system changes. The practitioner conclusion is to measure operational clarity, not just theoretical elegance.

Role explosion is the named failure mode that should trigger a model review. Once teams create roles to encode one-off exceptions, the access model stops expressing business structure and starts encoding technical debt. That pattern is easy to miss because it looks like governance discipline on paper. The practitioner conclusion is to treat exception roles as evidence that RBAC has crossed from control into complexity.

From our research:

• 35.6% of organisations cite managing consistent access across hybrid and multi-cloud environments as their top NHI security challenge, according to the 2024 Non-Human Identity Security Report.
• Only 23.7% of organisations share secrets through insecure methods such as email or messaging applications, which shows how governance gaps often persist even when teams believe controls are mature.
• That pattern is why the Ultimate Guide to NHIs remains a practical next step for teams formalising access governance across human and machine identities.

What this signals

Role explosion is increasingly a machine-identity problem, not just a human IAM problem. As service accounts, API keys, and workload identities proliferate, role-based shortcuts tend to accumulate in the same way they do for people, only faster. The governance signal is simple: if policy logic is becoming unreadable, the model has already started to outgrow the operating team.

Attribute governance is now the deciding factor for ABAC success. Teams that want context-aware access need reliable signals for device, resource, and environment state, plus a clear source of truth for each. Without that, ABAC becomes a pile of brittle policy exceptions rather than a control system. The practical next step is to align identity, device, and data governance before pushing more decisions into runtime policy.

Hybrid authorisation stacks are becoming the norm because they reduce pressure on any single model. RBAC can hold the baseline, ABAC can tighten context, and ReBAC can handle relationship-heavy access where collaboration drives permissions. For practitioners, the signal is to design for layering up front rather than waiting until exceptions force the architecture.

For practitioners

• Map current access decisions by model layer Separate baseline entitlements, contextual checks, and relationship-based inheritance before deciding where RBAC, ABAC, or ReBAC belongs in the stack.
• Watch for role explosion indicators Review roles that exist only to handle one-off exceptions, copied roles with minor edits, and access reviews that cannot be explained cleanly to auditors.
• Establish authoritative attribute sources If ABAC is in scope, document which directories, device signals, data labels, and environmental controls are trusted for policy evaluation.
• Use relationship models where access is inherited Apply ReBAC where teams, folders, project hierarchies, or shared resources determine permissions more accurately than user roles or standalone attributes.

Key takeaways

• RBAC, ABAC, and ReBAC solve different authorization problems, and most real systems need more than one.
• Role explosion, attribute sprawl, and relationship complexity are the practical signals that a single access model has stopped fitting the environment.
• For identity teams, the real task is not model purity but explainable, testable authorization across human, NHI, and workload access.

Key terms

• Role-Based Access Control: An access model that grants permissions through predefined roles rather than through per-user exceptions. It is easy to audit and explain, but it becomes difficult to govern when teams keep adding roles to cover edge cases or when role names no longer describe real access patterns.
• Attribute-Based Access Control: Attribute-Based Access Control is a policy model that grants or denies access using attributes such as user role, device state, location, and application context. It replaces purely static role assignment with a decision process that can adapt to current conditions, provided the underlying attributes are trustworthy and well-governed.
• Role-Based Access Control: A model that grants permissions by assigning identities to predefined roles. It works well when jobs are stable and access patterns are predictable, but it becomes brittle when exceptions pile up. In practice, role design must stay small enough to audit and broad enough to avoid endless custom variants.

What's in the full article

Ory's full article covers the implementation detail this post intentionally leaves for the source:

• Permission-mapping examples that show how RBAC, ABAC, and ReBAC differ in application design
• Practical guidance on when hybrid authorization is preferable to a single-model deployment
• Detailed examples of role explosion and attribute complexity that teams can use in architecture reviews
• Context on how Ory Keto fits into relationship-based authorization workflows

👉 The full Ory article includes implementation examples and model-selection guidance for production authorization.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.