Five entities usually means five inconsistent tenants. We run them as one estate.
A UAE holding or group running multiple Microsoft 365 tenants almost always runs them to five different standards, with five sets of security gaps and no group-level view. As a Microsoft CSP managing client tenants under GDAP, we bring every entity onto one baseline, one monitoring pane, and one monthly report, using Microsoft 365 Lighthouse where tenants are eligible and the wider multi-tenant toolbox everywhere else.
- OneBaseline across entities
- GDAPLeast-privilege access
- 68+UAE tenants
- MonthlyGroup-level reporting
What actually goes wrong when a group runs tenants entity by entity.
Inconsistent security posture
One entity enforces MFA everywhere, another still has legacy authentication enabled. Conditional Access exists in two tenants, is half-built in a third, and is absent in the rest. Attackers do not respect org charts; they find the weakest tenant and use its trust relationships to reach the others.
- Different MFA and Conditional Access states per entity
- Defender and Intune deployed in some tenants, not others
- No shared definition of what "secure" means for the group
Duplicated and stranded licences
Each entity buys licences independently, often from a different reseller, at a different tier, on a different renewal date. Group staff who work across entities end up licensed twice. Leavers keep assigned seats for months because nobody owns the joiner-mover-leaver process at group level.
- 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 CFO cannot answer "what do we spend on Microsoft across all entities" without a spreadsheet exercise. Group IT cannot answer "are all our tenants patched and compliant" at all, because there is no single place where that answer lives.
- 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 sets of Global Administrators, some of them ex-employees, some of them the previous IT provider that nobody removed. Every stale admin account is a standing breach path into that entity, and through collaboration links, into the group.
- Former providers still holding admin roles
- Break-glass accounts that were never created or never tested
- No group register of who can administer what
Collaboration friction between entities
Staff in sibling companies work together daily but live in separate tenants, so every shared file is an external share, every joint Teams channel is a guest experience, and people search stops at the entity boundary. The group behaves like five strangers rather than one organisation.
- 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 with a DIFC-regulated entity, a mainland trading company, and a free-zone holding faces different regulatory expectations per entity, but the evidence gathering is duplicated five times because each tenant logs, retains, and reports differently.
- 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 the group gets when its tenants are run as one estate.
Tenant health across every entity
Service incidents, configuration drift, secure posture, and licence state for every tenant, watched from one console instead of five logins. Problems in a subsidiary surface to group IT the day they appear, not at the quarterly review.
One security baseline, pushed everywhere
MFA enforcement, Conditional Access, legacy authentication blocking, email authentication, device compliance, and data protection defined once as the group standard, then deployed and verified in every tenant, with per-entity exceptions documented rather than accidental.
Unified alerting and triage
Risky sign-ins, compromised-account indicators, and Defender alerts from all entities land in one triage queue, handled by the same engineers with the same runbooks. An attack pattern seen in one entity is checked across the rest the same day.
Per-entity reporting for group IT and the CFO
A monthly written report per entity plus a group rollup: security posture, incidents, licence utilisation, and changes made. Group IT gets the technical view; the CFO gets seats, spend direction, and risk in one page per company.
Joiner-mover-leaver across entities
One lifecycle process covering all tenants. A leaver from any entity is disabled and delicensed everywhere they had access, the same day. A mover between sibling companies is transferred, not recreated with a second licence.
Consistent device management
Intune enrolment, compliance policies, update rings, and app deployment standardised across entities, so a laptop in the free-zone subsidiary meets the same bar as one at the holding company, and lost-device response is the same everywhere.
Cross-entity collaboration that works
Multi-tenant organization, cross-tenant access policies, and cross-tenant sync configured so staff find and reach colleagues in sibling entities without guest friction, while each entity keeps control of what it trusts.
Admin access under GDAP, not standing Global Admin
Our access into each tenant is granular, time-bound, and auditable under GDAP. Stale provider accounts and shadow admins from the old arrangement are found and removed as part of onboarding, per entity.
One support path for every entity
Every subsidiary calls the same UAE service desk and reaches engineers who already know its tenant, its baseline, and its exceptions. No more five providers with five ticket systems and no shared context.
Four Microsoft mechanisms plus automation, each used for what it is actually for.
Microsoft 365 Lighthouse, used as it was designed
Lighthouse is built for managed service providers. It requires a partner relationship with GDAP delegated access into each customer tenant, and each tenant must meet Microsoft licensing eligibility requirements to be onboarded. It is not a product a holding company buys and points at its own subsidiaries. Because we are a Microsoft CSP managing client tenants, we can legitimately run your entities through Lighthouse: tenant health status, security baseline deployment progress, risky sign-in visibility, and device compliance rollups across every eligible tenant in one console.
- Requires an MSP with GDAP relationships, which is what we are
- Per-tenant licensing eligibility checked before onboarding
- Baseline deployment tracking, risky users, device compliance in one view
- It does not replace per-tenant admin centers for deep configuration
Multi-tenant organization (MTO) in Entra and Teams
MTO is the mechanism for groups that want their separate tenants to feel like one organisation. Member users are synchronised across tenants so people search, Teams chat, and meetings work across entity boundaries without the degraded guest experience. Entities keep their own tenants, their own admins, and their own data boundaries.
- Cross-tenant people search and improved Teams experience
- Users appear as members, not guests, in sibling tenants
- Each entity keeps its own tenant, admins, and compliance boundary
- It is a collaboration layer, not a management or security console
Cross-tenant access policies and cross-tenant sync
Cross-tenant access settings in Entra decide exactly which sibling tenants each entity trusts, and whether MFA and device compliance claims from a home tenant are accepted rather than re-prompted. Cross-tenant synchronization then automates the provisioning of users into sibling tenants so access appears and disappears with the HR lifecycle instead of by ticket.
- Explicit trust decisions per entity pair, not blanket openness
- MFA and compliant-device claims honoured across the group
- Automated B2B user provisioning and deprovisioning
- The plumbing underneath both MTO and day-to-day collaboration
Standardised baselines enforced by automation
For everything the consoles do not cover, we maintain the group baseline as configuration, applied and re-checked across tenants through Microsoft Graph and scripted deployment. When a tenant drifts, the drift is detected and reported, then corrected in a change window rather than discovered in an incident.
- One documented baseline: identity, email security, device, data
- Scripted deployment of the same policy set to every tenant
- Scheduled drift detection with a written monthly variance report
- Change control per entity, so local admins see what changed and why
Map the group complaint to the right tool before buying anything.
| Group problem | Right mechanism | What it will not do | |
|---|---|---|---|
| No single view of tenant health and security | Security posture, baseline drift, risky users invisible at group level | Microsoft 365 Lighthouse via our MSP relationship, plus our reporting layer | Deep per-tenant configuration; that stays in each admin center |
| Staff across entities collaborate as guests | Degraded Teams and search experience between sibling companies | Multi-tenant organization with cross-tenant sync | Merge mailboxes or files; data stays in each tenant |
| Every cross-entity login re-prompts for MFA | Users challenged repeatedly when moving between entity tenants | Cross-tenant access policies trusting home-tenant MFA claims | Create true single sign-on into one identity; users keep per-tenant accounts |
| Policies drift apart between entities | Same control configured five different ways across five tenants | Standardised baseline pushed and re-checked by automation | Stop a local Global Admin changing things; governance does that |
| The group has outgrown separate tenants entirely | Duplicate licences, duplicate admin effort, no appetite for federation | Tenant-to-tenant migration into one consolidated tenant | Happen quickly; consolidation is a project, not a setting |
Microsoft 365 Lighthouse is a partner tool, not a product your holding buys.
If a provider tells you your holding company can simply license Lighthouse and manage its own subsidiaries with it, be careful: Lighthouse is designed for managed service providers with delegated GDAP access to customer tenants, and tenants must meet Microsoft eligibility requirements to be onboarded. The legitimate routes for a group are either to engage an MSP like us, who manages your entities through Lighthouse and the wider toolbox, or to build group-level tooling directly on Entra features and Graph automation. We will tell you which of your entities are eligible, which are not, and what covers the gap, in writing, during discovery.
Four reasons UAE holdings hand us the whole estate.
A real MSP with a real CSP authorisation
Multi-tenant management through Lighthouse requires an MSP with GDAP relationships and CSP standing. We hold a direct Microsoft CSP authorisation with a verifiable AppSource listing, so the access model underneath your group is the one Microsoft designed, not a workaround.
68+ UAE tenants under management
We operate Microsoft 365 tenants for UAE businesses every day, including multi-entity groups with mainland, free-zone, and regulated entities side by side. Your structure will not be the first of its kind we have onboarded.
One engineer team across all your entities
The engineers who set your group baseline are the same ones answering each subsidiary's tickets from Business Bay, Dubai. Context stays in one team instead of being split across five providers who never speak.
Honest tooling advice, in writing
We document which entities are Lighthouse-eligible, where MTO fits, where plain cross-tenant policies are enough, and whether consolidation would serve you better. The recommendation comes with its reasoning, before any contract.
Six group structures where multi-tenant management pays off.
Family business groups
A trading arm, a real estate arm, a services arm, each with its own tenant and its own inherited IT. The family board wants one view of risk and spend without forcing the businesses into one mould.
Holdings with mainland and free-zone entities
A mainland LLC, a DMCC entity, and a DIFC-regulated firm under one ownership. Separate tenants are often the right compliance posture; what is missing is the common baseline and the group rollup, which is exactly what we add.
PE-backed roll-ups
A platform company acquiring bolt-ons, each arriving with its own tenant and its own gaps. Day-one security baseline per acquisition, group reporting for the fund, and a clean path to consolidation later if the thesis calls for it.
UAE arms of international groups
Regional entities whose headquarters runs its own tenant abroad. We manage the UAE tenants to the group standard, wire the cross-tenant trust to headquarters properly, and give both sides the reporting they need.
Groups with shared services
One finance or HR team serving every entity from a single office. Cross-tenant sync and access policies let shared-services staff work across all tenants cleanly instead of juggling five guest accounts.
Groups mid-restructure
Entities being acquired, divested, or merged over the next year or two. Multi-tenant management keeps every entity secure and reportable now, while keeping each one cleanly separable when 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 licence 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-licence, or acquisition-driven groups | Groups that are one business in all but history |
Sometimes the honest recommendation is one tenant, not five managed ones.
Multi-tenant management is the right answer when entities must stay legally, operationally, or contractually separate. But if your group holds one trade licence family, shares one management team, and keeps separate tenants only because history left them there, a tenant-to-tenant migration into a single consolidated tenant usually beats managing five forever: one licence pool, one admin team, native collaboration, and no federation layer to maintain. We run both engagements, so our recommendation is based on your structure, not on which service we happen to sell.
The licence disciplines that stop a group leaking seats across entities.
Visibility first
- One consolidated register of every seat in every tenantSKU, assignment, last activity, and owning entity, refreshed monthly, so the group sees its whole Microsoft position on one page.
- Cross-entity duplicate detectionStaff who appear in more than one tenant flagged, with a decision recorded: dual role, guest access instead, or remove one seat.
- Inactive seat flagging per entityLicensed accounts with no sign-in activity surfaced to each entity manager and the group, with a reclaim recommendation.
Right-sizing and lifecycle
- SKU tier matched to role, not to habitFrontline, knowledge worker, and executive profiles defined once at group level and applied consistently in every entity.
- Joiner-mover-leaver wired to licensingLeavers delicensed on exit in every tenant they touch; movers between entities have seats transferred, not duplicated.
- Group-based licence assignment wherever possibleLicences follow group membership rather than manual per-user assignment, so drift cannot quietly accumulate.
Procurement discipline
- Renewal dates aligned across entitiesAgreements brought onto a common cycle over time, so the group negotiates and reviews once, not five times a year.
- One CSP relationship across the groupEvery entity buying through one partner gives the group one invoice trail, one support path, and one accountable throat to choke.
- A written annual licence position for the CFOSeats, tiers, utilisation, and next-year recommendation per entity and for the group, delivered before renewal, not after.
From group discovery to steady-state operations in five steps.
- 1
Group discovery
1 week
Map the structure: entities, licences held, tenants, current providers, regulators per entity, and who administers what today. Output: a written map of the estate and a Lighthouse eligibility check per tenant.
- 2
Per-tenant baseline audit
1-2 weeks
Each tenant audited against the same checklist: identity, email security, device management, data protection, admin roles, and licence utilisation. Output: a gap report per entity and a group heatmap for the board.
- 3
Access model and GDAP
1 week
GDAP relationships established with each entity under least privilege, stale provider and shadow admin access removed, break-glass accounts created and tested. Eligible tenants onboarded into Lighthouse.
- 4
Baseline rollout, wave by wave
2-6 weeks
The group baseline deployed entity by entity: security policies first, then device management, then collaboration plumbing (cross-tenant access, sync, and MTO where agreed). Every change logged per entity.
- 5
Steady-state operations
Ongoing
One service desk for every entity, unified alert triage, monthly drift checks, licence hygiene, and the per-entity plus group-rollup report. Quarterly review with group IT on 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, synchronised 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
Microsoft CSP
Microsoft Cloud Solution Provider for UAE businesses
M365 Administration
Expert Microsoft 365 tenant management
M365 Licensing
Optimize your Microsoft 365 licensing costs
Cross-Tenant Access
Decide which partner tenants you actually trust
Microsoft Entra
Identity and access management solutions
Microsoft Partner UAE
Microsoft Partner serving UAE-wide businesses on M365, Azure, Copilot