Identity in Mergers and Acquisitions Guide: Day One and Divestitures

Every acquisition brings in a second set of directories, tenants, privileged accounts and machine credentials that the buyer did not build, cannot yet see, and is about to connect to its own. Merger and acquisition security (M&A security) is mostly identity work: deciding what the target's people and systems can reach on day one, when to trust the other directory, which inherited service accounts and secrets to keep, and how to separate cleanly when a business is sold. This guide covers cyber due diligence for identity, day one access, coexistence and consolidation patterns (Microsoft Entra cross-tenant synchronisation, multitenant organisations, tenant to tenant migration, Active Directory forest trusts and SID filtering), inherited non-human identities, divestitures and transition services agreements, and how to measure progress. It is for identity architects, security leads and integration teams working on either side of a deal.

Key takeaways

• Due diligence does not end at signing. Limited access before close is normal, so plan a full identity discovery in the first weeks after it, and treat the target as untrusted until it is done.
• Day one is about minimum safe access. Give acquired staff collaboration and a few named applications through controlled guest or synchronised accounts, not a forest trust or network merge.
• Trusts and synchronisation are security decisions. Keep SID filtering on, use selective authentication, scope cross-tenant sync to named groups, and remove SID history after migration.
• Inherited non-human identities are the long tail. Service accounts, app registrations, OAuth grants, CI tokens and cloud keys outlast the integration project unless each gets an owner, a decision and a rotation.
• Divestitures reverse the problem. A transition services agreement keeps the buyer inside your systems for months; scope it, log it, time-box it and rotate every shared secret at exit.

Why identity is the integration risk

Acquisition risk in identity comes from joining two control environments designed separately: until they are reconciled, each side's weakest control applies to both. Recurring patterns:

Identity integration drag is the cost side: when consolidation stalls, the business runs two identity stacks and every new acquisition adds another layer of acquisition sprawl. Post acquisition identity risk peaks between close and consolidation, when access is granted fast and visibility is weakest.

Two cases show the stakes. In the Marriott case, attackers had placed a web shell on a Starwood system in July 2014, Marriott acquired Starwood in 2016 and the breach was detected in September 2018, affecting 339 million guest records (The Register). The UK ICO's penalty notice, as quoted by Herbert Smith Freehills, said a controller's due diligence "is not time-limited or a 'one-off' requirement" (Herbert Smith Freehills). In the Change Healthcare breach, UnitedHealth Group's chief executive told the US Senate "We were in the process of upgrading the technology that we had acquired", and that the server attackers entered "was not protected by MFA" (TechCrunch).

Cyber due diligence for identity

M&A due diligence on identity aims to price the integration and spot anything that should change the deal: an active compromise, missing MFA on remote access, or an estate that will take years to integrate. Pre-signing access is usually limited to documents and interviews, so ask for evidence rather than assurances; the deal team decides how findings affect terms.

Plan a compromise assessment of the target's identity estate as soon as the deal allows (privileged group history, new admin accounts, unfamiliar federation or app consent, unusual sign-ins) and treat it as a gate for any connection to your environment.

Day one access

Day one access is what acquired employees can do on the first day after close. The goal is visible progress (email, chat, a few shared applications) without exposing either environment to the other's unknowns.

• Collaborate before you connect: give acquired users B2B guest or synchronised external member accounts in your tenant for named applications, and leave both directories separate.
• Apply your baseline to their access: conditional access policies, phishing-resistant MFA for anyone reaching your applications, and device compliance where you can assess it.
• Restrict administration: no administrator in either organisation gets rights in the other on day one. Integration engineers use dedicated, time-limited accounts.
• Freeze and watch: freeze changes to privileged groups and federation in the acquired estate, and forward its identity logs to your security operations from close (earlier only if the deal team confirms it is permitted).
• Warn about deal-themed phishing: tell acquired staff how integration requests will and will not arrive. See the Account Recovery and Help Desk Security Guide.

Integration patterns: coexist, collaborate, consolidate

Post acquisition integration, or post merger integration when peers combine, usually moves through three states. Choose the pattern per state, not once for the whole deal.

Cross-tenant synchronisation and multitenant organisations

Microsoft's documentation describes cross-tenant synchronisation as automating "creating, updating, and deleting" B2B collaboration users and groups across tenants, as "a push process from the source tenant". The target tenant must allow it in cross-tenant access settings ("Allow user synchronization into this tenant"), and automatic redemption must be set on both sides. Users arrive as external members (the default) or guests. Users deleted, unassigned or out of scope in the source are soft deleted in the target and hard deleted after 30 days, but blocking sign-in in the source is only an update to accountEnabled, so test leaver behaviour explicitly. Sync is one-way, and Microsoft is clear that it "isn't a migration tool because the source tenant is required for synchronized users to authenticate." Each synchronised user needs Entra ID P1 in the source tenant.

