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.

Directory roles are assigned to persona groups (PAGs), never to people, in azure-privileged-access-grants (Lane A). Every row below is applied the same way: MR, then apply-merged with the operator persona active.

Role	Tier	EAM plane	Project	Apply method	Role engineer needs to apply
Global Administrator	0	Control	azure-privileged-access-grants	./apply.ps1	Tier 0 project group (pag-t0-manage-azure-privileged-access-grants: Privileged Role Administrator can assign any role, including GA)
Privileged Role Administrator	0	Control	azure-privileged-access-grants	apply-merged	Operator persona
Security / Identity Governance / Groups / Application / User Administrator	0 (mechanism)	Control (mechanism), bounded (capability)	azure-privileged-access-grants	apply-merged	Operator persona
Global Reader: read-only across almost all Entra/admin-center data	0 (mechanism) / 2 (capability)	Control (mechanism)	azure-privileged-access-grants	apply-merged	Operator persona
Security Reader: read-only over Defender/Sentinel/Identity Protection data	0 (mechanism) / 2 (capability)	Control (mechanism)	azure-privileged-access-grants	apply-merged	Operator persona

Eligibility is never assigned in code. A person becomes eligible for a persona group only through an approved access package request (azure-privileged-access-packages, bound as Eligible Member), and every use is a time-boxed PIM activation. See Manage Access Packages.

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. The operator persona holds PRA, so the operator persona is Tier 0 and is guarded like Global Admin: eligibility only through an approved access package, time-boxed activation with MFA and justification, and — once there's a second approver — approval on activation.

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. Today every persona activation requires MFA and a justification but no approval (solo operator); approval on activation is planned once there is a second approver, and it should start with mg-management and the Tier 0 personas.

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 roleAssignments/write at that scope (Owner, UAA or Role Based Access Control Administrator). 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.

Who holds roleAssignments/write at these scopes today:

• Humans, through azure-privileged-access-grants: the operator persona holds RBAC Administrator at the tenant root, conditioned to Owner / Reader / Storage Blob Data Contributor / Storage Blob Data Reader, assigned to groups only. Anything outside that condition (for example a role for a service principal) needs Emergency Tenant Recovery (Owner at the tenant root).
• CI identities at mg-intermediate-root:
  • EPAC's deploy-roles identity — accepted exception EX-003.
  • Both subscription-vending identities hold unconditioned RBAC Administrator there — a known gap, GAP-011: they could assign Owner at mg-intermediate-root. The fix is an ABAC condition excluding Owner / UAA / RBAC Administrator, and a narrower scope.
• No CI identity holds roleAssignments/write at the tenant root.

For scoping patterns, role specialisation and JIT governance, see the reader personas (pag-reader-tenant, pag-reader-mg-platform, pag-reader-mg-landing-zones) in Manage Access Packages.

MG layer	Role	Tier	EAM plane	Apply method
Tenant Root Group	Owner / UAA	0	Control	apply-merged (grants)
	Reader	0 (mechanism) / 2 (capability)	Control (mechanism)	apply-merged (grants)
mg-intermediate-root	Owner / UAA	0	Control	apply-merged (grants)
	Reader	0 (mechanism) / 2 (capability)	Control (mechanism)	apply-merged (grants)
	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