Relationship-Based Authorisation is an access control approach that grants permissions based on how people, systems, or agents are connected. It evaluates trust relationships such as team membership, delegated authority, ownership, or service-to-service links. In identity security, it helps enforce least privilege by authorising actions through contextual relationships instead of static roles alone.
What Relationship-Based Authorisation Actually Does
Relationship-based authorisation, often called ReBAC, decides access from the relationship between a requester and a resource, not just from a fixed role. The relationship may be ownership, delegation, team membership, hierarchy, tenancy, or a service-to-service trust link.
That matters because many real systems are not cleanly captured by broad roles alone. A document owner, a delegated approver, or a workload acting on behalf of another workload may all need different permissions even when they sit in the same role group.
How Relationship Context Becomes an Access Decision
ReBAC turns graph-like context into an authorisation check. Instead of asking only “what role does this subject have?”, the policy asks “what is this subject to the target, and is that relationship sufficient for this action?”
This makes authorisation more expressive for multi-party systems, collaboration platforms, delegated administration, partner access, and automation flows. It is especially useful where access changes as relationships change, such as ownership transfer, team reassignment, or an approval chain being delegated.
Because the decision depends on live relationships, the quality of the underlying identity data matters. If ownership records, delegation links, or service associations are stale, the policy may either over-grant access or block legitimate action.
Where ReBAC Fits Among Other Authorisation Models
ReBAC is usually part of a broader authorisation design rather than a complete replacement for roles or attributes. Roles still help with coarse grouping, attributes can express environmental or subject conditions, and relationship rules add the contextual link that static models miss.
For that reason, many organisations use ReBAC where object-level control is important, then combine it with Authorisation Models Guide to compare RBAC, ABAC, ReBAC and policy-based access control across people, workloads and AI agents. The practical design goal is not to choose one model universally, but to apply the least expressive model that still captures the real trust relationship.
Relationship-based checks are also closely tied to governance. A mature identity programme needs clear ownership, reviewable delegation, and a way to explain why a subject received access at the moment of decision rather than only what broad role they held.
Why ReBAC Matters for Least Privilege
ReBAC supports least privilege by narrowing authorisation to the specific relationship that justifies the action. That can reduce blanket access, role explosion, and the common workaround of assigning broad roles just to satisfy edge cases.
It also fits systems where permissions must follow the business relationship, not the employment category. Shared workspaces, partner collaboration, delegated workflows, and service chains often need access decisions that remain precise even when the same person or system interacts with many resources.
When ReBAC is implemented well, the policy becomes easier to align with business reality. When it is implemented poorly, relationship sprawl can become its own access-control problem, especially if no one owns the graph of trust links.
Risk and Threat Considerations
Relationship-based authorisation is powerful, but it can fail badly when the underlying relationships are wrong, overly broad, or not retired on time. If delegation, ownership, or service trust is abused, an attacker may inherit legitimate-looking access without needing to defeat the authorisation engine itself.
Failure mechanism: Stale ownership records, uncontrolled delegation chains, or weakly governed service relationships can create an access path that appears valid to policy logic but no longer reflects the real trust state.
Impact: The result can be excessive privilege, unauthorised data access, lateral movement through trusted relationships, or persistent access that survives a role change or offboarding event.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | ReBAC is an access enforcement pattern that makes relationship-driven decisions. |
| AC-6 — Least Privilege | Relationship-based access is used to narrow permissions to the specific justified trust relationship. | |
| IA-5 — Authenticator Management | ReBAC depends on reliable identity material and trust relationships that must be managed across their lifecycle. | |
| Recommendation — Enforce relationship-based policies at the decision point so access follows approved trust links. Limit access to the minimum relationship-derived privilege needed for the action. Manage credentials and related trust material so relationship assertions remain valid. | ||
| CSA Cloud Controls Matrix | IAM — Identity & Access Management | CSA CCM IAM covers identity and access controls where relationship-based authorisation is implemented. |
| Recommendation — Model relationship-based access rules inside your IAM governance and approval processes. | ||
Practitioner Guidance
Why practitioners should care: ReBAC works best when relationship sources are treated as security-critical data, not just application metadata. If the identity, ownership, or delegation graph is inaccurate, the authorisation decision will be too.
Governance implication: Define who owns each relationship type, how it is created, how it is reviewed, and when it expires. That is what keeps relationship-based access from becoming an unbounded trust graph.
Practitioner takeaway: Use ReBAC for the business relationships that truly determine access, but keep those relationships reviewable, minimised, and revocable.
Related resources from NHI Mgmt Group
- How do organisations reduce policy drift in relationship-based authorisation?
- How should teams compare SPIFFE-style workload identity with relationship-based authorisation?
- What do teams get wrong about RBAC, ABAC, and relationship-based access control?
- Why does relationship-based access control matter for application and NHI governance?