Use ReBAC for stable relationships that define who is connected to what, and use ABAC-style conditions only when the rule depends on changing context such as time, network location, or session state. The test is whether the condition should travel with the permission edge or remain part of the broader relationship model.
How to decide whether the rule is about the relationship or the condition
The cleanest test is whether the access decision describes a stable relationship or a changing circumstance. ReBAC fits when the permission follows a durable edge, such as member-to-team, owner-to-resource, or manager-to-report. ABAC fits when the rule depends on mutable context, such as time, network, device posture, or session state. If the condition feels like part of “who is connected to what,” it belongs in the relationship model.
That distinction matters because relationship rules are easier to reason about, review, and reuse when they stay close to the graph, while contextual rules are better expressed as policy conditions evaluated at decision time. Teams often get into trouble when they encode a transient condition as if it were a long-lived relationship, or when they hide a durable relationship inside a pile of attributes that nobody can interpret consistently.
For a broader treatment of authorization models, the practical question is whether the rule describes a permission edge or a policy predicate.
What changes the choice in real systems
Stable relationships are usually the better fit for ReBAC when the access logic follows business structure, hierarchy, delegation, or ownership. For example, “a project member can view project files” or “a manager can approve a direct report’s request” are relationship statements. They remain understandable even when systems, sessions, or network conditions change, because the core decision is anchored in a persistent link.
ABAC becomes more appropriate when the rule must react to volatile context that should not redefine the underlying relationship. A user may still be related to a resource, but access is only valid during business hours, from a managed device, or inside a trusted network zone. In those cases, the attribute is a modifier on the decision, not the definition of the relationship itself.
If the policy needs to survive turnover, restructuring, or data-model changes, keep the durable part in ReBAC and reserve ABAC for the factors that are expected to move frequently. That separation reduces policy drift and makes reviews easier because the team can see whether it is updating a relationship or simply tightening the conditions around it.
For teams formalizing access governance, IAM and IGA Basics is useful background on how relationships, entitlements, and governance controls fit together.
Common boundary mistakes and how to avoid them
The most common mistake is using ABAC to encode a business relationship that should really be modeled as a graph edge. That usually shows up as sprawling policies full of department names, reporting lines, project tags, and custom flags that try to imitate relationship logic without making the relationship explicit. The result is brittle authorization that is hard to audit and easy to misapply.
The opposite mistake is treating every context check as if it should become a relationship. If the rule depends on time windows, risk score, geolocation, or session freshness, forcing it into ReBAC makes the model awkward and can create false durability. A relationship should not need to be rewritten every time the environment changes.
Teams should also watch for hidden duplication. If the same access rule is partly represented as a role, partly as a relationship, and partly as an attribute condition, reviewers lose the ability to answer a simple question: what actually grants access here? Keeping the boundary sharp makes authorization easier to test, explain, and recertify.
When you need a concrete model comparison, the Authorisation Models Guide gives a practical lens for separating relationship-driven access from context-driven policy.
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, OWASP ASVS and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Covers enforcing who may access resources and under what conditions. |
| AC-6 — Least Privilege | Supports minimizing access by keeping permissions tied to the narrowest valid relationship. | |
| Recommendation — Separate durable relationship grants from conditional policy checks in your access enforcement design. Model only the access implied by the relationship, then add conditions only where needed. | ||
| OWASP ASVS | V8 — Authorization | Directly addresses how applications decide access based on roles, relationships, and policy conditions. |
| Recommendation — Implement authorization checks so relationship rules and contextual predicates stay distinguishable. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Requires a defined access control approach that distinguishes authorization logic from context checks. |
| Recommendation — Document which rules are relationship-based and which are conditional access controls. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Covers managing permissions cleanly so access rules remain understandable and reviewable. |
| Recommendation — Review permissions to ensure stable entitlements are not buried inside ad hoc conditions. | ||
Practitioner Guidance
What to verify: Ask whether the rule would still make sense if the user’s context changed but the business relationship did not. If yes, it likely belongs in ReBAC. If the rule only exists because context is variable, keep it as an ABAC condition.
Decision rule: Put the stable “who is related to what” logic in the relationship layer, then add ABAC only for the extra condition that narrows or suspends that relationship at decision time. That keeps the model intelligible and avoids turning relationships into a dumping ground for temporary policy logic.
What practitioners underestimate: The hardest part is not syntax, it is governance. A mixed model can work well, but only if teams can explain which layer owns membership, delegation, exception handling, and contextual restriction without contradiction.
Practitioner takeaway: If a rule defines a durable entitlement path, model it as ReBAC first; if it only constrains when that path may be used, express it as ABAC.
Related resources from NHI Mgmt Group
- How should teams decide whether CIAM belongs in the same IAM programme as workforce access?
- How do access-control teams decide whether filtering belongs in the app or the query layer?
- How can IAM teams decide whether an access issue belongs in IGA or PAM?
- How should teams decide whether SaaS access still belongs?