RBAC vs ABAC: where authorization models break down

At a glance

What this is: This is an IAM analysis of RBAC, ABAC and ReBAC that argues the real decision is not which model wins, but which authorization failure mode your environment reaches first.

Why it matters: IAM and identity governance teams need this framing because authorization design usually evolves from static roles to context-aware policy and then to relationship-based access, and each shift changes auditability, scale and operational complexity.

Context

Authorization models are often described as a binary choice, but production systems rarely behave that way. Role-based access control, attribute-based access control and relationship-based access control solve different parts of the same identity governance problem, and each one fails in a different way as environments become more dynamic.

For IAM practitioners, the issue is not naming the right model in isolation. It is recognising when role explosion, attribute sprawl or relationship complexity is telling you that the current policy layer no longer matches the way access is actually granted, reviewed and audited.

Key questions

Q: What breaks when RBAC is stretched past its limits?

A: RBAC breaks when teams keep adding exception roles until the catalogue becomes impossible to reason about. At that point, role explosion hides real access intent, makes audits slower and creates silent permission drift because nobody can confidently say what each role is supposed to mean.

Q: Why do teams move from RBAC to ABAC in the first place?

A: Teams move to ABAC when static roles can no longer express context such as time, device posture, resource sensitivity or location. The shift usually happens because the business needs more precision, not because RBAC is obsolete. ABAC becomes attractive when access must change with the situation.

Q: What are the signs that an ABAC implementation is becoming too hard to manage?

A: Common warning signs include policies that are difficult to read, too many special cases, inconsistent access decisions across apps, and frequent manual exceptions to make policies work. If teams struggle to explain why access was granted or denied, the policy set has likely become too complex. ABAC should increase precision, not hide decision logic.

Q: When should organisations use ReBAC instead of roles or attributes?

A: Organisations should use ReBAC when access is driven by relationships such as team membership, document sharing, delegated ownership or inherited permissions. If the real control question is who is connected to what, relationship-based access usually fits better than trying to encode the same logic in roles or attributes.

Technical breakdown

How RBAC works and where role explosion starts

Role-based access control grants permissions through predefined roles, so the decision path is simple: assign a user to a role, then check whether that role includes the requested permission. That simplicity makes RBAC easy to audit and explain, which is why it remains the default in many systems. The failure mode appears when teams keep adding edge-case roles to cover exceptions. At that point, roles stop describing the business and start encoding one-off access workarounds. The model still functions, but the governance burden grows faster than the policy structure can absorb.

Practical implication: watch role growth as a governance signal, not just an administration issue, because it often marks the point where RBAC can no longer stay legible.

Why ABAC changes the authorisation boundary

Attribute-based access control evaluates user, resource, action and environment attributes at runtime, so the policy boundary is no longer a fixed role map. That lets teams express conditions such as location, device posture, sensitivity or business hours without multiplying roles. The trade-off is that ABAC shifts complexity into attribute quality, policy design and testing. If the attributes are incomplete or inconsistent, the engine may be precise in theory but unpredictable in practice. ABAC solves a real scaling problem, but only if the organisation can govern the data that drives the decisions.

Practical implication: treat attribute governance as part of authorisation design, because weak attribute hygiene undermines every runtime decision ABAC makes.

Where ReBAC belongs when sharing and inheritance dominate

Relationship-based access control models access through links between subjects and resources, which is why it fits collaborative systems with folders, teams, document sharing and inherited permissions. RBAC and ABAC can both approximate these patterns, but they become awkward when the access question is really about who is connected to what, and through which relationship. ReBAC changes the unit of control from role or attribute to graph traversal. That is powerful for shared content and nested delegation, but it also means the access model now depends on relationship accuracy and graph integrity.

Practical implication: use ReBAC when collaboration and inheritance drive access more than job function or context, and govern the relationship graph as a first-class identity asset.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

