Choose graph-based FGA when your product truly depends on arbitrary relationship logic that cannot be expressed as inheritance. Choose hierarchical authorization when most permissions follow natural structures such as organisations, workspaces, projects, and resources. The deciding factor is not sophistication, but whether the model matches how the product actually assigns access.
How to Choose the Right Authorization Model
The real decision is whether your access rules are mostly structural or relationship-heavy. If access can be expressed cleanly through parent-child inheritance, hierarchical authorization is usually simpler to operate, audit, and explain. If access depends on rich relationships that vary by object, context, or path, graph-based FGA gives you the expressiveness to model that complexity without inventing awkward role layers.
That distinction matters because the wrong model creates long-term friction. Overusing hierarchy can lead to role explosion and brittle exceptions, while forcing everything into graph-based FGA can add unnecessary policy complexity where a clear containment model would have been enough.
In practice, the best test is whether the product’s access rules are stable enough to be represented as a tree. If the answer is yes, the simpler model usually wins on predictability. If the answer is no because users can reach the same object through multiple meaningful relationships, the graph model better matches the product’s semantics and reduces policy workarounds.
Where Hierarchy Fits Naturally
Hierarchical authorization works best when the product already has a natural nested structure, such as organisations containing workspaces, workspaces containing projects, and projects containing resources. In that shape, access often flows downward, and inherited permissions are easy to reason about.
This model is strongest when teams want consistency and fast comprehension. Administrators can answer questions like “who inherits access here?” without traversing a large relationship graph, and reviewers can validate access by following the containment chain. That makes hierarchy a strong fit for standardised enterprise structures, internal platforms, and systems where most access decisions are coarse-grained.
Hierarchies also tend to be easier to govern when the main control goal is predictable delegation. The trade-off is that exceptions become more visible and sometimes awkward, because any access pattern that does not fit the tree has to be handled as an override, a special rule, or a separate mechanism.
Where Graph-based FGA Pays Off
Graph-based FGA is the better choice when authorization depends on relationships that are not simply parent-child inheritance. Examples include shared ownership, direct membership, document-level collaboration, delegated access, or access that depends on how a user, group, team, or resource is connected in the product’s data model.
The advantage is precision. A graph model can express “user is a member of team that owns project that grants access to resource” without flattening that logic into roles that are too broad or too many. If your product has many object types and many ways for access to be granted, FGA can keep the policy aligned with the application instead of forcing the application to fit the policy.
The cost is that teams need stronger discipline around schema design, relationship definitions, and query performance. Graph-based authorization is not automatically better, it is better when the access model is genuinely relationship-centric and would otherwise accumulate manual exceptions. For teams comparing authorization patterns, the broader Authorisation Models Guide is useful context for where FGA sits relative to RBAC, ABAC, and ReBAC.
How Teams Should Make the Decision
Start by mapping the product’s real access paths, not the idealised ones. If most permissions can be explained by containment, inheritance, and a small number of overrides, hierarchical authorization is probably sufficient. If access depends on shared projects, ad hoc collaboration, resource-specific relationships, or multiple valid paths to the same object, graph-based FGA is more likely to scale with the product.
What to verify: Check whether your current permissions model can answer the common questions your support, security, and customer teams actually ask. If every answer requires a custom exception or a hard-to-maintain role, the model is too rigid. If every answer requires traversing many relationships, the model is too simple.
Common mistake: Choosing graph-based FGA because it sounds more advanced, or choosing hierarchy because it is familiar. The better question is which model preserves the product’s access semantics with the least distortion. A model that fits the business structure is usually easier to secure, explain, and maintain over time.
Risk and Threat Considerations
Authorization model choice affects exposure as much as developer ergonomics. A hierarchy that is too coarse can spread access farther than intended, while an overcomplicated graph can hide privilege paths that are hard to review, test, or recertify. The main risk is not theoretical sophistication, it is a mismatch between the policy model and the way access actually works.
Failure mechanism: In a hierarchy, inherited permissions can become overly broad when exceptions pile up around the tree. In a graph, relationship sprawl can make it easy to miss an indirect access path or to grant access through an unexpected link.
Impact: Teams can end up with excessive access, inconsistent enforcement, difficult audits, and higher odds of authorisation bugs that surface only in edge cases or after organisational change.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V8 — Authorization | The question is about choosing an authorization model and enforcing access decisions. |
| Recommendation — Define and verify authorization rules so the chosen model matches the application's access paths. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Model choice directly affects how access decisions are enforced across objects and relationships. |
| AC-6 — Least Privilege | The model must avoid excessive access, especially where inheritance or graph paths broaden permission. | |
| Recommendation — Implement access enforcement rules that reflect the selected hierarchy or relationship model. Constrain permissions to the minimum required by the chosen authorization model. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Authorization model selection determines how access control is designed and governed. |
| A.8.3 — Information access restriction | Both hierarchical and graph-based approaches exist to restrict access to information by relationship. | |
| Recommendation — Document and operate access control rules that match the product's permission structure. Apply information access restrictions that align with the chosen authorization pattern. | ||
Practitioner Guidance
Where to start: Catalogue the top 10 to 20 access decisions your product must support and classify each one as inheritance-driven or relationship-driven. That exercise usually makes the right model obvious faster than debating terminology.
Decision rule: If your access story can be explained cleanly to an auditor as “children inherit from parents, with limited overrides,” hierarchy is usually the better default. If you need to explain access through ownership, membership, delegation, and object-specific relationships, graph-based FGA is the better fit.
What good looks like: The authorization model should mirror the product’s own data relationships closely enough that teams can reason about access without translation layers. That usually produces better maintainability than trying to force every permission into a single abstraction.
Practitioner takeaway: Pick the simplest model that matches the product’s true access patterns, then enforce it consistently; complexity only helps when it removes real policy distortion.
Related resources from NHI Mgmt Group
- How should teams decide between a visual LLM builder and a graph-based orchestration framework for production AI workflows?
- How should teams decide between policy-based access control and Zanzibar-style relationship-based access control for authorization?
- How should teams decide between sidecar and service-based authorization deployment?
- How should security teams decide whether JIT access is safe for non-human identities?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org