Relationship-Based Access Control

What Relationship-Based Access Control Actually Does

Relationship-Based Access Control, or ReBAC, decides access from the relationships between actors and resources rather than from a fixed role alone. It is most useful when the permission question depends on who owns, manages, belongs to, or is delegated by whom.

That makes ReBAC a natural fit for systems where access changes with business context, such as document sharing, partner portals, collaboration platforms, and delegated administration. A policy engine can ask whether the requester is the owner, a manager, a member of the right group, or connected through another approved path before it authorises the action.

How ReBAC Evaluates Trust Through Relationships

ReBAC usually models relationships as edges in a graph or records in a directory, then evaluates those links at decision time. The important point is that the policy is not just checking a label on the user; it is checking whether the user stands in a verified relationship to the thing they want to reach.

This approach is more expressive than simple role assignment because the same person may have different rights depending on the resource, the delegation chain, or the organisational context. For example, a person may be able to view one project because they are a named collaborator, edit another because they are its owner, and see a third because they act on behalf of a manager.

In practice, ReBAC often sits alongside identity, attributes, and policy logic. A mature design treats the relationship graph as a first-class authorization input, not as an informal naming convention or an application-side shortcut.

Where ReBAC Is Strongest, and Where It Gets Complex

ReBAC is strongest when access is naturally relational and highly dynamic. Shared files, healthcare casework, vendor collaboration, channel partnerships, and internal approval chains are all examples where “who is connected to what” can matter more than job title alone.

Its main strength is precision at scale: you can grant access based on real-world business relationships without exploding the number of roles. The trade-off is operational complexity, because the organisation must keep relationship data accurate, timely, and consistent across systems that may each represent ownership, delegation, or membership differently.

That complexity is why ReBAC often needs careful modelling, clear source-of-truth rules, and a strong separation between relationship data and enforcement logic. If the relationship graph is stale or ambiguous, the authorization result can drift away from the business reality it is supposed to reflect.

Why ReBAC Matters for Modern Authorization Design

ReBAC is increasingly important wherever access must follow real relationships rather than broad entitlements. NHIMG’s Authorisation Models Guide places ReBAC alongside RBAC and ABAC because many real systems combine all three to reach a usable balance of precision and governability.

The key design question is not whether ReBAC is “better” than other models, but whether the access decision is genuinely relationship-driven. If the answer depends on ownership, delegation, sponsorship, partnership, or membership in a specific graph, ReBAC can express that directly and more faithfully than a static role alone.

For broader IAM context, NHIMG’s IAM and IGA Basics helps place ReBAC inside the larger lifecycle of provisioning, review, entitlement governance, and access policy management.

Risk and Threat Considerations

ReBAC reduces some over-provisioning problems, but it also creates a new failure surface: if relationship data is wrong, stale, or too easy to influence, access can be granted to the wrong party at scale. That is especially dangerous in collaboration and delegated-access environments, where a single incorrect edge can cascade into broad exposure.

Failure mechanism: Attackers or careless administrators can exploit broken relationship checks, stale graph data, confused ownership rules, or improper delegation paths to obtain access that should have been denied.

Impact: The result can be unauthorized data exposure, privilege escalation through trusted links, and difficult-to-detect access because the decision appears to come from a legitimate relationship rather than an obvious bypass.

Practitioner Guidance

Governance implication: Treat relationship sources as security-critical data, not just application metadata. Ownership, delegation, and membership rules need clear system-of-record boundaries, because the authorization result is only as trustworthy as the underlying relationship graph.

What to watch for: Pay particular attention to orphaned relationships, stale delegations, inherited access that no longer matches business reality, and application-specific exceptions that quietly bypass the central policy model. ReBAC works best when relationship changes are reviewed with the same seriousness as entitlement changes.

Related resources from NHI Mgmt Group

• 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?
• How should security teams govern relationship-based access control at scale?
• What is the difference between JWT-based access and relationship-based access control?