Do Multiple Microsoft 365 Tenancies Make Sense?

• In certain situations, multiple Microsoft 365 tenancies may be required or beneficial.
• Segmenting into multiple tenancies always results in additional costs and complexity.
• Organizations should carefully consider how and when multiple tenancies of Microsoft 365 will be deployed.

When customers provision Microsoft 365, they generally deploy a single tenancy for their entire organization. In each tenancy, all Microsoft 365 services and most other Microsoft hosted services that rely on it are rooted in a single instance of Entra ID that cannot easily interoperate with other instances of the service, other than by individual users or groups of users of tenancy A being invited to collaborate within tenancy B, etc. In a limited set of circumstances, the organization might decide strategically to deploy—or might be forced to deploy—multiple tenancies of Microsoft 365. Many of these scenarios do not exist on-premises due to the more extensive flexibility of Active Directory and on-premises software; others might have workarounds that are not possible with Microsoft-hosted services.

Why Multiple Tenancies?

A Microsoft 365 tenancy is an isolated instance of all Microsoft 365 services, including Office 365 services, services included in the Enterprise Mobility + Security (EMS) suite, and Microsoft Defender for Endpoint Plan 2. Access to the tenancy by users and external guests is controlled by an instance of Microsoft’s Entra ID.

Entra ID has limitations that do not exist with Active Directory (AD) on-premises, and since all Microsoft 365 services rely on Entra ID, they have many of the same limitations. For example, Entra ID does not support AD architectural constructs such as forests, domains, organization units (OUs), or any other mechanism to create interrelated hierarchical divisions inside the customer organization. Because of these and similar limitations within Microsoft’s hosted services, organizations have only two choices: a single global Entra ID instance and Microsoft 365 tenancy for their entire organization or multiple independent tenancies of Microsoft 365, each rooted off of its own instance of Entra ID. (There is no trust or federation model for Entra ID as AD offers on premises. This compromise simplifies deployment of Entra ID compared to AD; however, it also dramatically limits how larger businesses can interoperate with partners or other businesses through Entra ID.)

At least three (but potentially more) distinct scenarios may lead a customer organization to segment their Microsoft 365 hosted services into multiple tenancies:

• Architectural requirements
• License optimization
• Governmental compliance.

Architectural Requirements

An organization may arrive at the need to deploy multiple tenancies due to the business or regulatory variations in different regions where it operates. These include the following:

Management isolation, where different segments of the organization prefer to manage their own local users and services. For example, each of a conglomerate’s major business units might have its own IT organization that controls the resources and administrative rights for the unit. Azure customers can use management groups to partition management of entire groups of Azure resources to different parts of the organization, but Entra ID is not quite as flexible. 

Entra ID does offer administrative units, which allow the organization to subdivide management obligations of a predefined collection of users, groups, or devices along geographic, subsidiary, department, or other arbitrary organizational dividing lines. Administrative units enable some separation of management for users and groups without the complexity of setting up an entirely new Entra ID and Microsoft 365 tenancy, eliminating some significant management, collaboration, and licensing challenges.

(Maintaining separate production and development environments of Office 365 may require similar isolation, and a similar multiple-tenancy approach for organizations that continue to license Office 365 suites rather than Microsoft 365 suites.)

Data sovereignty, where geographically disparate parts of the organization need separate tenancies to ensure that all Microsoft 365 data at rest resides within the correct country or region. For example, European Union–based organizations might need to maintain data in that region to meet General Data Protection Regulation (GDPR) requirements. Although Microsoft’s Multi-Geo capabilities may help meet some of these requirements, it does not geographically isolate all Entra ID data or other Microsoft 365 service data (such as Office 365 metadata), just data belonging to individual users.

Information containment, where different parts of the organization should not be sharing information. This desire for intentional data-sharing limits could be due to potential conflicts of interest between divisions, the need to maintain data confidentiality needs, etc. Parts of the organization may be working with different partners/customers that need isolation or require the services to be isolated from a billing or accounting perspective. Information barriers can help deliver containment for Teams, SharePoint Online, Exchange Online, and OneDrive for Business, but like Multi-Geo, information barriers are limited in terms of how completely they can partition two parts of an organization. (Information barriers must be two-way; an organization cannot have division A trust division B but not the inverse.)

