Determine an Access Package's Tier¶
Use this before you create a persona and its access package. Work through the steps in order and answer each question yes or no from the facts given. Two engineers with the same request must reach the same tier. If you find yourself weighing opinions, a fact is missing: see Unsure?.
The rule in one line¶
A package's tier is the highest tier of anything its holder can do once they activate it, including anything they can reach through it.
Three things never change the tier:
- Breadth. A role reaching every workload subscription is still Tier 2 if it can't touch a Tier 0 or Tier 1 asset.
- How it's delivered. Every persona is created by the Tier 0 operator in
azure-privileged-access-grants(Lane A), whatever its tier. That sets how the package is built, not who should hold it. - How rarely it's used. A Tier 0 role used once a year is Tier 0.
Step 1 — List every permission¶
Write one row per permission the package grants. Leave the Tier column empty for now.
| # | Permission | Type | Scope | Tier |
|---|---|---|---|---|
| 1 | e.g. Security Admin | Azure RBAC | mg-intermediate-root | |
| 2 | e.g. Security Reader | Entra directory role | Tenant |
Include everything: each Entra directory role, each Azure role with its scope, and any data role (e.g. Storage Blob Data Contributor on a state container).
Step 2 — Check the Tier 0 asset register¶
These are the things in this tenant that are Tier 0. Questions 2 and 3 check every permission against this list.
| Tier 0 asset | Why |
|---|---|
Tenant Root Group and mg-intermediate-root |
Roles here reach the whole tenant, including things built later |
| The management group hierarchy itself | Restructuring it moves subscriptions out from under inherited policy and RBAC |
Entra directory role assignments, PIM settings, and every role-assignable pag-* and sg-t*-* group |
They decide who holds Tier 0 access |
| The privileged access catalog and its access packages | It hands out membership of the persona groups |
| Conditional Access policies and the authentication methods policy | They gate Tier 0 sign-in |
| Tier 0 app registrations and service principals (Tier 0 project pipeline identities) | Their credentials are Tier 0 identities |
| Break-glass accounts | Standing Global Administrator |
Tenant root state storage sa17452008tenantroot, rg-terraform-state, and every scope above it: the management subscription, mg-management, mg-platform |
Holds Tier 0 Terraform state. The scopes above are on this list only because of the known gap (shared-key access, under a Tier 1 scope). Remove them when the gap is closed |
Step 3 — Tier each permission¶
For each row, ask the questions in order. Stop at the first yes and write that tier in the row.
Q1. Is it an Entra directory role that Microsoft marks PRIVILEGED?¶
Check the role in Microsoft's built-in roles reference. Privileged roles carry a PRIVILEGED label.
Yes → Tier 0.
Why: Microsoft applies the label to roles that can escalate, reset credentials or read sensitive security data. This includes read-only roles such as Global Reader and Security Reader. It's Microsoft's published fact, not our opinion.
Q2. Can it grant or change access over a Tier 0 asset?¶
That means any of these, at or above a Tier 0 asset in the register:
Owner,User Access AdministratororRole Based Access Control Administrator(without a condition that blocks those three roles)- Adding or removing members or owners of a group that grants Tier 0 access
- Adding credentials to, or owning, a Tier 0 app or service principal
- Assigning access packages from the privileged catalog
Yes → Tier 0.
Why: the Tier 0 test, point 1 and point 2. Whoever can grant Tier 0 access can grant it to themselves.
Q3. Can it write to, take control of, or read the secrets or data of a Tier 0 asset?¶
Count all three routes:
- Directly, e.g. Storage Blob Data Contributor on a Tier 0 state container, or Management Group Contributor at the Tenant Root Group.
- Through a parent scope. RBAC is inherited, so any write role, or any role that can list storage keys, on a scope above a Tier 0 asset counts. Use the register.
- Through another identity it can steer, e.g. editing a policy definition that a DeployIfNotExists/Modify assignment runs with a managed identity, or editing a runbook or pipeline that signs in as an identity. It takes that identity's tier.
Reading configuration doesn't count. Reading data or secrets does (state files, key vault secrets, storage keys).
Yes → Tier 0.
Why: the Tier 0 test, points 2–4, and the placement rule (a Tier 0 asset inside a scope makes that scope's write roles Tier 0).
Q4. Can it change anything at all, outside the workload landing zones?¶
Any one of these:
- An Entra directory role with any create, update or delete permission (not PRIVILEGED, or Q1 would have caught it)
- Any Azure role that can write at
mg-intermediate-root, or anywhere in themg-platformsubtree - Any role that changes a platform-wide security or governance control: Azure Policy, Defender for Cloud, diagnostic settings, monitoring
Yes → Tier 1.
Why: EAM's management plane. These administer other resources across the platform, but can't reach the control plane (Q1–Q3 already said no).
Q5. Everything else¶
Write access only inside mg-landingzones and workload subscriptions, or
read-only access to configuration anywhere.
→ Tier 2.
Why: EAM's data/workload plane. Read-only configuration access never passes the Tier 0 test on its own.
Step 4 — The package's tier¶
Package tier = the highest tier in the table. One Tier 0 row makes the whole package Tier 0.
If the result surprises you, check Step 1 first: most disagreements are a missing or extra row, not a wrong answer.
Step 5 — Record it in the MR¶
Paste the completed table into the MR description, with the question that said yes for each row (e.g. "Q3 — parent scope: mg-platform holds tenant root state"). A reviewer who disagrees points to one row and one question, and the facts settle it.
What the tier decides¶
| Tier | Persona and package prefix | Requestors / approvers | Access review |
|---|---|---|---|
| 0 | t0-…, (tier 0) … |
sg-t0-requestors / sg-t0-approvers |
local.t0_assignment_review |
| 1 | t1-…, (tier 1) … |
sg-t1-requestors / sg-t1-approvers |
local.t1_assignment_review |
| 2 | t2-…, (tier 2) … |
sg-t2-requestors / sg-t2-approvers |
local.t2_assignment_review |
Unsure?¶
- A question you can't answer yes or no from facts → answer yes. Fail closed: the package goes up a tier, and the missing fact is recorded in the MR for a reviewer to settle.
- The answer depends on something not in the register (e.g. "is this storage account Tier 0?") → stop and add it to the register first, in its own MR. Never decide it inside a package request.
- The role is too broad for the job → that's a least-privilege problem, not a tier question. Split the package or use a narrower role, then tier what's left.
Worked examples¶
Manage Policy & Defender — Security Admin and Resource Policy
Contributor at mg-intermediate-root.
| Permission | Stops at | Tier |
|---|---|---|
| Security Admin @ mg-intermediate-root | Q4: changes Defender, a platform-wide security control | 1 |
| Resource Policy Contributor @ mg-intermediate-root | Q3 if any policy assignment there has a managed identity with Tier 0 reach; otherwise Q4 | 0 or 1 — check the managed identities |
Reader at Platform — Reader at mg-platform: Q1–Q4 no (read-only, can't
list keys) → Tier 2.
Owner at Landing Zones — Owner at mg-landingzones alone: Q2 no (no
Tier 0 asset below it), Q3 no, Q4 no → Tier 2. The real persona also
holds the Entra role Security Administrator (Q1, PRIVILEGED), so the package
is Tier 0.
Tenant Reader — Global Reader: Q1 yes → Tier 0, even though it's read-only.