Topic starter
25/06/2026 10:30 pm
TL;DR: RBAC works for flat access models, but collaborative, multi-tenant, and delegated workloads quickly expose its limits because relationship-driven permissions do not fit neatly into roles, according to Descope. ReBAC shifts authorization to named relationships and resource-level checks, which is the model modern IAM teams need when access must follow ownership, membership, and delegation.
Editorial analysis by NHI Mgmt Group, based on content published by Descope: “Implementing ReBAC Without Rebuilding Your Authorization”.
Key questions
Q: What breaks when RBAC is used for per-resource sharing?
A: RBAC starts to fail when different resources need different permissions for the same role holder.
Q: When should organisations prioritise ReBAC over ABAC in fine-grained access control?
A: Organisations should prioritise ReBAC when access is shaped by dynamic relationships, hierarchies, or collaborative structures that change frequently.
Q: What do teams get wrong about authorization models when role counts start to grow too quickly?
A: The common mistake is letting role explosion become the default response to every new access need.
Practitioner guidance
- Map implicit authorization relationships Inventory where ownership, membership, sharing, delegation, and parent-child resource inheritance already exist in your product, then make those relations explicit instead of hiding them in scattered if statements.
- Move one high-pain resource type first Start with the object class that generates the most exceptions, support tickets, or custom policy branches, then express only that resource's access paths as relations before expanding the model.
- Run shadow checks before cutover Evaluate the new relationship model in parallel with existing RBAC logic, log any mismatches, and only replace the legacy decision once both systems agree consistently for the chosen resource type.
Bottom line: RBAC is sufficient only when a role truly maps to the same access everywhere, which is rare once products support sharing and delegation.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 24 hours ago by NHI Mgmt Group
25/06/2026 11:04 pm
RBAC failure is usually a modelling failure, not a product failure. The problem appears when teams use roles to represent relationships that were never role-shaped in the first place. Once ownership, membership, and per-resource sharing enter the design, RBAC becomes a coarse approximation that forces compensation logic into the application layer. The practitioner lesson is to treat role explosion as evidence that the authorization model no longer matches the product.
A few things that frame the scale:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: What should teams do when delegation needs to stay bounded?
A: Use a relationship model that scopes delegated access to the exact resource path that was granted. That preserves the original sharing intent and prevents a delegate from inheriting broader access simply because they hold the same role as another user. The goal is traceable scope, not role inflation.
👉 Read our full editorial: ReBAC closes the gap where RBAC breaks down in modern apps
This post was modified 24 hours ago by NHI Mgmt Group