TL;DR: Relationship-based access control maps permissions to entity relationships rather than static roles, making it better suited to collaborative, multi-tenant systems and inherited access patterns, according to Permit.io. The governance question is not whether ReBAC is modern, but whether teams can operate it without letting graph complexity become an authorization blind spot.
NHIMG editorial — based on content published by Permit.io: ReBAC in Practice, comparing Permit.io and OpenFGA
By the numbers:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- Only 5.7% of organisations have full visibility into their service accounts.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
Questions worth separating out
Q: How should security teams govern relationship-based access control at scale?
A: Treat ReBAC as a governed identity system, not just an application pattern.
Q: When does ReBAC create more risk than it reduces?
A: ReBAC becomes risky when the relationship graph is stale, poorly synchronised, or spread across teams without a single ownership model.
Q: What do teams get wrong about hybrid RBAC, ABAC, and ReBAC models?
A: Teams often assume more policy dimensions automatically mean better security.
Practitioner guidance
- Inventory relationship sources and update paths Map every system that creates or syncs relationship tuples, then define who approves changes and how stale edges are removed when ownership changes.
- Separate policy logic from application code Keep access rules in a governed policy layer so developers are not re-implementing nested checks in multiple services and teams can review the same source of truth.
- Recertify descendant access paths Review inherited permissions for folders, tenants, and org structures on a fixed schedule so access granted through parent relationships does not outlive the business need.
What's in the full article
Permit.io's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of how the policy editor maps resources, roles, and relations into deployable access logic.
- The comparison table for managed versus self-hosted authorisation, including infrastructure and audit trade-offs.
- Terraform and SDK implementation details for teams that want to productionise relationship-based policies.
- Cedar compatibility and integration notes for organisations standardising authorisation as code.
👉 Read Permit.io's comparison of ReBAC implementations in production systems →
ReBAC in practice: are your authorization controls keeping up?
Explore further
ReBAC becomes a governance problem the moment it leaves the diagram. Relationship graphs are attractive because they match how modern applications actually share data, but they also move authorisation control into a stateful model that must be curated continuously. Once graph edges, tuples, and inheritance rules become operational security artefacts, lifecycle discipline matters as much as policy design. The implication is that teams must govern who can mutate the graph, not just who can query it.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which shows why relationship-driven access decisions need stronger governance than most teams currently have.
A question worth separating out:
Q: How should organisations choose between self-hosted and managed authorisation?
A: Choose based on operational maturity, not ideology. If your team can reliably run databases, caches, policy APIs, and audit workflows, self-hosting may fit. If not, managed authorisation reduces infrastructure burden and can improve governance visibility, but you still need clear ownership for policy design and review.
👉 Read our full editorial: ReBAC in practice: what OpenFGA and Permit.io change