Tenants and domains
Tenant IDs, verified and accepted domains, cloud environments, subscriptions, licensing, identity sources, administrative ownership, and known shadow or test tenants.
Planning guide · Merger and acquisition integration
Microsoft 365 security assessment after a merger or acquisition
Before standardizing policies or moving data, establish which tenants, identities, applications, devices, trust relationships, and collaboration paths now belong to the combined risk picture.
Do not confuse access with integration
The first security decision is the operating model—not a forced tenant consolidation.
Microsoft identifies mergers and acquisitions as a common reason organizations manage more than one Microsoft Entra tenant. Its multitenant organization guidance describes capabilities for collaboration and lifecycle management across those boundaries.
The combined organization may temporarily operate separate tenants, enable limited cross-tenant collaboration, migrate selected workloads, or work toward consolidation. Security assessment should make the current state and intended transition explicit before broad access or policy changes create hidden dependencies.
Transaction boundary: this guide is security-planning information, not legal, financial, tax, privacy, regulatory, or deal advice. Pre-close access and evidence collection must follow the transaction's authorization, confidentiality, data-handling, and clean-team requirements.
Current-state inventory
Map both control planes before deciding which standard wins.
Inventory the acquired and acquiring environments separately, then document the approved connections between them. “Same company” does not make two tenant configurations equivalent.
Users and privilege
Workforce populations, guests, external identities, Global Administrators, other privileged roles, emergency access, service accounts, workload identities, dormant users, and joiner-mover-leaver ownership.
Cross-tenant access
Inbound and outbound settings, B2B collaboration, B2B direct connect, synchronization scope, trust of MFA or device claims, default settings, tenant restrictions, and organizational exceptions.
Applications and consent
Enterprise applications, app registrations, delegated and application permissions, service principals, credentials, publishers, owners, provisioning, third-party dependencies, and unused access.
Devices and endpoints
Intune authority, enrollment and compliance coverage, device ownership, platform restrictions, app protection, encryption signals, local administration, Defender integration, stale records, and transition plans.
Email and collaboration
Exchange routing and forwarding, accepted domains, anti-phishing controls, Teams federation and shared channels, SharePoint and OneDrive sharing, guests, anonymous links, site ownership, and data-migration boundaries.
Conditional Access
Policy intent, target populations, exclusions, application coverage, authentication strength, device dependencies, locations, risk conditions, session controls, report-only policies, and emergency access.
Monitoring and response
Audit availability, log retention and export, alert routing, Defender products, investigation ownership, incident contacts, legal holds, evidence preservation, and cross-tenant response authority.
Recovery and change
Administrative recovery, independent communications, migration rollback, coexistence dependencies, backups and restoration where separately validated, exception ownership, and approval for high-impact changes.
Integration risk register
Look for security debt created by the connection—not only inherited settings.
- Broad cross-tenant defaults or trust settings are enabled before required users, groups, applications, MFA claims, and device claims are understood.
- Duplicated or synchronized identities accumulate access in both tenants without a clear lifecycle owner or reliable offboarding path.
- Inherited privileged roles, emergency accounts, automation identities, application credentials, and consent grants remain outside the combined governance process.
- Guests, shared channels, sites, links, mail routing, forwarding, and third-party applications preserve access paths that are absent from the migration plan.
- Conditional Access policies use different assumptions about managed devices, authentication methods, locations, exclusions, and supported applications.
- Endpoint migration creates intervals where devices are duplicated, stale, unenrolled, incorrectly owned, or unable to satisfy the intended access policy.
- Logs and alerts remain tenant-specific, while incident ownership assumes a combined view that the security team does not yet have.
- A source tenant, connector, domain, application, account, or credential is retired before its business and recovery dependencies are proven absent.
Microsoft's cross-tenant access documentation explains that inbound, outbound, and trust settings control different parts of collaboration. It also advises reviewing current sign-in behavior and consulting business stakeholders before blocking access that may be required.
Phased decisions
Stabilize, design, then standardize.
The windows below are planning concepts, not a promised timeline. Deal constraints, tenant size, evidence access, risk, and migration complexity determine the real sequence.
Establish control and visibility
Name tenant and incident owners. Preserve logs and material evidence. Inventory privileged and emergency access, critical applications, domains, collaboration paths, high-risk exceptions, and changes required for day-one operations.
Exit test: accountable owners can explain who administers each tenant, how urgent access is granted and removed, and where material alerts go.
Choose the coexistence model
Map required applications and collaboration, select cross-tenant scopes, define trust decisions, design identity lifecycle, compare Conditional Access and device assumptions, and identify workload-specific migration dependencies.
Exit test: every new trust or synchronization path has a business purpose, bounded population, technical owner, review date, and rollback approach.
Remediate and validate
Pilot policy changes, reduce stale access, align privileged controls, govern applications, transition devices and data through separate plans, exercise response, retest findings, and retire source components only after dependency validation.
Exit test: intended controls operate across the approved topology, residual exceptions are owned, and decommissioning evidence is retained.
Architecture choice: Microsoft documents hub-and-spoke, mesh, and just-in-time collaboration patterns. The existence of a Microsoft feature does not make it appropriate for every acquisition; licensing, governance, application behavior, and business requirements still need validation.
Decision-ready deliverables
A post-acquisition assessment should reduce integration uncertainty.
- A tenant and trust-boundary map naming identity sources, administrators, domains, collaboration paths, device authority, applications, and evidence limitations.
- A technical findings register separating inherited gaps, integration-created gaps, unavailable evidence, accepted exceptions, and items outside Microsoft 365.
- A prioritized action plan with immediate containment, safe coexistence, policy alignment, migration dependencies, accountable owners, and validation evidence.
- A decision log for cross-tenant trust, identity lifecycle, privileged access, application consent, external collaboration, monitoring, recovery, and decommissioning.
- A stakeholder readout where business, security, identity, endpoint, collaboration, migration, legal, privacy, and risk owners can challenge assumptions.
Scope boundary: the Microsoft 365 assessment described here is separate from tenant-to-tenant migration, data movement, device re-enrollment, production policy changes, penetration testing, legal diligence, compliance certification, and continuous monitoring.
Start with the Microsoft 365 Security Assessment, then examine the specialist Entra ID, Conditional Access, Intune, and Exchange Online scopes. The assessment checklist can help prepare stakeholders and evidence.
FAQ
Post-merger Microsoft 365 assessment questions
When should Microsoft 365 be assessed during a merger or acquisition?
As early as authorization and transaction constraints allow, then again after material integration changes. Pre-close diligence, day-one access, migration, and post-integration validation answer different questions and require separately approved access.
Must the acquired tenant be consolidated immediately?
No. Microsoft documents multiple multitenant collaboration models. The right sequence depends on timing, identity sources, applications, contractual and regulatory boundaries, migration readiness, and the risk of changing access too quickly.
Does the assessment migrate users, mail, files, or devices?
No. It maps current conditions, validates evidence, identifies gaps, and recommends priorities. Tenant migration, identity engineering, data movement, device transition, and production changes need separately approved implementation plans.
What if the acquired tenant has incomplete documentation?
Record what is known, what evidence was unavailable, who owns each follow-up, and which decisions should wait. Missing documentation is not proof that a control is absent, but it limits assurance and integration planning.
Primary sources
Ground the design in current Microsoft and NIST guidance.
Microsoft documents the available multitenant capabilities and important configuration boundaries. NIST CSF 2.0 supplies a technology-neutral vocabulary for governing, identifying, protecting, detecting, responding, and recovering.
Make the inherited Microsoft 365 risk visible before broad integration.
Request an assessment with the transaction stage, tenant count, integration goal, and decision deadline. Scope and fixed pricing are confirmed before access.