Hierarchy-based authorization is still an IAM governance problem

At a glance

What this is: This is an analysis of hierarchy-based authorization in multi-tenant applications, showing how Cerbos models descendant and child access through policy-defined roles or dynamic attributes.

Why it matters: It matters because IAM teams often treat hierarchical access as an application detail, when in practice it shapes tenant isolation, policy sprawl, and auditability across human, service, and workload identities.

By the numbers:

• NHIs outnumber human identities by 25x to 50x in modern enterprises.

👉 Read Cerbos' full guide to hierarchy-based authorization in multi-tenant apps

Context

Hierarchy-based authorization is the problem of deciding whether an identity can access a parent node, its descendants, or only immediate children inside a resource tree. In multi-tenant applications, that question quickly becomes an identity governance issue because the policy must preserve tenant isolation while still reflecting real business structure and operational delegation.

The core tension is between readability and scale. Static role policies are easy to inspect, but they tend to multiply as tenants, regions, and business units grow. Dynamic attribute-driven policies reduce policy sprawl, but they shift complexity into the quality and consistency of principal attributes at runtime.

For IAM and NHI programmes, the lesson is broader than one authorization engine. Hierarchical access models are where RBAC, ABAC, and ReBAC start to overlap, and that overlap is where auditability, lifecycle management, and entitlement review get harder rather than easier.

Key questions

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. Define tenant boundaries, parent-child reach, and exception handling separately, then decide whether the policy should be explicit per role or centralised through attributes. The right design is the one your teams can review, test, and recertify without losing isolation.

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. They reduce policy proliferation and make one policy reusable across many scopes. The trade-off is that identity data quality becomes part of the authorization boundary, so provisioning and attribute governance must be strong.

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. If the parent node is too broad, one entitlement can expose far more data than the business intended. Teams should review subtree reach as carefully as they review direct access.

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.

Technical breakdown

ReBAC in hierarchical resource trees

Relationship-based access control, or ReBAC, grants access based on relationships between identities and resources rather than only on static roles or single attributes. In the article's pattern, hierarchy(), descendantOf(), and immediateChildOf() let the policy evaluate whether a user is authorised for a parent node, a child node, or an entire subtree. That is a practical way to express business hierarchy, regional structure, and delegated ownership in one model. The architectural benefit is expressiveness. The risk is that the relationship graph becomes part of the security boundary, so resource modelling and hierarchy consistency matter as much as the policy syntax itself.

Practical implication: model hierarchical resources explicitly before writing policy logic.

Policy-defined roles versus dynamic attribute-driven policy

The article contrasts two ABAC implementations. In the first, roles such as germany_sales_manager are defined in policy files and paired with hierarchical conditions. In the second, the principal carries access_rules and allowed_actions, and the policy evaluates those attributes generically. The first approach is easier to audit role by role, but it creates policy proliferation as tenants grow. The second centralises logic and scales better, but it depends on trustworthy attribute population at runtime. That means authorization quality is no longer only a policy problem. It becomes an identity data integrity problem too.

Practical implication: decide whether policy drift or attribute drift is the more dangerous failure mode.

Tenant isolation in PBAC systems

Policy-based access control, or PBAC, executes authorization logic from policy rather than hardcoded application code. In a multi-tenant setting, the first rule is usually a deny condition that blocks cross-tenant access unless the principal tenant matches the resource tenant. That isolation rule is foundational because hierarchy logic is useless if tenant boundaries are porous. Cerbos uses principal and resource attributes to keep that boundary check separate from the more nuanced hierarchy checks. This separation is a useful design pattern for any authorization layer that must support both shared policy logic and tenant-specific data boundaries.

Practical implication: keep tenant isolation as a distinct control, not a side effect of role logic.

NHI Mgmt Group analysis

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.

Policy proliferation is the predictable cost of hardcoding hierarchy into roles. Explicit role policies are readable at small scale, but every new tenant, region, or business unit creates another policy surface to maintain. That increases review effort and the chance of inconsistent exceptions across environments. For identity teams, the practical issue is not only how access is granted but how many distinct artifacts must be recertified, tested, and offboarded over time.

Attribute-driven authorization shifts trust from policy files to identity data quality. When the policy becomes generic and the principal carries access_rules, the security model depends on the accuracy, freshness, and completeness of those attributes. That means provisioning pipelines, identity enrichment, and source-of-truth discipline become part of the authorization control plane. The implication is that governance has moved upstream into identity data management.

ABAC and ReBAC overlap most sharply where tenants, resources, and delegation all meet. The article is a good example of how roles, attributes, and relationships can work together without collapsing into one another. That overlap is where human IAM, service accounts, and application permissions start to resemble the same governance problem. Practitioners should evaluate hierarchy-based access as a cross-domain entitlement pattern, not a one-off app feature.

Identity blast radius: hierarchical access expands the number of records an identity can touch if the parent-child model is too permissive. This is the named concept that matters here because subtree access can turn one entitlement into broad visibility across many records. The governance question is whether the hierarchy is constrained by business need or by convenience. Teams should design for the smallest meaningful reach and keep that reach reviewable.

From our research:

• 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.
• For a broader control view, NHI Lifecycle Management Guide shows how provisioning, rotation, and offboarding support reviewable access paths.

What this signals

Identity blast radius: the more a hierarchy model allows inherited access, the more important it becomes to know exactly which identities can traverse the tree and why. Teams that cannot explain subtree reach in plain language will struggle to recertify it consistently.

With only 5.7% of organisations having full visibility into their service accounts, the same governance gap that affects machine identities also affects application authorization models that rely on rich principal attributes. If the attribute source is weak, the policy will faithfully enforce bad data.

This is where lifecycle governance and authorisation governance converge. Teams should align NHI Lifecycle Management Guide practices with policy review so changes in tenant structure, role scope, or delegated reach are reviewed before they become standing access.

For practitioners

• 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. If identity data drift is the bigger risk, centralise logic and invest in attribute quality controls.
• Review access artifacts as entitlements, not just roles Include hierarchy-based permissions in entitlement recertification so reviewers can see subtree reach, tenant scope, and any exceptions in one view.

Key takeaways

• Hierarchy-based access becomes a governance issue when subtree permissions outgrow the organisation's ability to review them.
• Policy-defined roles are simpler to inspect, but dynamic attributes scale better when tenant and hierarchy complexity increase.
• The decisive control is not the authorisation syntax itself, but whether tenant isolation, attribute quality, and recertification stay aligned.

Key terms

• Attribute-Based Access Control: An access model that grants or denies permissions by evaluating attributes on the identity, resource, and request. In practice, it is useful when roles alone are too blunt and organisations need context-aware decisions that still remain policy-driven and reviewable.
• Relationship-Based Access Control: An access model that authorises actions based on relationships between identities and resources, such as parent, child, or descendant links. It is especially useful for hierarchical data because it can reflect business structure directly in the decision logic.
• Policy-Based Access Control: An authorization approach where executable policy evaluates the context of a request instead of relying only on application code. It gives security teams a central place to define and audit access logic, but it can still become complex when many scopes or exceptions exist.
• Tenant Isolation: The control boundary that prevents one customer, business unit, or environment from accessing another's data or permissions. In multi-tenant systems, it must be enforced independently of convenience rules so hierarchical access never crosses organisational boundaries by accident.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Cerbos: hierarchy-based permissions in Cerbos for multi-tenant applications. Read the original.