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 or pipeline is Tier 0, Tier 1 or Tier 2, and how strictly each must be controlled. Every classification cites an external standard rather than this tenant's own judgment about what "feels" sensitive. The standards are 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.

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 controls identity or access itself: Tenant Root Group and mg-intermediate-root, Entra directory role and PIM administration, service principal vending and Graph consent, tenant root state storage. 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: mg-platform and its children (mg-connectivity, mg-management). Lane B: scoped OIDC, apply on merge
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

The rest of this page explains where these boundaries come from.

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. So anything that can control a Tier 0 identity, such as a CI pipeline, its runners or its templates, is itself Tier 0.

"Does independent evidence 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

Two frameworks, reasoning from different starting points (architectural function and business impact), independently draw the Tier 0/1 line in the same place. That agreement is the real justification for treating mg-platform and mg-landingzones as below Tier 0, not EAM alone. 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 satisfies condition 2 directly, and deliberately goes beyond condition 1: Tier 0 apply is human-only rather than a pipeline governed "as if" it were human. See Tier 0 Pipeline Design and Lane A and Lane B.

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 Reader Access Options 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

  • 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. mg-landingzones and mg-platform are not Tier 0.
  • Only scopes that give self-referential control over the tenant's own access-control mechanism are Tier 0. These are the Tenant Root Group and mg-intermediate-root, plus systems EAM explicitly names as Control plane: directory role administration, PIM, and mg-identity if it is ever populated with AD DS or Entra Connect.
  • Read-only roles can still be Tier 0 by mechanism.
  • Scale control strictness by NIST's AC-6 family, independent of tier.
  • The Tier 0/1 boundary isn't just this tenant's reading of EAM. Microsoft's separately reasoned security-levels framework draws the same line, calling Tier 0 "Privileged" and Tier 1 "Specialized".
  • CAF is the one reference that discusses pipelines, and its baseline is more permissive than the rest of this model might suggest. A privileged pipeline is acceptable if it is governed as rigorously as a human and can't escalate its own privileges. This tenant's human-only Tier 0 apply is a deliberate choice to go beyond that minimum, not a misreading of it.
  • Open gap: Tier 0 apply does not yet specify or enforce which device it happens on (PAW). See the callout above.