A multitenant organisation groups up to 100 active tenants you own under one owner tenant; each tenant can join only one, and Microsoft says it is "best deployed with the use of a bulk provisioning engine" such as cross-tenant synchronisation. Use it only when the group will keep several tenants for years.

Active Directory consolidation, forest trusts and SID filtering

Active directory consolidation is still the end state for most acquisitions with on-premises estates, and a forest trust is the usual bridge. Microsoft's guidance on trust security explains why SID filtering exists: without it, an administrator in a trusted forest could add a privileged SID from the trusting forest to the SID history of an account they control "and attempt to gain full access to the trusting forest". SID filtering is on by default for new interforest trusts, and Microsoft describes disabling it as reducing the security of the forest and "not recommended". Selective authentication goes further, requiring the "Allowed to Authenticate" permission on each computer object that trusted users may reach.

Migration tools often preserve SID history so migrated users keep access to old resources. MITRE ATT&CK tracks the abuse as T1134.005 SID-History Injection and recommends cleaning up SID-History attributes after legitimate migrations, applying SID filtering to forest and external trusts, and disabling SID history on forest trusts. Re-permission resources to the new accounts, then clear SID history. Monitor directory service changes to the sIDHistory attribute (Event ID 5136, as ATT&CK's detection notes describe) and Windows security events 4765 and 4766 for SID history added or failed attempts. See the Federation and Trust Relationships Guide and the Active Directory and Entra ID Hardening Guide.

For hybrid identity, Microsoft supports synchronising multiple forests to one tenant provided "a user is represented only once", and names merger or acquisition as a typical source of multi-forest designs. Microsoft Entra Cloud Sync "natively handles multiple disconnected Active Directory forests", which suits acquired forests that cannot be networked to yours. One constraint shapes every plan: "It's not supported to add and verify the same custom domain name in more than one Microsoft Entra tenant", so a domain moves between tenants only by removing it from one and verifying it in the other, a planned outage window.

Tenant to tenant migration

Microsoft's cross-tenant mailbox migration exists for exactly this case: "During mergers or divestitures, you might need the ability to move your users' Exchange Online mailboxes into a new tenant." Identity preparation is the critical path: each moving user needs a MailUser in the target with a matching ExchangeGUID, the LegacyExchangeDN and all x500 addresses copied, and a UPN aligned to the new identity. Moves are scoped by a mail-enabled security group in the source and authorised through an app registration with the Mailbox.Migration permission and organisation relationships in both tenants; that app is a privileged NHI to remove when migration ends. Only mailbox content moves: Microsoft 365 Groups, Teams chat, signatures and labels do not, and mailboxes on hold are blocked. Each user needs a one-time cross-tenant migration licence.

Inherited service accounts and credentials

Inherited non-human identities are where integrations quietly fail. Human accounts are visible through HR; service accounts, app registrations and tokens are not, and the people who know them may leave after the deal. Inherited credentials include anything the target's staff, former staff, MSPs or the seller's shared services knew or could reach.

• Inventory everything non-human: AD service accounts and gMSAs, Entra app registrations and service principals, OAuth consents to third-party apps, cloud access keys and roles, CI/CD secrets, SSH keys, certificates and API keys in SaaS tools. See the Service Account Security Guide.
• Assign an owner and a decision: keep, migrate, replace or retire, with a date. Unowned identities are disabled after a hold period. See the NHI Ownership Guide.
• Find forgotten tenants: the Microsoft Midnight Blizzard breach began in a forgotten test tenant with an OAuth app that held rights in production. Acquired estates are full of such tenants.
• Rotate on a schedule tied to the deal: rotate every secret known to departing staff, the seller or outgoing providers. The Cloudflare breach showed what four credentials left unrotated after an earlier incident can do.

Divestitures, carve-outs and transition services agreements

Divestiture security is the mirror image: a business leaves with its people and some systems, and identity must be separated without breaking either side. An identity carve out means deciding which accounts, groups, applications, NHIs and data go with the divested business, standing them up in a new environment, and removing the buyer's reach into yours.

A transition services agreement (TSA) lets the divested business keep using the seller's systems, such as email, ERP or the service desk, for a defined period while it builds its own. From an identity angle a TSA is time-limited third-party access, and should be controlled like one. See the Third-Party Access Guide.

Divestiture data separation is usually the hardest part, because data was never labelled by business unit; start classifying early. If the buyer takes a domain, it must leave your tenant before they can verify it.

Identity integration governance

M&A identity integration needs its own governance, separate from the wider integration programme:

• Integration decision log: every trust, sync scope, exception and deferred decision recorded with owner, rationale and expiry. This is how identity integration debt stays visible.
• Joiner-mover-leaver from day one: connect the acquired HR feed so leavers in the acquired business lose access in both environments. See the Joiner-Mover-Leaver Guide.
• Policy alignment deadline: a date by which the acquired estate meets your MFA, privileged access and review standards, with a risk acceptance from a named executive if it slips.
• Access reviews of interim access: review integration groups, guest accounts and cross-tenant scopes every month during integration. See the Access Reviews Guide.

How to implement

1. Before signing: run the due diligence requests above, size the integration, and agree with the deal team which findings must be remediated before connection.
2. Sign to close: design day one access, prepare B2B or cross-tenant sync configuration in a test tenant, line up log forwarding, and plan the compromise assessment.
3. Day one: enable scoped collaboration only. Keep directories and networks separate. Rollback is simple: disable the sync configuration or cross-tenant access settings.
4. First 90 days: complete identity and NHI discovery, run the compromise assessment, enforce MFA and privileged access standards, and rotate secrets known to departing parties.
5. Coexistence: add forest trusts only where named applications need them, with SID filtering and selective authentication, and pilot migrations in waves of a few dozen users.
6. Consolidation: migrate in waves with a tested rollback per wave (keep source accounts disabled, not deleted, until the wave is signed off), re-permission resources, then clear SID history.
7. Decommission: remove trusts, cross-tenant settings, migration app registrations and old tenants or forests, and record the closure in the decision log.

Small acquisitions (a few hundred users, one cloud tenant, no on-premises forest) can often skip coexistence: B2B for day one, then a direct tenant to tenant migration within a quarter. Large mergers with multiple forests should plan for a year or more of coexistence and agree the post merger identity end state (one tenant, or a multitenant organisation) early, rather than drifting into it.

Detection and measurement

Monitor changes to trusts and cross-tenant access settings, additions to privileged groups in either estate, SID history changes, new app consents and app registrations, sign-ins by acquired accounts to applications outside the day one scope, and use of accounts belonging to known leavers. Track:

• Identity discovery coverage: percentage of acquired directories, tenants and NHIs inventoried with an owner.
• Policy alignment: percentage of acquired users and admins meeting your MFA and privileged access standards.
• Inherited NHI disposition: share of inherited non-human identities with a keep, migrate or retire decision executed.
• Interim access age: integration groups, guests and exceptions past their expiry date.
• Consolidation progress: remaining trusts, forests, tenants and accounts with SID history.
• TSA exit completeness: TSA services exited on time with accounts disabled and secrets rotated.

Framework mapping

Common failure patterns

• Trust first, discovery later: a two-way forest trust on day one with SID filtering relaxed for migration, connecting an unassessed estate to yours.
• Acquired remote access left as it was: legacy VPN or portal access without MFA, the entry point in the Change Healthcare breach.
• Two leaver processes: HR leavers removed in the acquired directory but not in synchronised or guest accounts in yours.
• Inherited NHIs nobody owns: service accounts and app registrations kept "until we understand them", which never happens.
• Forgotten tenants and test environments: left outside every integration scope, as in Midnight Blizzard.
• Open-ended TSAs: divested staff keep access long after the agreed exit because nobody owns the end date.

Practitioner checklist

• Request directory, tenant, privileged access, MFA and NHI evidence in due diligence, not just questionnaire answers.
• Run a compromise assessment of the acquired identity estate before connecting it.
• Limit day one to scoped collaboration with your MFA and conditional access applied.
• Scope cross-tenant synchronisation to assigned groups and test leaver behaviour end to end.
• Keep SID filtering enabled, use selective authentication, and clear SID history after re-permissioning.
• Inventory every inherited non-human identity, assign an owner and decision, and rotate secrets known to departing parties.
• Connect the acquired HR feed to joiner-mover-leaver processes within the first weeks.
• Control TSA access as third-party access with fixed end dates and a written exit.

Standards and references

• Microsoft Learn: What is cross-tenant synchronization in Microsoft Entra ID?
• Microsoft Learn: What is a multitenant organization in Microsoft Entra ID?
• Microsoft Learn: Cross-tenant mailbox migration
• Microsoft Learn: Topologies for Microsoft Entra Connect
• Microsoft Learn: What is Microsoft Entra Cloud Sync?
• Microsoft Learn: Security Considerations for Trusts
• MITRE ATT&CK: T1134.005 SID-History Injection
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations

Related NHI Mgmt Group resources: Joiner-Mover-Leaver Guide · Active Directory and Entra ID Hardening Guide · Third-Party Access Guide · Service Account Security Guide. This guide summarises identity considerations in mergers, acquisitions and divestitures, including transition services agreements, and is not legal advice.