Azure RBAC by Management Group — Tier Mapping¶

Part of Privileged Access, PIM, and What Belongs in CI — see that page for the EAM/NIST/CAF/security-levels model this mapping applies.

Management group inheritance¶

Azure RBAC inherits downward only. A role granted at a management group scope is granted at every subscription beneath it, now and for any subscription added later.

Grant at the highest scope only when the role is genuinely needed at every descendant — not because it's one Terraform resource instead of five.
Watch for role assignment sprawl at root — assignments accumulating at the top of the hierarchy over time, because it was the path of least resistance for whoever wrote the code. This is one of the most common findings in real tenant access reviews.
Breadth alone does not determine Tier — see below. But breadth does determine blast radius if something goes wrong, which is why sprawl at root is still worth watching even for Tier 1 roles.

graph TD
    ROOT["Tenant Root Group<br/>(highest blast radius)"]
    GRIN["mg-grinntec"]
    PLAT["mg-platform"]
    LZ["mg-landingzones"]
    SUB1["Subscription A"]
    SUB2["Subscription B"]

    ROOT --> GRIN
    GRIN --> PLAT
    GRIN --> LZ
    PLAT --> SUB1
    LZ --> SUB2

    ROOT -.->|"role here reaches\nevery box below"| GRIN

Why tenant root / mg-grinntec are Tier 0 — and mg-platform / mg-landingzones are not¶

This is the part worth being precise about, because "biggest blast radius" and "Control plane" are easy to conflate and aren't the same thing.

Owner / User Access Administrator at the Tenant Root Group or mg-grinntec is Control plane per EAM, for a specific structural reason: it can modify RBAC and Policy for the entire tenant, including granting itself access to anything built in the future, anywhere in the tree. That's self-referential control over the access-control mechanism itself — exactly EAM's definition of Control plane, independent of what happens to be deployed under it today.

Owner / UAA at mg-platform cannot do that. It's bounded to its own subtree — it can't touch mg-grinntec's policy, can't reach mg-landingzones, can't grant itself access outside mg-platform. Its children (mg-connectivity, mg-management) are Management plane by EAM's own examples (hub networking, monitoring/backup) — administering other resources, not the identity system. So mg-platform is Tier 1, regardless of how many platform subscriptions it happens to cover.

Owner / UAA at mg-landingzones is Data/Workload plane per EAM, even as one aggregate grant covering every current and future workload subscription. Breadth doesn't promote it — EAM's own examples put "application subscriptions" squarely in Data/Workload plane regardless of count.

The one nuance NIST adds, without changing the tier: mg-management hosts central logging/monitoring. Owner there could disable diagnostic settings tenant-wide — a genuine AC-6(1) concern (access to a security-relevant function: audit configuration). That justifies stricter Tier 1 handling — mandatory PIM approval, activation alerting — not promotion to Tier 0. This project already requires PIM approval on every grant it manages regardless of level, so this is already covered, not a gap.

mg-identity would become genuinely Control plane — EAM explicitly lists domain controllers and Entra Connect/AD FS as Control plane — if and when it hosts that infrastructure. Today it's reserved and empty, so nothing is managed there at any level. If it's ever populated, mg-platform's Tier 1 grant needs an explicit carve-out at that point, since RBAC inheritance means mg-platform's Owner/UAA would otherwise silently reach the newly-Control-plane mg-identity underneath it.

Scope	Tier	EAM plane	Why
Tenant Root Group	0	Control	Can reconfigure RBAC/Policy tenant-wide, including self-granting access to anything built later
`mg-grinntec`	0	Control	Same property, scoped to the managed-tenant boundary
`mg-platform`	1	Management	Bounded to its own subtree; children are monitoring/networking, not identity infrastructure
`mg-landingzones`	1	Data/Workload	Business applications and data, regardless of breadth
`mg-identity`	(unmanaged — reserved)	Would be Control, if populated	No AD DS/Entra Connect deployed yet — nothing to protect

Azure RBAC by management group layer¶

Creating any role assignment — including Reader — at tenant root or mg-grinntec requires Owner/UAA at that scope to execute. Only azure-priv-tier-0's human-applied identity holds that; azure-platform-identity's CI-applied SP has no roleAssignments/write there at all. So Reader at these two scopes is Tier 0 by mechanism — the one exception to "Reader is always Tier 2" — for the same reason Global Reader is an exception among directory roles (see Entra directory roles).

MG layer	Role	Tier	EAM plane	Project	Apply method
Tenant Root Group	`Owner` / `UAA`	0	Control	`azure-priv-tier-0`	CLI, human apply
	`Reader`	0 (mechanism) / 2 (capability)	Control (mechanism)	`azure-priv-tier-0`	CLI, human apply
mg-grinntec	`Owner` / `UAA`	0	Control	`azure-priv-tier-0`	CLI, human apply
	`Reader`	0 (mechanism) / 2 (capability)	Control (mechanism)	`azure-priv-tier-0`	CLI, human apply
	`Contributor`	1 (no role-assignment rights)	Management	`azure-platform-identity`	CI, auto-apply
	`Cost Management Reader`	2	Management	`azure-platform-identity`	CI, auto-apply
mg-platform / mg-connectivity	`Owner` / `UAA` / `Contributor` / `Reader`	1	Management	`azure-platform-identity`	CI, auto-apply
mg-management	`Owner` / `UAA` / `Contributor` / `Reader`	1 (stricter — AC-6(1), audit function access)	Management	`azure-platform-identity`	CI, auto-apply
mg-identity	(reserved, unused)	Would be Control if populated	—	—	—
mg-landingzones / mg-online / mg-sandboxes	`Owner` / `UAA` / `Contributor` / `Reader`	1 / 2	Data/Workload	`azure-platform-identity`	CI, auto-apply
mg-quarantine / mg-decommissioned	`Reader` only	2	Data/Workload	`azure-platform-identity`	CI, auto-apply