Merger and acquisition (M&A) planning, as organizations with considerable M&A activity may want to proactively design and deploy Microsoft 365 services to optimize for frequent churn. (An example is a healthcare organization or consortium that acquires or divests subsidiaries over time to meet market demands.) Microsoft offers no alternative other than multiple tenancies to help separate business divisions for divestiture or other accounting/cost partitioning needs.

Performance, while likely an infrequent reason for deploying multiple tenancies, could make sense as deploying Microsoft 365 services physically close to the users who require it can improve their user experience. (This can work because a tenancy can be established in Microsoft datacenter regions that are closer in proximity to the needs of the organization’s end users accessing it.) Multi-Geo may be able to help optimize performance for some, but not all, Microsoft hosted services.

License Optimization

Microsoft 365 services, including Office 365, are available in multiple licensing tiers (also commonly referred to as editions). Many features of these tiers offer tenancy-wide or organization-wide features, including most of the security and compliance services included in Microsoft 365 E5 suites, including (but by no means limited to) Microsoft Defender for Endpoint, Entra ID Protection, and Microsoft 365 E5 eDiscovery.

Due to Microsoft 365 licensing rules, customers who turn on tenancy-wide features must generally license all users in the tenancy for them, even if only a few users actually need the features. (The number of services that are enabled tenancy-wide is a poorly documented aspect of Microsoft 365 hosted services but are a key point of discussion in Directions Licensing Boot Camps.)

Some organizations may find it worthwhile to deploy a distinct tenancy of Microsoft 365 services for each user tier. For example, a customer might have one tenancy for users who need Microsoft 365 E5 tenancy-wide features and a separate tenancy for users who do not (those with Microsoft 365 E3, or more likely, F3/F1 “frontline” suites). This arrangement will allow the organization to reduce licensing costs and the risks of violating licensing rules, in exchange for significantly expanding deployment and management complexity.

However, large organizations in this situation might be able to solve the problem by (for example) negotiating amendments to licensing rules in their Enterprise Agreements (EAs) to permit mixing tiers in a single tenancy without running afoul of licensing requirements.

Governmental Compliance

Special levels of Microsoft 365 services are available for government customers in the United States to meet certain public-sector compliance requirements. These customers might need to use a mix of services that meet the highest compliance standards (Government Community Cloud [GCC] High and Department of Defense [DoD], generally designed to meet the needs of federal government entities) for part of their organization while also using less restrictive services (commercial and GCC) for other parts of their organization. To do this, organizations will need to establish GCC High and DoD tenancies of Microsoft 365 services and Entra ID that are separate from their commercial and GCC tenancies.

This is required both for the organization to ensure compliance requirements are met with the higher tier, and because users who do not need the GCC High/DoD-level services or cannot be licensed for them must be licensed for GCC or commercial tenancies of Microsoft 365 services.

Government customers outside of the United States looking to meet specific data sovereignty requirements may also want to deploy multiple tenancies of Microsoft 365 services to ensure regional data sovereignty across the entire instance of services.

Challenges with Multiple Tenancies

Several challenges occur as a result of having multiple concurrent tenancies across the organization. Challenges appear in the following four areas:

• Deployment
• Management
• Licensing
• Collaboration.

Deployment

Organizations are likely to run into their first challenges when deploying multiple tenancies as early as in the planning and piloting phases of Microsoft 365 deployment.

Since Microsoft 365 services are not designed to be fragmented and then managed as a cohesive group, each tenancy must be deployed, managed, and secured individually. No on-premises infrastructure required to work with Entra ID, nor Entra ID itself, is designed with multiple tenancies in mind. As a result, organizations will have to come up with solutions for dealing with Domain Name System (DNS), Entra ID synchronization, and Exchange global address list synchronization problems. At higher levels, organizations are likely to bump into issues with Azure multifactor authentication (MFA), and users who require credentials to access multiple tenancies, including administrators potentially responsible for accessing and managing multiple instances of Microsoft 365 as discussed next.

Management

After an organization has deployed multiple tenancies, a new level of oversight challenges will arise.

Like any other user of multiple tenancies, administrators will need all required credentials for every single tenancy they are expected to manage; this requirement is likely to frustrate administrators, lead to duplicated work (or missed work items), and require duplicate licensing for each tenancy, as discussed below.

If Microsoft 365 services are required within multiple tenancies, they will need to be deployed to each tenancy, and there is no mechanism for interoperation between tenancies, resulting in procedural overhead and operations that are likely to result in errors and potential security lapses and legal or regulatory compliance gaps.

