Role Tier Mapping: Entra ID and Azure RBAC¶

This page applies the Access Tiering Model to specific roles. It shows which Entra ID directory roles and which Azure RBAC assignments are Tier 0, 1 or 2, and how each one is applied.

The same rule runs through both halves of this page. A role's tier depends on its capability (what the role lets its holder do) and on the mechanism needed to grant it (what is needed to assign it). The higher of the two wins.

Entra ID directory roles¶

Assigning or managing PIM eligibility for any directory role requires the same tenant-wide Graph permission (RoleManagement.ReadWrite.Directory), regardless of how sensitive the specific role looks. Per EAM, PIM/PAM administration is itself Control plane. So the mechanism used to configure eligibility is Control-plane-critical even when the role being configured (for example, Global Reader) is not.

Role	Tier	EAM plane	Project	Apply method	Role engineer needs on CLI
Global Administrator	0	Control	`azure-priv-tier-0`	CLI, human apply	PIM-activate Global Administrator
Privileged Role Administrator	0	Control	`azure-priv-tier-0`	CLI, human apply	PIM-activate Global Administrator (PRA can assign any role, including GA)
Security / Identity Governance / Groups / Application / User Administrator	0 (mechanism)	Control (mechanism), bounded (capability)	`azure-priv-tier-0`	CLI, human apply	PIM-activate Privileged Role Administrator
Global Reader: read-only across almost all Entra/admin-center data	0 (mechanism) / 2 (capability)	Control (mechanism)	`azure-priv-tier-0`	CLI, human apply	PIM-activate Privileged Role Administrator
Security Reader: read-only over Defender/Sentinel/Identity Protection data	0 (mechanism) / 2 (capability)	Control (mechanism)	`azure-priv-tier-0`	CLI, human apply	PIM-activate Privileged Role Administrator

Don't be fooled by read-only roles

Global Reader and Security Reader look harmless because the role is read-only. The mechanism used to grant them is not: it's the same Graph permission that can grant Global Administrator. Per EAM, that mechanism is Control plane, so treat their eligibility management accordingly, even though day-to-day use of the role itself is low-risk.

Privileged Role Administrator is a second path to Global Admin

Privileged Role Administrator can assign any directory role, including Global Administrator. Any control applied to Global Admin eligibility must apply equally to Privileged Role Administrator, or it's a bypass. This is why provisioning PRA itself requires GA, not PRA.

Machine identity creation and service principal permissions

Vending service principals that need directory roles or Microsoft Graph application consent follows the same Control-plane boundary. See Platform Service Principal Vending for the Lane A operating model and operator requirements for azure-service-principals.

Azure RBAC by management group¶

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 that build up 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)"]
    IR["mg-intermediate-root"]
    PLAT["mg-platform"]
    LZ["mg-landingzones"]
    SUB1["Subscription A"]
    SUB2["Subscription B"]

    IR --> PLAT
    IR --> LZ
    PLAT --> SUB1
    LZ --> SUB2

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

Why tenant root and mg-intermediate-root are Tier 0, and mg-platform and mg-landingzones are not¶

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

Owner / UAA at the root or mg-intermediate-root 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, which is exactly EAM's definition of Control plane, whatever 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-intermediate-root's policy, can't reach mg-landingzones, and 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 and backup). They administer other resources, not the identity system. So mg-platform is Tier 1, regardless of how many platform subscriptions it covers.

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" in Data/Workload plane regardless of how many there are.

The one nuance NIST adds, without changing the tier: mg-management hosts central logging and monitoring. Owner there could disable diagnostic settings tenant-wide, which is a genuine AC-6(1) concern (access to a security-relevant function: audit configuration). That justifies stricter Tier 1 handling, such as mandatory PIM approval and 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 Control plane if and when it hosts identity infrastructure, because EAM explicitly lists domain controllers and Entra Connect/AD FS as Control plane. 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. 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 and Policy tenant-wide, including granting itself access to anything built later
`mg-intermediate-root`	0	Control	Same property, scoped to the managed-tenant boundary
`mg-platform`	1	Management	Bounded to its own subtree; children are monitoring and 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 or Entra Connect deployed yet, so nothing to protect

Roles by management group layer¶

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

For scoping patterns, role specialisation and JIT governance, see Reader Access: Architecture, Patterns & Options.

MG layer	Role	Tier	EAM plane	Apply method
Tenant Root Group	`Owner` / `UAA`	0	Control	CLI, human apply
	`Reader`	0 (mechanism) / 2 (capability)	Control (mechanism)	CLI, human apply
mg-intermediate-root	`Owner` / `UAA`	0	Control	CLI, human apply
	`Reader`	0 (mechanism) / 2 (capability)	Control (mechanism)	CLI, human apply
	`Contributor`	1 (no role-assignment rights)	Management	CI, auto-apply
	`Cost Management Reader`	2	Management	CI, auto-apply
mg-platform / mg-connectivity	`Owner` / `UAA` / `Contributor` / `Reader`	1	Management	CI, auto-apply
mg-management	`Owner` / `UAA` / `Contributor` / `Reader`	1 (stricter: AC-6(1), audit function access)	Management	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	CI, auto-apply
mg-quarantine / mg-decommissioned	`Reader` only	2	Data/Workload	CI, auto-apply