An account hierarchy is the relationship structure that determines how users, groups, tenants, or organisations inherit access and administrative authority. In CIAM, it is a governance mechanism because it shapes delegation, segmentation, and how access decisions are enforced across different user populations.
Expanded Definition
Account hierarchy describes how identities are organised into parent-child relationships that determine inherited access, delegated administration, and policy scope. In CIAM and enterprise IAM, it is not just a reporting structure. It controls who can create accounts, approve changes, segment populations, and apply controls across tenants, subsidiaries, regions, or application groups.
For NHI security, account hierarchy matters because machine identities often inherit permissions indirectly through organisational containers, service groups, or project structures. That makes hierarchy a governance layer, not merely an admin convenience. In mature implementations, it shapes how NIST Cybersecurity Framework 2.0 functions are enforced across environments, especially where delegated administration and segmentation are used to limit blast radius. Definitions vary across vendors when hierarchy is treated as a billing construct, an access model, or a tenant boundary, so the operational meaning must be explicit.
Account hierarchy is commonly misapplied when teams assume that separating folders, tenants, or groups automatically enforces isolation without verifying inherited permissions, delegated roles, and cross-boundary trust paths.
Examples and Use Cases
Implementing account hierarchy rigorously often introduces administrative complexity, requiring organisations to weigh delegation speed against the cost of auditing inherited privileges and trust relationships.
- A parent organisation delegates application administration to regional subsidiaries while retaining control over policy templates and emergency override rights.
- A CIAM platform uses tenant hierarchy so consumer, partner, and internal accounts are segmented, but shared services still require carefully scoped cross-tenant access.
- An engineering platform assigns service account to project-level containers, so CI/CD automation inherits only the permissions needed for one workload boundary.
- A cloud platform maps organisational units to separate account trees, with central security teams reviewing how access propagates through child accounts and groups.
- In NHI governance, hierarchy is used to separate production from non-production identities, reducing the chance that a low-trust test account can influence a high-value environment.
These patterns are closely tied to the lifecycle and visibility problems described in the Ultimate Guide to NHIs, especially where inherited access hides excessive privilege. The same design choices also intersect with identity assurance and access governance principles in NIST Cybersecurity Framework 2.0.
Why It Matters in NHI Security
Account hierarchy becomes security-critical because inherited authority can spread faster than direct provisioning. If a parent account, tenant root, or top-level group is over-privileged, every child identity may inherit more access than intended. That is a common pathway to privilege creep, misaligned delegation, and weak separation of duties across service accounts, API keys, and automation agents.
This is especially important in NHI environments where identities are numerous and often poorly governed. NHI Mgmt Group notes that Ultimate Guide to NHIs reports that 97% of NHIs carry excessive privileges, and account hierarchy is one of the structural reasons those privileges persist undetected. A misdrawn hierarchy can also undermine Zero Trust segmentation by creating hidden trust chains that bypass intended controls. Practitioners should treat hierarchy reviews as part of access engineering, not only as an IAM cleanup task.
Organisations typically encounter the consequences only after a compromised service account, tenant admin, or automation token is used to move laterally across inherited boundaries, at which point account hierarchy becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC | Account hierarchy shapes who inherits access and delegated admin authority across identity boundaries. |
| NIST Zero Trust (SP 800-207) | Hierarchy can create hidden trust paths that conflict with Zero Trust segmentation and least privilege. | |
| OWASP Non-Human Identity Top 10 | NHI-01 | Inherited access and delegated admin paths increase NHI privilege exposure and governance risk. |
Map inherited permissions and delegation paths, then review hierarchy-driven access as part of access control governance.