An additional problem that will occur is due to the lack of a mechanism to move users between tenancies; their accounts must be completely re-created and destroyed in the destination/source directories, respectively. This highlights one more issue, which is retiring accounts when users leave the organization entirely; some mechanism or process will need to ensure that each of a user’s (or administrator’s) credentials have been removed or retired across all instances of Entra ID and Microsoft 365.

Licensing

As noted earlier, every user account (potentially including administrative accounts) within each Microsoft 365 tenancy requires its own User Subscription License (User SL). If users exist within multiple tenancies, they require multiple User SLs, one for each tenancy. Organizations that require this capability can sometimes negotiate with Microsoft so that the costs of maintaining multiple User SLs do not grow exponentially. However, these kinds of exceptions exist solely to address license purchasing within contracts and do not simplify or ease any of the management challenges that arise with needing to manage and deploy user licenses into multiple tenancies of Microsoft 365 for each user of both tenancies. 

Microsoft Entra External ID permits access to Microsoft 365 services like SharePoint Online by users external to the organization. However, external users in this context does not mean “external to this tenancy”; as in most volume licensing agreements, external means “external to the organization.” Consequently, Microsoft Entra External ID is typically not licensed for intra-organizational use. It might be possible to have Microsoft grant a contractual amendment permitting use of B2B-based services across multiple tenancies within the same organization, and this might even ease some of the pain points mentioned previously. However, this is not something designed into Microsoft technology or contracts as is.

Collaboration

Although Microsoft is actively working to improve certain aspects of multitenant access, having users from one tenancy work with users in another may be challenging or impossible, even within the same organization. These complexities will vary depending on the service that users require.

Something as simple as e-mail will be challenging, as the two tenancies cannot easily share a single Exchange global address list (GAL); some resources, shared accounts, and other items will exist in one GAL and not in the other. Similarly, SharePoint is not designed for sharing or searching between libraries that exist in multiple tenancies.

Teams supports B2B direct connect, and SharePoint Online and OneDrive for Business support B2B collaboration, but as noted earlier in this report, these capabilities are limited in the level of intra-tenant collaboration they can offer (by user or by group, not an entire cross-tenant trust) and are not intended to be used by users within the same organization (cross-tenant licensing within the same organization remains unclear and poorly documented).

Entra ID allows user credentials to be synchronized into additional Microsoft 365 tenancies, but there are limits to what this enables. For example, it does not federate licensing (so does not simplify any of the licensing challenges discussed previously) and creates additional licensing costs because synchronized users must be licensed as external users in all secondary tenancies of Microsoft 365.

Some users may also require additional stand-alone licensing beyond their Microsoft 365 suite for services like Entra ID Governance, even if they are licensed for that tier of Entra ID service within their own home tenancy of Entra ID.

Technical Considerations

Organizations planning a new Microsoft 365 deployment should first plan to deploy a single tenancy of services across the organization, unless one of the scenarios mentioned earlier is absolutely required.

Organizations that require multiple tenancies should engage with Microsoft early in the planning process to ensure limitations are understood and that any documented approaches that Microsoft recommends are followed, and Microsoft licensing rights and rules are understood and followed. Organizations should avoid building their own solutions to glue things together because they are not likely to age well as Microsoft 365 services are updated by Microsoft.

Organizations that are regularly subject to M&A activity (whether inbound acquisitions or outbound divestitures) should avoid trying to run multiple tenancies over the long term and instead build repeatable processes for onboarding external tenancies for acquisitions and offboarding existing users and groups into a new independent tenancy for divestitures.

As with the acquisition process, if an organization already has multiple Microsoft 365 tenancies and no longer needs them, they should establish processes for incorporating the users and services from the secondary tenancies into the primary destination tenancy to maximize employee productivity and minimize the process overhead for maintenance and oversight of additional tenancies. (There may also be third parties skilled at the practice of consolidating Microsoft 365 tenancies that can help with implementing these kinds of processes.)

Resources

Supported topologies for Entra ID Connect are documented at https://learn.microsoft.com/entra/identity/hybrid/connect/plan-connect-topologies (Microsoft).

Entra ID planning and administration are discussed in the Directions Kit “Entra ID Planning and Management” at https://www.directionsonmicrosoft.com/kits-collections/kit-entra-id-planning-and-management/.