When should organisations use ReBAC instead of roles or attributes?

When ReBAC is the better fit than roles or attributes

ReBAC is the better fit when the access decision depends on a real-world or system relationship, not just a person’s job title or a static property. If the policy question is “who is related to this resource, and in what capacity?”, ReBAC usually models the requirement more cleanly than forcing the same logic into broad roles or brittle attribute rules.

That matters because relationship logic tends to be highly contextual. A user may be allowed to view a document because they are its owner, a delegated editor, a member of the project that owns it, or part of a parent organisation with inherited access. ReBAC expresses those paths directly, which reduces the need for role explosion or sprawling attribute combinations.

It is also a good fit when access is naturally recursive or inherited. Sharing models often need to follow folder, team, case, tenant, or graph relationships, and those relationships can change over time without changing the core policy intent. In those cases, ReBAC keeps the policy aligned to the business object graph instead of encoding it indirectly through entitlements that must be constantly rewritten.

What ReBAC changes in practice

ReBAC does not replace RBAC or ABAC everywhere. It is strongest when the primary control variable is the link between subject and object, while roles and attributes remain useful for coarse gating, default posture, or administrative guardrails. A common pattern is to use roles to establish baseline permissions and ReBAC to decide whether a specific user is connected enough to a specific resource to inherit those permissions.

That distinction helps avoid overloading roles with exceptions. Roles work best when access is stable and easy to explain, such as “finance analyst can read finance reports.” Attributes work well when access can be evaluated from known properties, such as department, clearance, region, or device state. ReBAC becomes preferable when neither a role nor a property fully captures the relationship that actually justifies access.

For practitioners, the real test is whether the policy can be stated without reference to a relationship graph. If you keep finding yourself describing ownership, membership, delegation, sharing, or inheritance, the model is probably relationship-based whether or not the implementation currently is. That is why ReBAC often improves both policy clarity and long-term maintainability when access patterns are collaborative and object-centric.

Where ReBAC is strongest and where it can be awkward

ReBAC is strongest in collaboration platforms, document systems, case management, multi-tenant applications, and other environments where objects are shared through connections rather than blanket entitlements. It is especially useful when one object can derive permissions from another, such as a file inheriting access from a folder or a workspace inheriting access from an organisation boundary. For a broader comparison of authorization models, the key question is whether the policy is driven by hierarchy, sharing, or both.

It can be awkward when the organisation wants very simple explainability, because relationship graphs are harder to audit in plain English than a small role set. They can also become difficult if ownership data is inconsistent or if teams model relationships differently across systems. In other words, ReBAC is not automatically simpler, it is simpler only when the underlying business relationships are already the real source of truth.

That is why ReBAC should be chosen for semantic accuracy first and implementation convenience second. If the access decision really comes from a connection between entities, forcing the policy into roles or attributes usually creates indirection, duplication, and edge cases. If the decision is primarily about persona, clearance, or machine state, RBAC or ABAC may still be the cleaner choice.

Practitioner Guidance

What to verify: Confirm that the relationship you intend to use is authoritative, durable enough for access control, and available at decision time. If the “relationship” is really an informal workflow status or a manually maintained field, ReBAC can become just as brittle as the model it was meant to replace.

Decision rule: If the same access rule would need many exception roles or nested attribute clauses, model the access through the relationship that actually grants the right. If the policy can be expressed cleanly as a role assignment or attribute check, do not force it into ReBAC just because the platform supports graphs.

Common mistake: Treating ReBAC as a universal replacement for authorization design. Good access architecture usually combines models, with roles for broad entitlement, attributes for context, and relationships for shared resources and delegated control.

Practitioner takeaway: Use ReBAC when the business meaning of access is “this actor is connected to this object in a way that justifies access,” and choose roles or attributes when the relationship is not the real control variable.

Related resources from NHI Mgmt Group

• When should organisations use ABAC instead of relying on roles alone?
• Should organisations use JIT access instead of permanent admin roles for critical apps?
• When should organisations use conditional relationships instead of broad roles?
• How do organisations operationalise NHI ownership at scale?