Skip to content

Access Tiering Model: EAM, NIST and Tier 0/1/2

This page defines how the tenant decides whether an identity, role, scope, resource or pipeline is Tier 0, Tier 1 or Tier 2, and how strictly each must be controlled. The classifications are grounded in external standards: Microsoft's Enterprise Access Model (EAM), Microsoft's privileged access security levels, the Cloud Adoption Framework's landing zone identity guidance and NIST SP 800-53 Rev. 5. Where this page applies them to the tenant's own structure (management groups, pipelines, Graph permissions), which the standards don't name, it says so.

This page is the desired state

This page states how the tenant should be. Where a deployment, identity or role assignment doesn't match it, the deployment is wrong, not the page. Known mismatches are recorded in the Exceptions Register until they are fixed.

This is the model. These pages apply it:

External references:

Security tiers are not module tiers

The Tier 0/1/2 on this page are security tiers. They are unrelated to the Tier 1/2/3 layers in the 3-Tier Terraform Module Taxonomy, which describe how Terraform code is structured.

Tier 0, 1 and 2 at a glance

Tier EAM plane Microsoft security level What it covers in this tenant Delivery
Tier 0 Control plane Privileged Anything that passes the Tier 0 test: Tenant Root Group and mg-intermediate-root, Entra directory role and PIM administration, service principal vending and Graph consent, Conditional Access and authentication methods, tenant root state storage, and anything that can take over a Tier 0 identity. mg-identity too, if it ever hosts AD DS or Entra Connect. Lane A: plan-only CI, PIM-elevated human apply
Tier 1 Management plane Specialized Systems that administer other resources, bounded to their own subtree and holding no Tier 0 asset: mg-platform and its children (mg-connectivity, mg-management). Lane B: scoped OIDC, apply on merge, pipeline requirements met
Tier 2 Data/Workload plane Enterprise Business systems and data: mg-landingzones and every workload subscription, however many there are. Lane B: scoped OIDC, apply on merge, pipeline requirements met

The management group column is this tenant's application of EAM. EAM classifies systems by function and doesn't mention management groups. The rest of this page explains how the boundaries are drawn.

The Tier 0 test

An identity, system, scope or resource is Tier 0 if it can do any of the following to a Tier 0 asset:

  1. Grant or change access to it. For example, assign Entra directory roles, grant Microsoft Graph application permissions or admin consent, assign Azure roles at the Tenant Root Group or mg-intermediate-root, or change PIM eligibility and role settings.
  2. Obtain the credentials or tokens of a Tier 0 identity. For example, add a secret, certificate or federated credential to its app registration, own its app or service principal, reset its authentication methods, change the membership of a group that grants Tier 0 access, or control the pipeline, runner or templates that sign in as it.
  3. Change a control that gates Tier 0 access. For example, Conditional Access policies, the authentication methods policy, PIM settings, or cross-tenant access and federation settings.
  4. Read or write Tier 0 state or secrets. For example, the Terraform state of a Tier 0 deployment, or a key vault holding a Tier 0 secret.

The test is transitive: if something can control a Tier 0 thing, it is Tier 0 too. This is EAM's plane isolation principle: a lower-trust system must never be able to control a higher-trust one. The same test, with "Tier 1" in place of "Tier 0", decides whether something is at least Tier 1.

The test applies to what an identity can do, whatever mechanism grants it: an Entra directory role, a Graph application permission, an Azure role, app or group ownership, or a pipeline's federated credential. Breadth alone never promotes anything. A role reaching every workload subscription is still Tier 2 if it can't do any of the four things above to a Tier 0 or Tier 1 asset.

Permissions that pass the test

These are Tier 0 wherever they are held, including by a Tier 1 or Tier 2 pipeline identity. The list is not complete: anything that passes the test is Tier 0, whether or not it appears here.

Permission Why it is Tier 0
RoleManagement.ReadWrite.Directory Can assign any directory role, including Global Administrator (test 1).
AppRoleAssignment.ReadWrite.All Can grant any Graph application permission, including to itself (test 1).
Application.ReadWrite.All Can add a credential to any app registration, including a Tier 0 one, and sign in as it (test 2).
Application.ReadWrite.OwnedBy Tier 0 if the caller owns any Tier 0 app or service principal (test 2). Otherwise it follows the tier of the apps it owns.
Group.ReadWrite.All Can change membership of any group that is not role-assignable. Tier 0 unless every group that grants Tier 0 access is role-assignable (test 2).
UserAuthenticationMethod.ReadWrite.All Can reset or add authentication methods for privileged users (test 2).
Policy.ReadWrite.ConditionalAccess, Policy.ReadWrite.AuthenticationMethod Can weaken the controls that gate Tier 0 sign-in (test 3).
Owner, User Access Administrator or Role Based Access Control Administrator without conditions, at the Tenant Root Group or mg-intermediate-root Can grant any role across the tenant, including to itself (test 1).
Any role that can list storage account keys or write blob data on Tier 0 state storage Can read or rewrite the state that Tier 0 applies use (test 4).