The RBAC versus ABAC framing is too narrow for production identity governance. Most mature systems do not choose one model and stop there. They start with RBAC, layer ABAC where context matters, and reach ReBAC when relationship-driven sharing becomes the harder problem. The governance question is therefore evolutionary, not binary, and practitioners should design for model layering rather than model purity.

Role explosion is the clearest sign that RBAC has outlived its useful boundary. When teams create roles for exceptions, duplicate roles with one permission changed, or can no longer explain what a role actually represents, the model has become a control surface for exceptions instead of a reflection of access intent. That failure mode tells security teams the role catalogue is now part of the risk surface.

Attribute sprawl is ABAC’s equivalent governance debt. ABAC reduces role count, but it can quietly accumulate inconsistent attributes, weak policy testing and runtime complexity that teams underestimate. The model only works cleanly when the organisation can trust the inputs as much as the policy logic, which makes data quality and policy lifecycle management part of identity governance, not a separate concern.

Relationship graphs are now an identity control plane, not just an application detail. ReBAC matters because modern collaboration systems are governed by inheritance, sharing and nested delegation patterns that neither static roles nor standalone attributes express well. The implication for practitioners is that access models increasingly need to be selected based on how relationships behave over time, not just how permissions are assigned on day one.

Hybrid authorisation is the operational norm, not a compromise. RBAC provides the broad boundary, ABAC adds contextual refinement, and ReBAC handles connected-resource scenarios that break both simpler models. The real maturity marker is not picking the most elegant model, but knowing when to combine them without losing auditability or policy clarity.

What this signals

Identity governance now has three distinct control shapes to manage. RBAC governs stable boundaries, ABAC governs contextual decisions and ReBAC governs connected-resource access. Teams that treat them as interchangeable usually end up overloading one model until it fails, then rebuilding under pressure.

The practical signal to watch is not which model is fashionable, but which one matches the system’s actual access geometry. Stable hierarchies point to RBAC, runtime context points to ABAC, and collaboration graphs point to ReBAC; mismatch is what creates the governance gap.

For practitioners

• Map your current role catalogue for explosion signals Look for duplicate roles, one-off exception roles and roles that only differ by a single permission. Those are the strongest indicators that RBAC is carrying policy complexity it was never meant to absorb.
• Govern attributes before expanding ABAC Inventory the user, resource, action and environment attributes that actually drive decisions, then check which ones are incomplete, stale or sourced inconsistently across systems.
• Use relationship-based access where sharing is structural Apply ReBAC when access follows teams, folders, delegated ownership or nested sharing, and validate that the underlying relationship graph is accurate enough to support audits and revocation.
• Layer policies instead of replacing models wholesale Keep RBAC as the coarse boundary where it still fits, then add ABAC or ReBAC only for the parts of the system that need context or relationships to make correct access decisions.
• Define a review trigger for authorisation model drift Reassess the access model whenever role count, attribute count or relationship depth changes faster than the team can explain in an access review or audit.

Key takeaways

• RBAC is still useful, but its limits appear quickly when organisations keep adding exception roles and lose visibility into what those roles mean.
• ABAC reduces role explosion by making decisions on runtime context, but it introduces a different governance problem around attribute quality, policy testing and operational complexity.
• ReBAC becomes necessary when access follows relationships rather than job titles or static attributes, which is why mature systems often combine all three models.

Key terms

• 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.
• 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.
• Relationship-Based Access Control (ReBAC): A model that grants or denies access based on relationships between identities, resources, and contextual objects. Instead of hard-coding who can do what, ReBAC evaluates whether the relevant graph links exist at decision time, which makes it well suited to collaboration-heavy and agentic environments.
• Role Explosion: Role explosion happens when a shared authorization model accumulates too many narrowly tailored roles, often because every customer or team request becomes a permanent global role. The result is a harder-to-understand access catalogue, broader blast radius, and weaker governance over who can do what.

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.