Everything the foundation has built so far is inert until someone has the authority to change it. The management-group tree, the hub, the name resolution wired end to end: none of it acts on its own. It waits for an identity with the right to act on it. That is the quiet truth about Azure that the diagrams never show. Identity is not a supporting service sitting beside the platform. Identity is the control plane, and this article is about who may act on the foundation, under what conditions, and how to arrange that so a team of two or three can operate safely without pretending to be an enterprise security organization.
The control plane was identity all along
Microsoft Entra ID is the root of trust for two planes that people tend to think of as separate and are not. One plane is the directory itself, where roles like Global Administrator govern the tenant, its users, and every Microsoft 365 service attached to it. The other plane is Azure resource management, where roles like Owner and Contributor govern subscriptions, resource groups, and the resources inside them. They feel like different products because they live behind different portals, but they share a single source of identity, and the seam between them is exactly where the most dangerous authority lives. A Global Administrator does not, by default, control Azure resources. But a Global Administrator can grant themselves that control in two clicks, and that single bridge is the reason identity governs everything else you have built.
This is why the governance backbone from earlier in the series is only half a design until identity is decided. The management-group tree inherits nothing without role assignments placed on it. The network you cannot redo later can be redone in an afternoon by anyone holding Owner high enough on that tree. Governance without an identity model is decoration: a shape that looks like control but enforces nothing. The work of this article is to make the shape real, by deciding who holds which rights, at which scope, and with what conditions attached.
Keep one distinction in front of you throughout, because it mirrors a distinction the foundation already made. There is platform identity, meaning who operates the foundation itself, and there is landing-zone identity, meaning who operates the workloads that live on it. You separated Platform from Landing Zones in the management-group tree for exactly this reason, so that the people who run the file server are not, by inheritance, the people who can rebuild the hub. The identity model has to honor that same separation, or the tree stops meaning anything.
Groups are the assignment surface, people are only members
Assign roles to groups, never to people. This is the one rule that survives at every scale, and the reasoning is durability. A role assignment placed directly on a person is a fact you will forget you created, and it will outlive their need for it, their role, and sometimes their employment. A role assignment placed on a group never changes; only the membership does, and membership is the thing you actually want to manage. When someone joins the team, they become a member. When they leave, they stop being one. The access follows the person because the person moves in and out of the group, not because anyone remembered to hunt down a scattered set of direct grants. At three admins this feels like ceremony. It is not. It is the difference between an estate you can reason about and one you audit by archaeology.
Those groups then land on the management-group tree, and where they land is the whole discipline. A role assignment placed at the top of your tree cascades to every subscription, every resource group, and every resource beneath it. That inheritance is a gift when the role is Reader and a loose weapon when the role is Contributor. The instinct to assign high, so that you only do it once, is the instinct to resist. The correct instinct is least privilege: assign at the lowest scope that satisfies the need, and use inheritance deliberately rather than as a shortcut. Almost nothing gets a standing assignment at management-group scope. Reader for org-wide visibility can live there. The right to manage policy can live there, and it should be eligible rather than standing, which the next section explains. Contributor and Owner do not belong at management-group scope in an organization this size, because the blast radius is the entire estate and the benefit is saving yourself a second assignment.
Contributor is the ceiling for standing, day-to-day access. Nobody holds standing Owner at subscription scope. When someone genuinely needs Owner, that is what time-boxed activation is for, not a permanent grant.
There is a hard limit worth designing away from long before you approach it: a subscription accepts a fixed number of role assignments and a management group accepts fewer, and both ceilings are the platform’s, not yours to raise. You will never hit them by assigning groups. You will absolutely hit them by assigning individuals across hundreds of resources, which is one more reason the groups-not-people rule is architectural rather than cosmetic. Design so that the number of assignments grows with the number of teams, not the number of people or resources.
Break-glass, and the thing mandatory MFA quietly changed
Every tenant needs emergency access accounts, and the shape of them is well established: at least two, cloud-only, living on the onmicrosoft.com domain so they depend on nothing federated or synced from on-premises, with long random passwords split into an offline store that two people cannot open alone. Their purpose is the day a Conditional Access policy misfires, or a federation link breaks, or the one administrator who mattered is unreachable, and you need a way into the tenant that no ordinary failure can sever. So far this is doctrine every competent build already follows.
What has changed, and what most existing runbooks still get wrong, is the instruction to exclude break-glass accounts from all Conditional Access. That advice was written for a world where you could carve out an account that met no conditions and answered to no policy, and that world is gone. Microsoft now enforces multifactor authentication on the administration surfaces themselves. Signing into the Azure portal and the admin centers has required MFA since late 2024, and the enforcement extended through late 2025 to the command line, PowerShell, and infrastructure-as-code paths that a break-glass account is most likely to use in a real emergency. Emergency accounts are not exempt from any of it. An account excluded from every policy and carrying only a password is, under this enforcement, an account that cannot sign in when you need it most.
So the modern emergency account is not the account with no controls. It is the account with the strongest credential you can give it and the fewest brittle dependencies. That means a phishing-resistant passwordless method, a passkey on a hardware security key, registered to each account and stored with the offline credentials. The exclusion still matters, but it narrows: exclude these accounts from the restrictive, blocking policies that could lock everyone out at once, the ones that demand a compliant device or a specific location or a named MFA method, and exclude them as well from the Microsoft-managed Conditional Access policies that now arrive switched on by default. Do not exclude them from the simple fact of needing a strong credential, because that requirement is no longer yours to waive. The account that survives an emergency in 2026 is a hardened account with a security key, not an unguarded one.
Standing access is the liability. Eligibility is the design.
The most valuable thing you can remove from an estate is standing privilege. A role that is always active is a role that is always available to whoever compromises the account that holds it, at three in the morning, with no friction and no record beyond the damage. Privileged Identity Management inverts that: the powerful roles become eligible rather than active, and a person activates one when they need it, with a justification, a time box that expires on its own, multifactor at the moment of use, and an approval step on the roles that warrant one. Owner and User Access Administrator are the obvious candidates. Held eligible, they are a capability a person can reach for and the platform records; held standing, they are a liability nobody is watching.
Here is where I will not make a decision silently on your behalf, because it costs real money and it depends on a licensing fact most organizations get wrong. Privileged Identity Management requires Microsoft Entra ID P2. Microsoft 365 Business Premium, which most organizations at this size already own and assume covers everything, includes Entra ID P1, not P2. The capability you most want for privileged access is the one your license does not include. That leaves a genuine fork, and it belongs to the customer, not to me.
One path buys the capability. Entra ID P2, or the standalone Entra ID Governance license which also carries Privileged Identity Management, is purchased as an add-on for the handful of people who actually hold privileged roles. You do not license the whole company. You license the two or three administrators and whoever approves their activations, and at a list price in the region of ten dollars per user each month for P2, and less for Governance, the cost of protecting the keys to the entire estate is a rounding error against what the estate is worth. When the budget allows it at all, this is the path I recommend, because just-in-time privilege is the single highest-leverage identity control available to a small team.
The other path operates without it, and it is defensible when it is done deliberately rather than by neglect. Without Privileged Identity Management you cannot make Owner eligible, so the answer is that nobody holds standing Owner at all. The admin group holds Contributor, which manages every resource but cannot hand out access, and the rare operation that genuinely needs Owner or root-scope authority is performed through a break-glass account or the one-time elevation bootstrap, deliberately and with a record. You compensate for the missing automation with attention: an alert on every privileged role assignment, so that a new Owner anywhere in the estate is something a human sees the moment it happens. This path asks more discipline of the operator and gives less back from the platform, but it is a real design, and it is far better than the common third option, which is standing Owner spread across a handful of accounts because nobody wanted to choose.
Tiering, so the planes do not bleed into each other
The reason to think in tiers is that authority over identity and authority over resources are not the same power, and the accounts that hold each should not be the same accounts. A privileged access model, drawn small for an organization this size, sorts access into three bands and refuses to let them merge. At the top sits the identity control plane: Global Administrator, the roles held eligible through Privileged Identity Management, and the break-glass accounts. This is the tier that can grant every other tier, which is exactly why it is the smallest, the most watched, and the one you never operate from a machine that also reads email and browses the web. Beneath it is the Azure platform tier, where Owner and User Access Administrator are held eligible and Contributor is the standing ceiling for the people who run the foundation. Beneath that is the workload tier, where operators hold Contributor scoped to the resource groups their workloads live in and nothing wider.
The point of the drawing is the refusal in the middle of it. A workload operator does not administer identity. An identity administrator does not run workloads from the same account that governs the directory. The tiers are not a hierarchy of seniority, they are a separation of blast radius, and the whole model fails the moment one account spans two of them for convenience. For a managed-services provider the same separation shows up in a different vocabulary: partner access to Microsoft 365 and Entra flows through Granular Delegated Admin Privileges, partner access to Azure subscriptions flows through Azure Lighthouse, and the two are complementary rather than interchangeable. Set both up deliberately, from the provider’s own tenant identities, so that access is auditable and no shared credential or guest account ever becomes the way in.
Where identity meets the foundation you built
Landed on the tree, the model is quiet and specific. Reader for the readers group can sit at the top of your custom hierarchy, because visibility across the whole estate is harmless and useful. The right to manage policy sits at the same level but held eligible, because whoever runs policy is reshaping enforcement across everything beneath, and that is the article still to come. Contributor for the platform admins sits at the Production subscription, not at the management group above it, so that the ceiling on standing power is a single subscription rather than the estate. Workload operators sit lower still, at the resource groups their workloads occupy. None of this is elaborate, and that is the point. The identity design is what converts the governance backbone from a diagram into something that actually decides what can happen, and it does so with a small number of assignments placed exactly where their blast radius is acceptable.
What remains is to build it, and building it is where the choices become concrete: two break-glass accounts hardened the modern way, the groups that carry every role, the assignments placed on the tree with a worked example, the one un-automatable elevation that bootstraps root scope, and Privileged Identity Management stood up if you licensed it or a disciplined standing model if you did not. The build sheet takes it from there, and it ends by proving the thing that makes all of this real: a role assigned once, high on the tree, showing up inherited at a subscription that was never touched.
Azure Landing Zones
‹ Previous: [LZ 4.2] Wiring Name Resolution End to End
Next: [LZ 5.1] Standing Up Identity and Access ›