Read-only Graph permissions (*.Read.All) do not pass the test on their own. They still need the stricter handling described under NIST SP 800-53 when they expose security-relevant data.

Placement: Tier 0 assets live in Tier 0 scopes

Azure RBAC is inherited. Every role at a management group or subscription also applies to every resource below it. So a resource's effective tier is capped by the lowest-tier scope above it: anyone with write access to any parent scope can control it.

The rule:

  • A Tier 0 resource must sit in a scope where every parent scope's write roles are themselves Tier 0. Typically this means a subscription under a Tier 0 management group, or a subscription that only Tier 0 identities can write to.
  • If a Tier 0 resource sits inside a Tier 1 scope, the write roles on that scope (Owner, Contributor, User Access Administrator, and any role with listKeys) become Tier 0 by the Tier 0 test. Either move the resource, or treat those roles as Tier 0 and deliver them through Lane A.
  • A resource that mixes tiers, such as a storage account holding both Tier 0 and Tier 1 state, is Tier 0 at the account level. Lower-tier identities may only hold container-scoped data-plane roles on their own containers.

mg-identity is an instance of this rule. If it ever hosts AD DS or Entra Connect, it becomes Tier 0, and mg-platform's Owner and User Access Administrator grants above it would become Tier 0 too unless they are carved out.

Known gap: tenant root state storage sits under a Tier 1 scope

The tenant root state storage account (sa<tenant>tenantroot in rg-terraform-state) holds the state of Tier 0 deployments. It sits in the management subscription under mg-platform, which is Tier 1, and shared-key access is enabled on it. So any Contributor or Owner at mg-platform, mg-management or the management subscription can list its keys and read or rewrite Tier 0 state. Under this page that makes those roles Tier 0. The fix is either to move the account to a Tier 0 scope or to disable shared-key access and remove management-plane write from Tier 1 identities on it. Tracked in the Exceptions Register.

How the model uses its four references

Four questions come up constantly when scoping access, and each has a different standard behind it.

"Which tier does this role belong to?": EAM

EAM splits every system into three planes, classified by function, not by how many resources a role's scope happens to reach:

Plane What it means EAM's own examples
Control plane Systems that control identity and access itself. Compromising one lets you reconfigure who has access to anything, including things built later. Domain controllers, Entra Connect/AD FS, PKI/CA issuing systems, PIM/PAM administration
Management plane Systems that administer other resources Monitoring, automation accounts, backup, network management
Data/Workload plane The business systems and data themselves Application subscriptions, workload resources

A common mistake is treating a role's breadth (how many subscriptions it reaches) as a proxy for its tier. EAM doesn't do that. A role that reaches every workload subscription in the tenant is still Data/Workload plane if it can't touch the identity system itself.

EAM's other key principle is plane isolation: a lower-trust system must never be able to control a higher-trust one. The Tier 0 test is how this page applies it.

"Does a second framework agree with EAM's boundary?": security levels

Microsoft's privileged access security levels framework classifies by business impact of compromise rather than architectural function. It lands on the same line:

Security level Definition (Microsoft's own wording, paraphrased) Maps to
Enterprise Baseline, all users and productivity scenarios Tier 2
Specialized Elevated business impact, but explicitly "not enterprise-wide". Named examples include admins of individual high-impact workloads. Tier 1
Privileged Highest level. Named examples include Entra administrator roles and "identity management roles with administrative rights to an enterprise directory, identity synchronization systems, federation solution... or privileged identity/access management system". Tier 0

The two frameworks start from different questions (architectural function and business impact) and draw the Tier 0/1 line in the same place. Both come from Microsoft's privileged access guidance, so this is a consistency check rather than independent corroboration. It supports treating mg-platform and mg-landingzones as below Tier 0, provided they hold no Tier 0 asset (see Placement). See Azure RBAC by management group for the full walkthrough.

"How strict does the control need to be?": NIST SP 800-53

NIST's AC (Access Control) family, plus the audit controls that evidence it:

Control What it requires
AC-6 Least Privilege Grant the minimum access needed, nothing broader.
AC-6(1) Authorize Access to Security Functions Extra scrutiny for access to audit and security-relevant functions, such as diagnostic settings and logging configuration.
AC-6(5) Privileged Accounts Privileged accounts are restricted to explicitly authorized individuals for explicitly authorized purposes, not a shared identity used for routine work.
AC-2(6) Dynamic Privilege Management Privilege is granted just-in-time, not held standing.
AC-5 Separation of Duties The person or system proposing a change should not be the same one that executes it unsupervised.
AU-2 and AU-6 Audit Events and Review Privileged actions are logged and the logs are reviewed for unauthorized change.

EAM tells you which roles are Control-plane-critical. The security-levels framework cross-checks that boundary against business impact. NIST tells you how strict the handling of any given role needs to be, scaled to its impact, and this is independent of tier. For example, mg-management's audit-function sensitivity (AC-6(1)) earns stricter Tier 1 handling, not promotion to Tier 0.

"Is a CI pipeline even allowed to hold privileged access?": CAF

None of the first three sources address this. They are written for human admin accounts and workstations, not Terraform pipelines. The answer comes from CAF's landing zone identity guidance, the one source here that talks about automation directly.

CAF does not say a pipeline must never hold privileged access. It says a privileged pipeline is acceptable if two conditions hold:

  1. It is governed with tools and policies equivalent to a human holding the same privilege.
  2. Its role assignments structurally prevent it from escalating its own privileges. CAF's own example: "deployment pipelines... should have role assignments that prevent an application owner from escalating their own privileges."

This tenant goes beyond condition 1 for Tier 0: Tier 0 apply is human-only rather than a pipeline governed "as if" it were human. For Tier 1 and Tier 2 pipelines, both conditions are turned into the requirements below.

Pipeline requirements

Tier 0

No pipeline identity holds write access to a Tier 0 asset. CI plans with a read-only identity, and a named person applies main's saved plan under their own PIM-activated role (Lane A). The Lane B split-identity exception, where a human can't apply, is defined in Lane A and Lane B and must be recorded in the Exceptions Register.

Tier 1 and Tier 2

A pipeline identity that applies on merge must meet all of these:

Requirement What it means Standard
Fails the Tier 0 test It holds nothing listed under Permissions that pass the test, owns no Tier 0 app or service principal, and has no write access to any scope that holds a Tier 0 asset. EAM plane isolation
Can't escalate Role Based Access Control Administrator and User Access Administrator are only granted with conditions that block assigning Owner, User Access Administrator and Role Based Access Control Administrator, and block assigning any role to the identity itself. Owner is not granted to pipeline identities. CAF condition 2, AC-6
Bounded scope Its role assignments sit at the narrowest scope that works, and never above the management group of its own tier. AC-6
Write only from main The identity that applies trusts only the protected default branch in its federated credential. Merge request and branch pipelines plan with a separate read-only identity. A credential that trusts every branch of a project lets unreviewed code use the write identity. AC-5, CAF condition 1
No stored secrets Workload Identity Federation only. No client secrets or certificates. AC-2
Reviewed and logged Every change goes through a merge request with a reviewer, and the identity's sign-ins and changes reach the central Log Analytics workspace. AC-5, AU-2, AU-6

Capability versus mechanism

A role's tier depends on two things, and the higher one wins:

  • Capability: what the role lets its holder do. Reader is harmless.
  • Mechanism: what is needed to grant or configure the role. Assigning Reader at the Tenant Root Group needs Owner or User Access Administrator at root. Making someone eligible for Global Reader needs the same Graph permission (RoleManagement.ReadWrite.Directory) that can grant Global Administrator.

So read-only roles can still be Tier 0 by mechanism. Global Reader, Security Reader, and Reader at tenant root or mg-intermediate-root are all configured through Control-plane mechanisms, even though the access they grant is low-risk. See Manage Access Packages (the reader personas) and Entra directory roles.

Known gap: Privileged Access Workstations (PAW), not yet addressed

Microsoft's security-levels framework requires Privileged-level accounts never to share an identity or device with general productivity work. This is the dedicated-hardware requirement that the "Privileged Access Workstation" model is named after. This tenant's design says Tier 0 apply is done by a human, with a local az login and a PIM-activated role, but says nothing about which device that happens on. If a senior engineer runs it from their everyday laptop (the one used for email and general browsing), that is a real, unaddressed gap against this standard, independent of everything else described here. Closing it means deciding on dedicated hardware, a hardened build, or an equivalent compensating control. That is a separate decision this page doesn't make. See Privileged Access Workstations for the options and a recommendation.

Summary

  • This page is the desired state. Anything that doesn't match it is a defect to fix or a recorded exception.
  • Classify by function (EAM's three planes), not by breadth. A role reaching every subscription in the tenant is still Data/Workload plane if it can't touch the identity system itself.
  • Something is Tier 0 if it passes the Tier 0 test: it can grant access to, take over, weaken the controls on, or read or write the state of a Tier 0 asset. The test is transitive and applies to every mechanism: directory roles, Graph permissions, Azure roles, ownership and pipelines.
  • Placement matters: a Tier 0 asset inside a Tier 1 scope makes that scope's write roles Tier 0. Tier 0 assets live in Tier 0 scopes.
  • Read-only roles can still be Tier 0 by mechanism.
  • Scale control strictness by NIST's AC-6 family, independent of tier.
  • Microsoft's security-levels framework draws the same Tier 0/1 line as EAM, calling Tier 0 "Privileged" and Tier 1 "Specialized". Both come from Microsoft's privileged access guidance, so this is consistency, not independent proof.
  • CAF is the one reference that discusses pipelines. Tier 0 goes beyond it with human-only apply. Tier 1 and Tier 2 pipelines must meet the pipeline requirements: no Tier 0 permissions, no escalation, write only from main.
  • Open gaps: tenant root state storage sits under a Tier 1 scope, and Tier 0 apply does not yet specify or enforce which device it happens on (PAW). See the callouts above.