Notifications
Clear all
Topic starter
12/06/2026 9:13 pm
TL;DR: Two ways to handle hierarchy-based permissions in multi-tenant applications are shown by Cerbos, using policy-defined roles or dynamic attributes to express descendant and child access in ABAC and ReBAC patterns. The governance challenge is not the syntax of the policy, but whether authorization logic stays auditable as tenant and resource hierarchies grow.
NHIMG editorial — based on content published by Cerbos: hierarchy-based permissions in Cerbos for multi-tenant applications
By the numbers:
- NHIs outnumber human identities by 25x to 50x in modern enterprises.
Questions worth separating out
Q: How should security teams govern hierarchy-based access in multi-tenant applications?
A: Start by treating the resource hierarchy as a governed entitlement model, not a coding shortcut.
Q: When do dynamic attributes work better than role-based hierarchy policies?
A: Dynamic attributes work better when tenant count, hierarchy depth, or role variation changes faster than policy files can safely keep up.
Q: What do teams get wrong about descendant-based authorization?
A: They often assume descendant access is just a more flexible permission rule, when it can actually widen blast radius across large sections of a hierarchy.
Practitioner guidance
- Map hierarchy rules to governed business domains Document which resource trees, tenant boundaries, and delegated scopes are security-relevant before encoding descendant or child access in policy.
- Separate tenant isolation from hierarchy logic Use a distinct deny rule for cross-tenant access so descendant checks never become a substitute for tenant boundary enforcement.
- Choose the failure mode you can actually govern If policy sprawl is the bigger operational risk, keep role-based hierarchy rules explicit.
What's in the full article
Cerbos' full post covers the implementation detail this analysis intentionally leaves for the source:
- Concrete Cerbos policy examples for tenant-scoped role definitions and hierarchy conditions
- The exact principal and resource attribute structures used in the dynamic approach
- Shared hierarchy check variables that interpret SELF, DESCENDANTS, CHILDREN, and LEAVES conditions
- A side-by-side view of when to choose explicit role policies versus generic attribute-driven rules
👉 Read Cerbos' full guide to hierarchy-based authorization in multi-tenant apps →
Hierarchy-based authorization: what IAM teams need to know?
Explore further
12/06/2026 11:07 pm
Hierarchical authorization is an identity governance problem before it is a policy problem. The article shows that access decisions are not just about who a user is, but where they sit in a business structure and what level of the tree they should reach. That makes hierarchy modelling part of entitlement design, lifecycle review, and audit evidence, not just implementation detail. Practitioners should treat resource trees as governed access domains, not application convenience structures.
A few things that frame the scale:
- NHIs outnumber human identities by 25x to 50x in modern enterprises, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which is why hierarchy-based entitlement models need strong inventory and review discipline.
A question worth separating out:
Q: What is the difference between policy-defined roles and attribute-driven authorization?
A: Policy-defined roles encode hierarchy logic directly in named role rules, which makes the model easier to inspect but harder to scale. Attribute-driven authorization moves the access conditions into principal attributes and evaluates them through a generic policy, which scales better but depends on cleaner identity data and tighter runtime controls.
👉 Read our full editorial: Hierarchy-based authorization is still an IAM governance problem
