Identity is the real control plane of the cloud. Networking gets the diagrams and firewalls get the budget, but the boundary an attacker actually probes is who can do what. In a landing zone, identity is a platform responsibility: set it up well once, and every workload inherits a secure default. Get it wrong, and you are handing out long-lived secrets and standing admin rights that no firewall can claw back.
The goal of an identity foundation is simple to state and hard to live up to: no standing privilege, no shared secrets, and every action attributable to a real identity.
The three pillars
For platform teams, identity foundations come down to three things: the tenant and directory design that everything sits in, workload identity (how services authenticate without secrets), and privileged access (how humans get admin rights, briefly and accountably).
flowchart TB T["Entra ID Tenant"] --> H["Human identities
(users & groups)"] T --> W["Workload identities
(apps & services)"] H --> CA["Conditional Access
(MFA · device · risk)"] H --> PIM["Privileged Identity Mgmt
(just-in-time roles)"] PIM --> R["Azure / Entra roles
(time-bound, approved)"] W --> MI["Managed identities"] MI --> RB["RBAC on resources"] W --> KV["Key Vault
(secrets, when unavoidable)"]
1. Tenant & directory design
Your Entra ID tenant is the root of trust for the whole estate. A few decisions here shape everything downstream:
- One production tenant, by default. Resist spinning up extra tenants for “separation” — management groups and subscriptions give you isolation within a single tenant. Multiple tenants mean multiple identity perimeters to secure and reconcile. Use a separate tenant only for a genuinely independent boundary (e.g. a regulated subsidiary).
- Groups, not direct assignments. Grant access to Entra security groups and assign roles to groups, never to individuals one by one. It keeps access reviewable and reversible.
- Emergency access (“break-glass”) accounts. Create two cloud-only global admin accounts excluded from Conditional Access, with long stored credentials, monitored for any sign-in. They are your way back in if MFA or federation breaks.
Anti-pattern: a sprawl of tenants created “to keep things separate.” Each one multiplies your Conditional Access policies, break-glass accounts, and audit surface — and cross-tenant access is far clumsier than a clean subscription model in one tenant.
2. Workload identity: managed identities over secrets
The fastest way to leak a credential is to have one. Every secret you issue is a string that can be copied into a notebook, a pipeline log, or a chat message. Managed identities remove the secret entirely: Azure issues and rotates the credential for you, and the workload simply asks for a token.
- Prefer user-assigned managed identities for anything shared across resources or that should outlive a single resource — they’re reusable and easier to grant RBAC to ahead of time.
- Use system-assigned for one-to-one, lifecycle-bound cases where the identity should die with the resource.
- For workloads outside Azure (GitHub Actions, AKS, other clouds), use workload identity federation so external tokens are exchanged for Entra tokens — no stored secret at all.
- When a secret is truly unavoidable, put it in Key Vault behind a Private Endpoint and access that with a managed identity. Never in app settings or config files.
Tip: make “no secrets in code” an enforceable policy, not a guideline. Azure Policy can flag resources without managed identities, and secret scanning in your pipeline catches the rest before they merge.
3. Privileged access: PIM and just-in-time admin
Standing admin rights are the single juiciest target in your tenant. Privileged Identity Management (PIM) turns permanent role assignments into eligible ones: an admin activates the role only when needed, for a limited window, with justification — and optionally approval and MFA at activation.
- Make privileged roles eligible, not active. Global Administrator, Owner, User Access Administrator, and platform roles should all require activation.
- Time-box and approve. Short activation windows, with approval for the most sensitive roles, so elevation is deliberate and logged.
- Review regularly. Access reviews on privileged groups remove the access people accumulated for a project two quarters ago and never gave back.
- Pair with Conditional Access. Require MFA and compliant devices for activation, and block legacy authentication everywhere.
How it lands on the platform
None of this belongs to individual app teams. The platform defines the tenant, the Conditional Access baseline, the break-glass accounts, the PIM configuration, and the managed-identity pattern — and workloads inherit it. An app team’s job is simply to use a managed identity and request the RBAC they need; they never handle a secret or hold standing admin. That division is exactly what a landing zone exists to create.
Key takeaways
- Treat identity as the real control plane — design it first, not last.
- Default to one tenant; isolate with subscriptions and groups, not extra directories.
- Use managed identities (and federation) so workloads never hold secrets.
- Eliminate standing admin with PIM: eligible, time-boxed, approved, reviewed.
- Keep break-glass accounts and a Conditional Access baseline owned by the platform.
This is the identity layer of the foundation introduced in Azure Landing Zones: A Practical Architect’s View, and it pairs directly with the private-by-default networking in Hub-and-Spoke vs Azure Virtual WAN.