Notifications
Clear all
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.
NHIMG editorial — based on content published by Descope: Implementing ReBAC Without Rebuilding Your Authorization
Questions worth separating out
Q: When should security teams move from RBAC to ReBAC?
A: Teams should move when access depends on ownership, membership, sharing, or delegation at the individual resource level.
Q: How do I know if my authorization model has become too role-heavy?
A: A role-heavy model shows up as duplicated role variants, long chains of if-then checks, and policy logic spread across application code.
Q: What breaks when access rules are hidden in application logic?
A: Hidden authorization logic makes access difficult to audit, test, and explain.
Practitioner guidance
- Inventory relationship-dependent access paths Map where current authorization depends on ownership, membership, invitation, or inheritance rather than a simple role.
- Model relations before expanding role counts Define explicit relations such as owner, member, editor, and viewer in one schema, then point authorization checks at that schema instead of adding role variants like manager-finance or manager-engineering.
- Separate authorization logic from application code Move access decisions out of scattered middleware and service methods so you can query and audit them centrally.
What's in the full article
Descope's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of how to move from role checks to explicit relation checks in application code
- Schema design guidance for modeling ownership, membership, and delegation in a ReBAC system
- Implementation patterns for shadow mode testing before switching a resource type to ReBAC enforcement
- Practical examples of post-retrieval filtering and tenant-scoped authorization in collaborative systems
👉 Read Descope's guide to implementing ReBAC without rebuilding authorization →
ReBAC and RBAC: where relationship-driven access becomes necessary?
Explore further
25/06/2026 11:04 pm
ReBAC is the point where identity governance stops pretending every access rule is role-shaped. RBAC is built for broad equivalence, but modern applications increasingly need per-resource decisions that follow ownership, membership, and delegation. Once those relationships matter, the authorization model is no longer a list of roles but a governed graph of who can act on what. Practitioners should treat that shift as a structural change in authorization design, not a tuning exercise.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
- Only 44% of organisations have implemented any policies to govern AI agents, even though 92% agree that governing them is critical to enterprise security.
A question worth separating out:
Q: Who is accountable when relationship-based authorization is implemented poorly?
A: Accountability sits with the platform and identity teams that define the schema, enforcement points, and review process. Frameworks such as NIST CSF and zero trust architecture both expect access decisions to be controlled and explainable. If relationship data is stale or inconsistent, the authorization owner must correct the model, not just the application bug.
👉 Read our full editorial: ReBAC closes the gap where RBAC breaks down in modern apps
