What should teams do first when integrating identities after a merger or acquisition?

The first step is to establish a clear inventory of identities, applications, and access dependencies across both organisations. From there, teams can prioritise which directories, authentication methods, and lifecycle processes should be unified first. Without that baseline, every later decision is made in the dark, which increases the chance of access gaps, duplicate accounts, and delayed integration value.

Why Identity Integration Must Start With Discovery, Not Tooling

When two organisations merge, the first real problem is not technology selection but uncertainty about what is actually connected to what. Identity integration touches directories, authentication methods, application trust relationships, and lifecycle processes, so teams need a reliable baseline before they can safely consolidate anything. Without that baseline, they can easily create orphaned access, break sign-in flows, or leave duplicate identities active longer than intended. The control question is simple: know the current state before you change it. In practice, many security teams encounter the most expensive identity mistakes only after they have already started unifying systems without a complete dependency map.

For a control-oriented view of baseline access governance, the NIST SP 800-53 Rev 5 Security and Privacy Controls provides the kind of access and accountability structure teams need before they begin rationalising identity estates.

How Teams Should Sequence the First Integration Work

The first phase should be discovery, normalisation, and dependency mapping. That means inventorying user populations, administrative accounts, service accounts, directories, federation links, MFA methods, privileged roles, and application-specific authentication dependencies. Teams then need to reconcile naming collisions, inactive accounts, and duplicated entitlement models so they understand which identities are the same person, which are legacy artefacts, and which are application-bound exceptions.

Once the inventory exists, prioritisation becomes possible. The usual order is to stabilise authentication and central trust anchors first, then address lifecycle governance, then rationalise downstream application access. That sequence matters because authentication failures create immediate business disruption, while entitlement cleanup can often be staged more safely. It also helps teams avoid the common mistake of trying to collapse every directory and access policy at once. A staged approach reduces blast radius and gives stakeholders a chance to validate business-critical exceptions before they are lost in a blanket migration.

Inventory identities, directories, applications, privileged accounts, and machine-to-machine dependencies.
Map which authentication methods each application accepts and where legacy dependencies still exist.
Identify duplicate accounts, stale accounts, and overlapping administrative roles before any consolidation.
Rank systems by business criticality and by how much they depend on shared identity services.
Unify the highest-confidence trust and lifecycle processes first, then phase in the harder exceptions.

That approach aligns with common identity governance practice and with the idea that access control only works when the organisation understands who can authenticate, what they can reach, and how that access is revoked. It also avoids treating a merger like a pure infrastructure cutover. Identity programmes fail when they assume technical compatibility is the same thing as governance readiness. The guidance breaks down when teams lack authoritative owners for legacy applications, because no amount of sequencing can safely resolve unknown or unmaintained dependencies.

Where Merger Identity Programmes Get Delayed or Misrouted

Tighter identity integration often increases short-term operational overhead, requiring organisations to balance speed against the risk of disrupting critical access. One common variation is when the merger spans different authentication models, such as one side relying on local directories and the other on federated sign-in. Another is where business units insist on keeping legacy applications live while central identity teams are trying to standardise controls. Guidance varies by environment here, but the consensus remains that unknown dependencies must be resolved before aggressive consolidation.

Another edge case is privileged access. Admin accounts, break-glass accounts, and application owners often require a separate review path because they can preserve operational continuity even while standard user access is being unified. Teams should also be cautious with shared accounts and service dependencies, because these can hide the true blast radius of an identity change. The practical rule is to treat exceptions as design inputs, not cleanup noise. If teams ignore them, they usually discover them only after authentication problems start affecting production systems or audit evidence becomes incomplete.

In identity integration, the first step is rarely to move accounts. It is to decide which dependencies are real, which are duplicative, and which must be protected until the rest of the estate is understood.

Risk and Threat Considerations

Identity consolidation after a merger creates material exposure if teams unify systems before they understand inherited access paths. The main risks are orphaned accounts, inconsistent privilege, broken deprovisioning, and hidden trust relationships that survive long after the organisational change is complete.

Failure mechanism: During integration, stale accounts and overlapping directories can preserve access that nobody formally owns, while rushed consolidation can also remove legitimate access paths for critical users or applications. If privileged roles, federation rules, or application-specific exceptions are not mapped first, attackers or insiders may benefit from the resulting visibility gaps and weak revocation boundaries.

Impact: The result can be unauthorised access, delayed offboarding, audit failure, or operational disruption when business-critical applications lose valid authentication routes. In a merger, those failures are especially damaging because they affect both security posture and integration delivery at the same time.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	ID.AM-1 — Asset Inventory	Merger identity integration begins with knowing what identities and systems exist.
	PR.AC-1 — Identities and Credentials Issuance and Management	The question concerns sequencing identity unification and access governance.
Recommendation — Build and maintain a complete inventory of identities, applications, and dependencies before consolidation. Standardise identity issuance and access management after the estate is mapped.
CIS Controls v8	5 — Account Management	M&A identity work must identify, normalise, and retire duplicate and stale accounts.
	6 — Access Control Management	Teams must prioritise how access dependencies and privileged paths will be unified.
Recommendation — Reconcile accounts, remove duplicates, and verify ownership before merging access paths. Review access dependencies and privilege boundaries before changing authentication or lifecycle flows.
NIST SP 800-63	4 — Federation and Assertions	M&A integration often hinges on how directories and trust relationships are unified.
	2 — Identity Assurance	Identity proofing and assurance consistency matter when reconciling two organisations' identities.
Recommendation — Validate federation and trust assumptions before switching users to shared authentication. Compare assurance levels across both organisations before treating identities as equivalent.

Practitioner Guidance

What to prioritise: Start with the identities and access paths that can break the most business processes if they are wrong. That usually means directories, federation, privileged access, and the most critical application dependencies before any broad clean-up effort.

What to verify: Confirm that every identity source has an owner, every application has a known authentication dependency, and every privileged path has a revocation process. If any of those three are missing, treat consolidation as premature.

Practitioner takeaway: The best first move is not technical unification but governance clarity, because only a verified inventory tells teams where they can safely consolidate and where they must leave exceptions in place for now.