Skip to content

Privileged Access, PIM, and What Belongs in CI

Two different things get conflated in most identity deployments: defining the shape of access control, and actually holding or activating privileged access. The first is configuration and safe to automate. The second is a live security event and needs a human control point, not a merge button. Every classification in this section cites the specific external standard it comes from — Microsoft's Enterprise Access Model (EAM), Microsoft's privileged access security levels, the Cloud Adoption Framework's landing zone identity guidance (the one that actually talks about pipelines), and NIST SP 800-53 Rev. 5 — rather than this tenant's own judgment about what "feels" sensitive.

This is the model. The rest of the section applies it:

Other references:

How this page uses its four references

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

"Which tier does this role belong to?" — answered by 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/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

The common mistake — one this page made in an earlier draft, corrected below — 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.

"Does independent evidence agree with EAM's boundary?" — checked against Microsoft's privileged access security levels, a different Microsoft framework that classifies by business impact of compromise rather than architectural function, and 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 vs. business impact), independently draw the Tier 0/1 line in the same place. That agreement is the actual justification for treating mg-platform/mg-landingzones as Tier 1 — not just EAM alone. See Azure RBAC by management group for the full walkthrough.

"How strict does the control need to be?" — answered by NIST SP 800-53, specifically the AC (Access Control) family:

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 specifically for access to audit/security-relevant functions (e.g., diagnostic settings, logging config)
AC-6(5) Privileged Accounts Privileged accounts restricted to explicitly authorized individuals for explicitly authorized purposes — not a shared identity used for routine work
AC-2(6) Dynamic Privilege Management Privilege should be granted just-in-time, not held standing
AC-5 Separation of Duties The person/system proposing a change should not be the same one that executes it unsupervised

EAM tells you which roles are Control-plane-critical. The security-levels framework cross-checks that boundary against business impact. NIST's AC-6 family tells you how strict the handling of any given role needs to be, scaled to its impact.

"Is a CI pipeline even allowed to hold privileged access?" — this is the question none of the first three sources actually address; they're written for human admin accounts and workstations, not Terraform pipelines. The answer comes from CAF's landing zone identity guidance, which is the one source here that talks about automation directly. CAF's baseline is more permissive than this page's earlier draft implied — it does not say a pipeline must never hold privileged access. It says a privileged pipeline is acceptable if two conditions hold:

  1. It's 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 is "deployment pipelines... should have role assignments that prevent an application owner from escalating their own privileges."

See CI/CD and pipeline design for Tier 0 for how this tenant's design satisfies condition 2 directly and deliberately exceeds condition 1.

Every Tier assignment across this section cites one or more of the four references above.

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

Microsoft's security-levels framework requires Privileged-level accounts to never share an identity or device with general productivity work — the dedicated-hardware requirement the "Privileged Access Workstation" model is named for. This tenant's design currently says Tier 0 apply is "human, local az login, PIM-activated Global Administrator" — but says nothing about which device that happens on. If a senior engineer runs that from their everyday laptop (the one used for email and general browsing), that's a real, unaddressed gap against this specific standard, independent of everything else this section describes. Flagged here deliberately rather than silently folded into the existing design — closing it means deciding on dedicated hardware, a hardened build, or an equivalent compensating control, which is a separate decision this page doesn't make for you.

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 Tier 1, not 0.
  • Only scopes that grant self-referential control over the tenant's own access-control mechanism — Tenant Root Group, mg-grinntec — or systems EAM explicitly names as Control plane — directory role administration, and mg-identity if it's ever populated with AD DS/Entra Connect — are Tier 0.
  • Read-only roles can still be Tier 0 by mechanism: Global Reader, Security Reader, and Reader at tenant root/mg-grinntec all require the same Control-plane mechanism to configure, even though the capability granted is harmless.
  • Scale control strictness by NIST's AC-6 family, independent of tier — mg-management's audit-function sensitivity (AC-6(1)) earns stricter Tier 1 handling, not promotion to Tier 0.
  • CAF is the one reference that actually discusses pipelines, and its baseline is more permissive than the rest of this page might imply: a privileged pipeline is acceptable if it's governed with equivalent rigor to a human and can't escalate its own privileges. The two-repo allow-list split satisfies that second condition directly, by CAF's own named example. The human-CLI-only apply is this tenant's deliberate choice to exceed CAF's first condition rather than attempt to meet it — worth knowing as an informed extension of the standard, not a misreading of it.
  • The Tier 0/1 boundary isn't just this tenant's read of EAM — Microsoft's independently-reasoned security-levels framework (business impact, not architectural function) draws the same line, calling Tier 0 "Privileged" and Tier 1 "Specialized."
  • Open gap, not yet addressed: that same framework requires Privileged-level accounts to never share an identity or device with productivity work (the PAW model). This tenant's Tier 0 apply process doesn't yet specify or enforce which device it happens on — see the callout above.