Five companies in a group almost always means five tenants configured five different ways. We run them as a single estate.
An American holding company, a private equity platform or any group of several legal entities running more than one tenant will be running them to as many different standards as it has tenants, with a matching number of security gaps and no view across any of it. Working under delegated administration, we bring every entity onto one baseline, one place to watch them, and one monthly report, using Lighthouse wherever tenants qualify and the wider multi-tenant toolbox everywhere they do not.
- OneBaseline across entities
- GDAPLeast-privilege access
- One paneEstate-wide visibility
- MonthlyGroup-level reporting
What genuinely goes wrong when a group leaves each entity to run its own tenant.
Inconsistent security posture
One entity enforces multifactor across the board while another still has the legacy protocols wide open. Conditional Access exists properly in two tenants, half exists in a third, and is entirely absent from the rest. Nobody attacking you cares about the org chart. They find the weakest tenant and use whatever trust relationships it has to reach the others.
- Different MFA and Conditional Access states per entity
- Defender and Intune deployed in some tenants, not others
- Nobody has ever agreed what secure means across the group
Duplicated and stranded licenses
Each entity buys its own licensing, usually from a different reseller, at a different tier, renewing on a different date. Anybody working across two entities ends up licensed twice over. People who left months ago keep their seats because nobody at group level owns the process for joiners, movers and leavers.
- The same person licensed in two or three tenants
- Mixed SKU tiers with no group rationale
- Renewal dates scattered across the year
No group-level visibility
The group finance director cannot say what the whole business spends on Microsoft without somebody spending a week building a spreadsheet. Group IT cannot say whether every tenant is patched and compliant at all, because no single place exists where that answer could live.
- No consolidated view of spend, seats, or security state
- Incidents in one entity invisible to the group
- Board questions answered by email survey, not by data
Admin sprawl and shadow admins
Five tenants means five separate sets of Global Administrators. Some belong to people who left. Some belong to the IT provider before last, whom nobody ever removed. Every one of those stale accounts is a standing route into that entity, and through the collaboration links, into the whole group.
- Former providers still holding admin roles
- Emergency accounts that either never existed or have never been tested
- No group register of who can administer what
Collaboration friction between entities
People in sister companies work together every day while living in separate tenants, so every file they share is an external share, every shared channel is a guest arrangement, and searching for a colleague stops dead at the entity boundary. The group behaves like five unrelated firms who happen to share a shareholder.
- Guest access as the default internal experience
- Shared mailboxes and calendars that cannot span entities
- Group announcements sent five times to five tenants
Audit and compliance fatigue
A group containing one entity covered by HIPAA, one subsidiary holding defense contracts and one ordinary commercial business faces genuinely different regulatory expectations in each, and yet the evidence gathering happens five separate times over, because every tenant logs, retains and reports differently from every other.
- Five audit log configurations, five retention states
- Evidence requests answered tenant by tenant, by hand
- No standard control set mapped across the group
Nine things a group gains once its tenants are genuinely run as one estate.
Tenant health across every entity
Service incidents, drift away from the configuration, the posture and the licensing position for every tenant, all watched from one console rather than five separate logins. A problem in a subsidiary reaches group IT on the day it appears rather than at the quarterly meeting.
One security baseline, pushed everywhere
Multifactor enforced, Conditional Access configured, the legacy protocols closed, mail authentication set up, device compliance and data protection in place, all defined once as the group standard and then deployed and verified in every tenant. Where an entity needs an exception, it is documented rather than arrived at by accident.
Unified alerting and triage
Risky sign-ins, indications of a compromised account and Defender alerts from every entity land in a single triage queue, worked by the same engineers using the same runbooks. A pattern seen in one entity gets checked against all the others the same day rather than the following quarter.
Per-entity reporting for group IT and the CFO
A written report each month for every entity, plus one rolled up for the group. Posture, incidents, how much of the licensing is used, and what changed. Group IT gets the technical version. Whoever runs finance gets seats, the direction of spend, and risk, on a single page per company.
Joiner-mover-leaver across entities
One lifecycle process spanning every tenant. Somebody leaving any entity is disabled and delicensed everywhere they held access, that same day. Somebody moving between sister companies is transferred across rather than recreated with a second license attached.
Consistent device management
Device enrollment, the compliance policies, the update rings and application deployment all standardized across entities, so a laptop at the company you bought last month meets the same bar as one at head office, and losing a device is handled identically wherever it happens.
Cross-entity collaboration that works
The multi-tenant organization arrangement, the cross-tenant access policies and the synchronization between tenants all configured so that people find and reach colleagues in sister companies without the guest experience getting in the way, while each entity retains control over exactly what it trusts.
Admin access under GDAP, not standing Global Admin
Our own access into each tenant is narrow, expires, and is fully auditable under the delegated model. The stale provider accounts and forgotten administrators left over from whatever came before get found and removed during onboarding, entity by entity.
One support path for every entity
Every subsidiary reaches the same service desk and the same engineers, who already know that tenant, its baseline and every exception on it. No more five providers running five ticket systems with nothing shared between any of them.
Four Microsoft mechanisms plus automation, each used for what it was genuinely designed to do.
Microsoft 365 Lighthouse, used as it was designed
Lighthouse was built for service providers rather than for the companies they serve. It needs a partner relationship with delegated access into each tenant, and every tenant has to meet the licensing eligibility rules before it can be onboarded at all. It is not something a holding company buys and aims at its own subsidiaries. Because we operate as a service provider managing client tenants, your entities can legitimately run through it: tenant health, how far the security baseline has deployed, visibility of risky sign-ins, and device compliance rolled up across every eligible tenant in one console.
- Needs a service provider holding delegated relationships, which is exactly what we are
- Per-tenant licensing eligibility checked before onboarding
- Baseline progress, risky accounts and device compliance, all in a single view
- It does not replace each tenant own admin center for anything configured in depth
Multi-tenant organization (MTO) in Entra and Teams
This is the mechanism for a group wanting its separate tenants to feel like one company. People get synchronized across the tenants so that searching for a colleague, chatting to them and meeting them all work across entity boundaries without the degraded guest experience everybody hates. Each entity keeps its own tenant, its own administrators and its own data boundary.
- Cross-tenant people search and improved Teams experience
- Users appear as members, not guests, in sibling tenants
- Every entity retains its own tenant, its own administrators and its own compliance boundary
- This is a collaboration layer and not a management or security console
Cross-tenant access policies and cross-tenant sync
The cross-tenant access settings decide precisely which sister tenants each entity trusts, and whether a multifactor or device compliance claim from somebody home tenant is accepted rather than demanded again. Cross-tenant synchronization then automates provisioning people into those sister tenants, so access appears and disappears alongside the HR record rather than by somebody raising a ticket.
- Explicit trust decisions per entity pair, not blanket openness
- MFA and compliant-device claims honored across the group
- Automated B2B user provisioning and deprovisioning
- The plumbing sitting underneath both the collaboration layer and ordinary daily working
Standardized baselines enforced by automation
For everything no console covers, the group baseline is maintained as configuration, applied and then re-checked across every tenant through Graph and scripted deployment. When a tenant drifts away from it, that drift gets detected and reported, and corrected inside a change window rather than discovered halfway through an incident.
- One documented baseline: identity, email security, device, data
- The same policy set deployed by script to every tenant, identically
- Scheduled drift detection with a written monthly variance report
- Change control per entity, so the local administrators can see what changed and the reason for it
Match whatever the group is complaining about to the right mechanism before buying a thing.
No single view of tenant health and security
- Group problem
- Posture, drift from the baseline, and risky accounts, none of it visible at group level
- Right mechanism
- Lighthouse through our service provider relationship, with our own reporting on top
- What it will not do
- Anything configured in depth per tenant, which stays in that tenant own admin center
Staff across entities collaborate as guests
- Group problem
- Degraded Teams and search experience between sibling companies
- Right mechanism
- Multi-tenant organization with cross-tenant sync
- What it will not do
- Merge mailboxes or files; data stays in each tenant
Every cross-entity login re-prompts for MFA
- Group problem
- Users challenged repeatedly when moving between entity tenants
- Right mechanism
- Cross-tenant access policies trusting home-tenant MFA claims
- What it will not do
- Produce genuine single sign-on onto one identity, since people keep an account per tenant
Policies drift apart between entities
- Group problem
- Same control configured five different ways across five tenants
- Right mechanism
- Standardized baseline pushed and re-checked by automation
- What it will not do
- Prevent a local Global Administrator changing something, which is a governance problem rather than a tooling one
The group has outgrown separate tenants entirely
- Group problem
- Duplicate licenses, duplicate admin effort, no appetite for federation
- Right mechanism
- Tenant-to-tenant migration into one consolidated tenant
- What it will not do
- Happen quickly; consolidation is a project, not a setting
Lighthouse is a tool for partners, not something your holding company can go and buy.
If somebody tells you your holding company can simply license Lighthouse and manage its own subsidiaries through it, treat that carefully. It is built for service providers holding delegated access into customer tenants, and every tenant must satisfy the eligibility rules before it can be onboarded. Two legitimate routes exist for a group. Either engage a provider who manages your entities through it alongside the wider toolbox, or build your own group-level tooling directly on the Entra capabilities and Graph automation. Which of your entities qualify, which do not, and what covers the difference all get set out in writing during discovery.
Four reasons multi-entity groups hand us the whole estate.
A real MSP with the access model Microsoft designed
Multi-tenant management through Lighthouse requires an MSP with GDAP relationships and partner standing. We manage client tenants under exactly that model, so the access underneath your group is the one Microsoft designed for this work, not a workaround built on shared admin passwords.
Multi-entity structures are familiar ground
We operate Microsoft 365 tenants for multi-entity businesses with regulated and unregulated companies side by side: HIPAA-covered entities next to ordinary commercial ones, acquisition-heavy platforms mid-integration. Your structure gets mapped, not improvised around.
One engineer team across all your entities
Whoever set the group baseline is also whoever answers the tickets from each subsidiary. The context stays inside one team rather than being distributed across five providers who have never spoken to each other.
Honest tooling advice, in writing
Which entities qualify for Lighthouse, where the multi-tenant organization arrangement fits, where plain cross-tenant policy is entirely sufficient, and whether consolidating outright would serve you better, all get documented. The recommendation arrives with its reasoning attached, before anybody signs anything.
Six group structures where multi-tenant management pays off.
Family offices and family business groups
An operating business, a property arm and an investment entity, each carrying its own tenant and whatever IT it inherited. The family board wants a single view of risk and spend without forcing three genuinely different businesses into one mold.
Groups mixing regulated and unregulated entities
A medical practice covered by HIPAA, a subsidiary holding defense contracts, and an ordinary commercial business, all under one owner. Keeping the tenants separate is very often the correct compliance position. What is missing is the shared baseline and the view across the group, and that is precisely what gets added.
PE-backed roll-ups
A platform business acquiring smaller companies, each arriving with a tenant of its own and a fresh set of gaps. A security baseline applied on the first day of each acquisition, reporting the fund can read, and a clean route to consolidating later if the investment thesis calls for it.
US arms of international groups
American entities whose parent company runs its own tenant somewhere else entirely. We manage the American tenants to the group standard, wire the trust relationship back to head office properly rather than approximately, and give both sides the reporting each of them actually needs.
Groups with shared services
A single finance or HR team serving every entity from one office. Synchronization between tenants and the access policies let shared services staff work across all of them cleanly rather than juggling five separate guest accounts and five sets of credentials.
Groups mid-restructure
Entities due to be bought, sold or merged over the next year or two. Managing them this way keeps every one secure and reportable today while leaving each cleanly separable on the day the structure changes.
Multi-tenant management versus merging into one tenant.
| Feature | Multi-tenant management | Consolidate into one tenant |
|---|---|---|
Entity independence preserved | ||
Separate compliance and data boundaries per entity | ||
Time to value | Weeks | Months, as a migration project |
Ongoing federation layer to maintain | Yes | No |
Single license pool and one admin surface | ||
Native collaboration, no cross-tenant plumbing | ||
Easy divestment of one entity later | Requires carve-out migration | |
Best for | Regulated, multi-license, or acquisition-driven groups | Groups that are one business in all but history |
Occasionally the honest answer is one tenant rather than five managed well.
Managing several tenants is the right answer where the entities genuinely have to stay separate, whether legally, operationally or under a contract. But where a group shares one management team and one workforce, and keeps separate tenants purely because a decade of acquisitions left them lying around, consolidating into a single tenant usually beats managing five of them indefinitely. One pool of licenses, one administrative team, collaboration that works natively, and no federation layer to keep alive. We deliver both engagements, so the recommendation follows your structure rather than whichever service we would rather sell.
The license disciplines that stop a group leaking seats across entities.
Visibility first
- One consolidated register of every seat in every tenantEvery product, who it is assigned to, when they last did anything, and which entity owns it, refreshed monthly, so the group sees its entire Microsoft position on a single page.
- Cross-entity duplicate detectionAnybody appearing in more than one tenant gets flagged, and a decision recorded against them: they genuinely hold two roles, they should be a guest instead, or one of the seats comes back.
- Inactive seat flagging per entityLicensed accounts nobody has signed into get surfaced to the manager of that entity and to the group together, with a recommendation to reclaim.
Right-sizing and lifecycle
- SKU tier matched to role, not to habitProfiles for frontline staff, for people who live in these tools all day, and for executives, defined once at group level and applied identically everywhere.
- Joiner-mover-leaver wired to licensingAnybody leaving loses their licensing in every tenant they ever touched, and anybody moving between entities has their seat transferred rather than a second one bought.
- Group-based license assignment wherever possibleLicensing follows group membership instead of somebody assigning it person by person, so drift has nowhere to accumulate quietly.
Procurement discipline
- Renewal dates aligned across entitiesOver time the agreements get brought onto one cycle, so the group negotiates and reviews annually instead of five times scattered through the year.
- One partner relationship across the groupWith every entity buying through one partner, the group gets a single invoice trail, a single support path and one person accountable for both.
- A written annual license position for the CFOSeats, tiers, how much is genuinely used, and a recommendation for next year, given per entity and for the group as a whole, delivered before the renewal rather than after it.
From the first look at the group to steady running, in five steps.
- 1
Group discovery
1 week
Mapping the structure. Which entities exist, what licensing each holds, how many tenants, which providers are involved, which regulator applies where, and who administers what as things stand. What comes out is a written map of the estate and an eligibility check per tenant.
- 2
Per-tenant baseline audit
1-2 weeks
Every tenant audited against one identical checklist covering identity, email security, device management, data protection, administrative roles and how much of the licensing is used. What comes out is a gap report for each entity and a single heatmap the board can read.
- 3
Access model and GDAP
1 week
Delegated relationships established with each entity at the minimum privilege that works, stale provider accounts and forgotten administrators removed, and emergency accounts created and actually tested. Whichever tenants qualify get onboarded into Lighthouse.
- 4
Baseline rollout, wave by wave
2-6 weeks
The group baseline deployed one entity at a time. Security policies first, then device management, then the collaboration plumbing, meaning cross-tenant access, synchronization and the multi-tenant organization arrangement wherever that has been agreed. Every change logged against the entity it touched.
- 5
Steady-state operations
Ongoing
One service desk covering every entity, a single triage queue for alerts, drift checked monthly, licensing kept tidy, and the reporting produced both per entity and rolled up. Then a quarterly conversation with group IT about what to tighten next.
What group boards and entity managers ask before signing.
The rest of the multi-tenant cluster.
Microsoft 365 Tenant Management
What day-to-day tenant operations cover for a single tenant, the layer we run per entity underneath the group view.
Tenant to Tenant Migration
When consolidating entities into one tenant beats managing several, and how a migration actually runs.
Cross-Tenant Sync & Collaboration
The Entra plumbing between sibling tenants: trust settings, synchronized users, and the collaboration experience they unlock.
Book a group discovery and get the estate map your board has never seen.
Tell us your entities and we will map the tenants, check Lighthouse eligibility per company, audit each one against a single baseline, and hand you a written picture of where the group stands. If consolidation would serve you better than management, we will say so.
Related Services
Explore more solutions that work great with this service
M365 Tenant Management
Your tenant run properly, end to end
Learn moreTenant to Tenant Migration
M&A and rebrand moves without losing a day
Learn moreCross-Tenant Sync
Multi-tenant orgs collaborating safely
Learn moreMicrosoft Entra
Identity and access management solutions
Learn moreM365 Administration
Expert Microsoft 365 tenant management
Learn more