How should IAM teams decide where ReBAC belongs in an authorisation model?

Where ReBAC Fits Best in an Authorization Model

ReBAC belongs where the business question is fundamentally about relationships between actors, resources, and delegated rights rather than only static user attributes or fixed roles. It is strongest when access needs to follow ownership chains, group membership, collaboration links, or inherited structure, and weaker when decisions must vary by context, sensitivity, or runtime intent.

That distinction matters because authorization models are often mixed, not pure. Authorisation Models Guide is useful here because it treats ReBAC as one part of a broader model set, not as a universal replacement for RBAC, ABAC, or policy-based controls.

How to Choose ReBAC Instead of Forcing a Role or Policy Model

Use ReBAC when the answer to “should this principal get access?” is best derived from a graph-like relationship: owner-to-asset, member-to-team, manager-to-report, editor-to-document, tenant-to-subtenant, or parent-to-child resource inheritance. In those cases, the relation itself is the clearest entitlement source, and hard-coding equivalent roles usually creates role explosion or brittle exceptions.

Use a different model when the decision depends on attributes that are not captured by the relationship graph, such as data sensitivity, location, device posture, time, transaction value, or step-up requirements. IAM and IGA Basics is a practical companion because it places ReBAC alongside RBAC and ABAC in the broader authorization and governance picture.

In practice, ReBAC often works best as the structural layer for who is connected to what, while policy controls decide whether that relationship is sufficient under current conditions. That is especially common in collaboration platforms, content repositories, SaaS tenant hierarchies, and applications with nested objects or delegated administration.

Where ReBAC Breaks Down and Why IAM Teams Combine Models

ReBAC can become awkward when the relationship graph is incomplete, hard to observe, or expensive to evaluate at runtime. It can also over-grant access if teams treat “related” as automatically “allowed” without layering sensitivity checks, least privilege, or exception handling around the relationship.

Another common failure mode is overloading ReBAC with every authorization concern, which makes the graph carry rules it was not designed to express. Authorisation Models Guide and CSA Cloud Controls Matrix are both helpful references because they reinforce the need to separate entitlement structure from broader governance and cloud control expectations.

Practitioner Guidance

What to prioritise: Start by mapping the authorization decision type. If access is naturally inherited through relationships, model that with ReBAC first; if the decision depends heavily on context or data sensitivity, keep ReBAC as a supporting layer rather than the primary decision engine.

What to verify: Validate that every relationship used for authorization is authoritative, current, and reviewable. If the business cannot explain where the relationship comes from, who owns it, and when it expires, the model will drift into implicit privilege.

Decision rule: If the access rule can be stated cleanly as “because this principal is related to that resource in this way,” ReBAC is probably a good fit. If the rule needs multiple conditional checks to stay safe, pair ReBAC with policy logic instead of stretching the graph model.

Practitioner takeaway: ReBAC is most valuable when it reduces entitlement complexity without hiding risk; use it for structural authorization, but keep context-sensitive decisions explicit and separately governed.

Related resources from NHI Mgmt Group

• How do IAM teams decide whether a brokered login model is safe for production use?
• How should teams decide whether CIAM belongs in the same IAM programme as workforce access?
• How can organisations decide whether a computer-use model belongs in production IAM?
• How should teams decide whether to keep custom IAM or move to a platform model?