A hierarchical Azure construct used to organise subscriptions for governance at scale. Management Groups let teams scope policies and connect sets of subscriptions together, rather than handling each subscription separately. In practice, they are a control boundary for applying consistent oversight across a multi-subscription environment.
Expanded Definition
Azure Management Groups are the governance layer above subscriptions, allowing policy assignment, role scoping, and inheritance across multiple subscriptions without repeating configuration at each boundary. In an NHI context, that matters because service principals, managed identities, and automation accounts often operate across subscription fleets rather than inside one isolated environment. Used correctly, management groups help security teams apply consistent controls for NIST Cybersecurity Framework 2.0 style oversight, while also supporting the control discipline described in Ultimate Guide to NHIs — Regulatory and Audit Perspectives. Definitions vary across vendors when people loosely describe them as “folders” or “policy containers,” but in Azure they are specifically a hierarchical control plane for governance inheritance, not a workload runtime boundary.
The practical distinction is important: subscriptions hold resources, while management groups organize subscriptions so policies, RBAC, and compliance expectations can be inherited downward. That makes them especially relevant when NHI access spans shared services, landing zones, and platform teams. The most common misapplication is treating management groups as a substitute for identity design, which occurs when organisations assume hierarchy alone will limit service account blast radius.
Examples and Use Cases
Implementing Azure Management Groups rigorously often introduces governance overhead, requiring organisations to weigh standardisation against the effort of maintaining a clean hierarchy as environments change.
- A platform team places all production subscriptions under one management group so a deny policy for public exposure applies uniformly to automation-driven workloads.
- A security team uses a higher-level management group to enforce tag requirements, diagnostic settings, and RBAC guardrails for service principals across business units.
- A compliance function separates regulated subscriptions into their own branch so audit scopes can be mapped to Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs expectations and reviewed centrally.
- An engineering organisation keeps sandbox subscriptions in a lower-tier management group to prevent broad inheritance of privileged NHI permissions into experimental environments.
- During post-incident review, teams use the hierarchy to identify which subscriptions inherited weak policy assignments, then compare the affected identity paths against Top 10 NHI Issues.
Why It Matters in NHI Security
Azure Management Groups matter because NHI risk is usually systemic, not isolated. NHIMG research shows 97% of NHIs carry excessive privileges, which means weak governance at the hierarchy level can propagate across many subscriptions at once. When a service principal, token, or automation identity is granted broad access in one branch, the impact can extend far beyond the original team’s intent. Management groups are therefore a control amplifier: they can reduce repetition, but they can also multiply mistakes if inheritance is poorly planned. That is why practitioners should align hierarchy design with least privilege, separation of duties, and reviewable ownership, as discussed in Ultimate Guide to NHIs — Regulatory and Audit Perspectives.
This also becomes relevant in incidents where cloud access was already too broad. A policy gap at the management group layer can allow compromised secrets to affect multiple subscriptions before detection, especially when teams do not know which identities inherit which controls. Organisations typically encounter the governance failure only after a cross-subscription incident or audit finding, at which point Azure Management Groups become 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, NIST Zero Trust (SP 800-207), NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Hierarchy misconfiguration expands NHI blast radius across subscriptions. |
| NIST CSF 2.0 | PR.AC | Access control governance depends on consistent inheritance and review. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous policy enforcement across resource boundaries. | |
| NIST SP 800-63 | IAL/AAL | Identity assurance informs how strongly NHI access should be governed. |
| NIST AI RMF | Governance structures must support risk measurement and accountability. |
Document inherited controls and review hierarchy risk as part of AI-adjacent governance.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
