One or several Microsoft 365 tenants: the criteria that should drive the decision
The question comes up with every acquisition, every new subsidiary and every sovereignty requirement: should you run a single Microsoft 365 tenant or several? The answer shapes security, collaboration and running costs for years. It deserves better than a default choice.
A tenant is a boundary, not just a container
A Microsoft 365 tenant is built on a single Entra ID directory. Everything inside it shares the same Global Administrators, the same default Conditional Access policies, the same application catalogue and the same audit log. It is the only real isolation boundary the platform offers: administrative units, groups and delegation policies organise administration, but they do not protect you from a compromised Global Administrator.
Conversely, two tenants are two separate worlds. Users from one are guests in the other; calendars, search, Teams and groups do not mix naturally, and every security setting has to be maintained twice. The choice is therefore a trade-off between isolation and simplicity.
Good reasons for a single tenant
In the vast majority of organisations we work with, a single tenant remains the sensible target. It provides:
- native collaboration: a global directory, free/busy, Teams, file sharing and search without any cross-tenant configuration;
- one security policy: one Conditional Access baseline, one authentication methods policy, one application governance model;
- one monitoring stack: one audit log, one Defender console, one source for the SIEM;
- fewer privileged administrators overall, and therefore a smaller attack surface.
Subsidiaries' need for autonomy is then handled through delegation: administrative units, custom roles, restricted management administrative units for sensitive accounts, and naming rules.
When several tenants are justified
Some situations require or justify separation:
- Foreseeable divestitures: an entity that is likely to be sold will be far easier to carve out if it already has its own tenant.
- Regulatory or contractual requirements: some activities demand strict isolation of administration or data, sometimes a specific cloud. A tenant's data location is set when it is created; Multi-Geo can distribute some data, but it does not provide administrative isolation.
- Administrative isolation: when it is unacceptable for a group-level Global Administrator to control an entity, only a separate tenant guarantees that separation.
- Recent mergers: during the transition two tenants inevitably coexist. The real question is whether, and how soon, they will be merged.
Avoid this. Creating an extra tenant "for a test" or for an impatient team often leaves orphaned environments with no security baseline and forgotten admin accounts. Every tenant that is created must be inventoried and governed like the main one.
Running several tenants side by side
When several tenants are kept, Entra ID offers a number of building blocks whose scope changes regularly; check the current state of features and licensing at the time of the project:
- Cross-tenant access settings: they define, organisation by organisation, which users may collaborate and whether you trust the partner tenant's MFA and device compliance claims.
- Cross-tenant synchronisation: it automatically provisions users from one tenant as B2B members in another, populating the directory and making access assignment easier.
- Multitenant organisation: it groups the tenants of one organisation to improve the experience in Teams and some Microsoft 365 apps.
- B2B direct connect: used in particular for Teams shared channels, without creating a guest object.
These tools reduce friction without removing it: some features remain limited across tenants, and every trust you grant a partner (MFA, compliant devices) extends your exposure to their level of security.
The real cost of each choice
The cost of a multi-tenant model is not just about licences. You have to account for duplicated policies and their upkeep, duplicated emergency and admin accounts, duplicated monitoring and SIEM integration, access reviews, and the time spent troubleshooting collaboration issues. Conversely, a single tenant demands fine-grained delegation and stricter governance discipline, because a configuration mistake affects everyone.
Finally, consolidating tenants is a heavy project: moving mailboxes, sites and Teams, reassigning licences, changing domains. It needs planning, usually with dedicated tooling, and cannot be improvised.
What an audit checks
- A complete inventory of the organisation's tenants, including those created outside IT.
- A documented justification for each separate tenant.
- A consistent security baseline across all tenants.
- Cross-tenant access settings and the trusts granted to partners.
- Delegated administration in the main tenant: administrative units, roles, protected accounts.