Azure landing zones and multiple Microsoft Entra tenants

Azure landing zones are built on management groups. Azure policies are assigned and subscriptions are placed into management groups to provide the required governance controls that an organization needs to meet its security and compliance needs.

Tip

See Security control mapping with Azure landing zones to learn how to use Azure landing zone and Azure Policy to help achieve your organization's security, compliance, and regulatory needs.

These resources are deployed within a single Microsoft Entra tenant. Management groups and most other Azure resources, like Azure Policy, only support operating within a single Microsoft Entra tenant. An Azure subscription relies on a Microsoft Entra tenant to authenticate users, services, and devices against Azure Resource Manager (ARM) to control plane operations and some Azure services, like Azure Storage, for data plane operations.

Multiple subscriptions can rely on the same Microsoft Entra tenant. Each subscription can only rely on a single Microsoft Entra tenant. For more information, see Add an existing Azure subscription to your tenant.

Diagram of a single Microsoft Entra tenant with Azure landing zones deployed.

In the previous diagram, management groups, Azure Policies, and Azure subscriptions are deployed following the Azure landing zones conceptual architecture within a single Microsoft Entra tenant.

This approach is recommended for most organizations based on their requirements. This approach gives organizations the best collaboration experience possible and allows them to control, govern, and isolate users and resources within a single Microsoft Entra tenant.

Your organization might be required to use multiple Microsoft Entra tenants for many scenarios. See how to deploy and manage the Azure landing zone deployment into each of these tenants and considerations and recommendations for handling multiple Microsoft Entra tenants.

Note

This article focuses on Azure, not Microsoft 365 or other Microsoft Cloud offerings, such as Dynamics 365 or Power Platform.

It focuses on the platform rather than applications that are built on top of the platform in tenants. For information about multiple Microsoft Entra tenants and application architecture, see:

Why a single Microsoft Entra tenant is sufficient

There are reasons you might require multiple Microsoft Entra tenants, but it's important to understand why a single Microsoft Entra tenant is typically sufficient. It should be the default starting point for all organizations.

Use your existing corporate Microsoft Entra tenant for Azure subscriptions for the best productivity and collaboration experience across the platform.

Within a single tenant, development teams and application owners can have the least privileged roles to create non-production instances of Azure resources and trusted apps, test apps, test users and groups, and test policies for those objects. For more information about how to delegate administration with a single tenant, see Resource isolation in a single tenant.

Only create more Microsoft Entra tenants when there are requirements that can't be met by using the corporate Microsoft Entra tenant.

With Microsoft 365, the corporate Microsoft Entra tenant is generally the first tenant provisioned in the organization. This tenant is used for corporate application access and Microsoft 365 services. It supports the collaboration within an organization. The reason to start with this existing tenant is because it’s already been provisioned, managed, and secured. The defined lifecycle of the identities is likely already established. This course makes the task of onboarding new apps, resources, and subscriptions easier. It’s a mature, understood environment with established process, procedures, and controls.

Complexities with multiple Microsoft Entra tenants

When you create a new Microsoft Entra tenant, it requires extra work to provision, manage, secure, and govern the identities. You must also establish the required policies and procedures. Collaboration is best in a single Microsoft Entra tenant. Moving to a multi-tenant model creates a boundary, which can result in user friction, management overhead, and increase the attack surface area, which can cause a security risk and complicates product scenarios and limitations. Some examples include:

Organizations need to be clear about why they're deviating from the corporate Microsoft Entra tenant model to ensure the extra overhead and complexity is justified in meeting the requirements. There are examples of these instances in the scenarios article.

The Global Administrator (Global Admin) role is another concern. The Global Admin role provides the highest level of permissions available in a Microsoft Entra tenant. In Azure, any Global Admin can assume control of any Azure subscription linked to the Microsoft Entra tenant. For more information, see Elevate access to manage all Azure subscriptions and management groups.

Important

Microsoft Entra Privileged Identity Management should be used to help protect this role, and other privileged roles, within Microsoft Entra ID and Azure.

The ownership of this role across internal teams and departments can provide a challenge as the Identity team and the Azure team are often in different teams, departments, and organization structures.

The teams that operate Azure are responsible for Azure services and want to ensure the security of the services that they manage. When individuals outside of that team have roles with the power to potentially access their environments, the security is weaker. For more information, see Understand required cloud functions.

Microsoft Entra ID provides controls that help mitigate this problem on a technical level, but this issue is also a people and process discussion. For more information, see Recommendations.

Important

Multiple Microsoft Entra tenants are not the recommended approach for most customers. A single Microsoft Entra tenant, typically the corporate Microsoft Entra tenant, is recommended for most customers because it provides the necessary separation requirements.

For more information, see:

Next steps