Securing identity and access for Azure landing zones
Microsoft Entra outlines a set of design principles and practical steps to secure identity and access for Azure landing zones, covering governance, RBAC, MFA, PIM, and automation.
When an organisation moves workloads to Azure, the way it controls who can do what becomes a critical part of keeping the business running. Microsoft Entra has published a set of design principles and practical steps that help platform and application teams build a secure identity foundation for landing zones.
Design foundations
Subscription democratisation and policy‑driven governance, By allowing workload teams to own their own subscriptions while the platform team enforces guardrails, you get both agility and control. This model lets teams manage resources without constantly asking a central gatekeeper, yet policies keep the environment compliant.
Who does what, The platform team creates the landing zone and applies the baseline access controls. Once the zone is live, the application owner takes responsibility for managing users, groups and role assignments in Microsoft Entra ID. This split of duties keeps the ownership chain clear and reduces bottlenecks.
Control mechanisms
| Guideline | Why it matters |
|---|---|
| Use Azure role‑based access control (RBAC) for fine‑grained administrative access | RBAC lets you give just the permissions needed for a specific task, limiting the blast radius of a compromised account. |
| Create custom RBAC roles only when built‑in roles do not meet the principle of least privilege | Built‑in roles cover most scenarios; custom roles should be a last resort to avoid unnecessary complexity. |
| Deploy Microsoft Entra Privileged Identity Management (PIM) for just‑in‑time privileged access | PIM ensures that elevated rights are granted only for the time they are required, reducing exposure. |
| Separate administrative access from day‑to‑day activities such as web browsing and email | Admin accounts are high‑value targets; keeping them away from common attack vectors lowers risk. |
| Enforce multi‑factor authentication (MFA), including phishing‑resistant methods, for all accounts with Azure rights | MFA adds a second layer of proof that the user is genuine, and phishing‑resistant options protect against credential‑theft attacks. |
| Apply Conditional Access policies to privileged accounts based on risk profile | Conditional Access can require compliant devices or additional checks when risk signals rise, tightening security for high‑value users. |
| Enable Microsoft Defender for Identity to monitor and protect user identities | Defender for Identity watches for suspicious sign‑in behaviour and credential‑dumping techniques, alerting you early. |
| Create emergency‑access (break‑glass) accounts and secure them with strict controls | Break‑glass accounts provide a safety net for disaster recovery without locking out administrators. |
| Use subscription‑vending automation to standardise landing‑zone creation and identity configuration | Automation ensures every new zone starts with the same security baseline, eliminating manual drift. |
| Leverage administrative units to delegate scoped administration within the tenant | Administrative units let you give a group of admins authority over a defined set of objects, keeping the broader tenant safe. |
| Assign roles to security groups rather than directly to users | Group‑based assignments reduce the number of role entries and stay within Azure RBAC limits. |
Photo by Ivan S on Pexels
Security hardening
- MFA enforcement, Require MFA for any user who can manage resources. Prefer the phishing‑resistant option that uses a hardware token or the Microsoft Authenticator app’s push notification.
- Conditional Access, Build a policy that blocks sign‑ins from risky locations unless the device meets compliance standards.
- Defender for Identity, Deploy the sensor on domain controllers or enable the cloud‑only version to gain visibility into credential‑theft attempts.
- Break‑glass accounts, Store the credentials in a sealed vault, enable MFA, and audit every use.
Operational safeguards
- Subscription‑vending pipelines, Integrate Azure Resource Manager templates or Bicep files that automatically apply the RBAC and PIM settings when a new subscription is spun up.
- Administrative units, Map each business unit to an administrative unit so that its IT staff can only manage the objects belonging to that unit.
- Group‑centric role assignments, Create security groups for each functional role (e.g., "Finance‑App‑Admins") and attach the appropriate Azure role to the group.
Implementation checklist
- Align the landing‑zone design with subscription democratisation and policy‑driven governance.
- Let the platform team provision the zone and set baseline RBAC.
- Hand over user and group management to the application owner in Microsoft Entra ID.
- Apply Azure RBAC for all admin tasks; add custom roles only if needed.
- Enable Entra PIM for any privileged role and configure just‑in‑time activation.
- Enforce MFA with phishing‑resistant methods for all privileged accounts.
- Deploy Conditional Access policies that consider risk signals for admin users.
- Turn on Microsoft Defender for Identity and integrate alerts with your SIEM.
- Create and protect break‑glass accounts, documenting their purpose and access controls.
- Automate subscription creation and identity configuration through a vending service.
- Set up administrative units to delegate scoped tenant administration.
- Assign Azure roles to security groups, not individual users, to stay within limits.
Photo by Kampus Production on Pexels
Terms used in this article
- Azure role‑based access control (RBAC), A permission model that assigns roles to users, groups or services to control what actions they can take on Azure resources.
- Microsoft Entra Privileged Identity Management (PIM), A service that provides just‑in‑time access to privileged roles and requires approval or MFA before activation.
- Multi‑factor authentication (MFA), An authentication method that requires two or more verification factors, such as a password plus a phone prompt.
- Phishing‑resistant MFA, An MFA method that cannot be tricked by a fake login page, typically using a hardware token or the Microsoft Authenticator app.
- Conditional Access, Policies that enforce additional requirements (device compliance, location, risk) before granting access.
- Microsoft Defender for Identity, A cloud‑based security solution that analyses identity‑related signals to detect attacks.
- Break‑glass account, An emergency‑access account that is kept offline or highly protected, used only when normal admin access is unavailable.
- Subscription‑vending automation, A scripted process that creates new Azure subscriptions and applies predefined configurations.
- Administrative unit, A container in Microsoft Entra that limits the scope of delegated administrators to a subset of objects.
By following these guidelines, organisations can build landing zones that are both flexible for development teams and hardened against credential‑based attacks, keeping the Azure environment reliable and secure.
