Why do mergers and acquisitions create identity risk even when the acquirer has strong IAM controls?

Why This Matters for Security Teams

M&A is an identity event as much as a legal or financial one. The acquirer may have mature IAM, PAM and RBAC, but the target usually arrives with inherited service accounts, shared admin logins, stale contractors and undocumented integrations that were never built for a clean control environment. NHI Management Group’s research shows that only 5.7% of organisations have full visibility into their service accounts, which helps explain why identity debt survives diligence and then surfaces during integration.

The risk is not limited to missing accounts. Combined environments often expose secrets in code, CI/CD tooling and vaults, while temporary access granted for deal work lingers after close. Current guidance from the NIST Cybersecurity Framework 2.0 and NHIMG’s Ultimate Guide to NHIs both point to visibility, governance and lifecycle control as prerequisites, not optional cleanup. In practice, many security teams encounter orphaned access only after the first post-close outage, failed audit, or TSA extension, rather than through intentional pre-close discovery.

How It Works in Practice

The core failure mode is assuming the target’s identities will fit the acquirer’s steady-state model. They rarely do. During diligence, teams tend to catalogue human users and directory groups, but they miss machine identities that carry production access across SaaS, cloud, CI/CD, databases and partner links. That is where identity risk becomes operational: access paths that were acceptable in a standalone company can become toxic once trust boundaries collapse.

Practitioners should treat the carve-out or merger plan as an identity remediation program with explicit workstreams:

• Inventory human and non-human identities before Day 1, including service accounts, API keys, certificates and break-glass access.
• Map each identity to an owner, purpose, system dependency and expiration date.
• Re-issue secrets and rotate anything that was shared, hardcoded or inherited from a third party.
• Disable dormant access paths early, then re-enable only the minimum required for TSA or transition tasks.
• Align privileged access to a temporary exception register, not to permanent entitlements.

This is where the Top 10 NHI Issues becomes relevant: excessive privilege, weak rotation and poor visibility are not abstract problems, they are the exact conditions M&A amplifies. The better pattern is to use pre-close discovery plus post-close re-authentication, with every inherited secret treated as suspect until revalidated against policy. Best practice is evolving, but current guidance suggests that standing access should be eliminated first for privileged and machine identities, then for the long tail of low-risk accounts.

These controls tend to break down when the transaction spans multiple directories, shared SaaS tenants and legacy on-prem systems because ownership and dependency mapping are incomplete.

Common Variations and Edge Cases

Tighter identity control often increases transaction overhead, requiring organisations to balance security certainty against deal speed, TSA commitments and business continuity. That tradeoff is especially visible in carve-outs, where the buyer may not own all target systems on Day 1, and in roll-up acquisitions, where repeated integrations can create a backlog of exceptions.

There are also cases where the clean answer is not immediate revocation. Production service accounts, supplier tokens and certificate-based integrations may need staged replacement so core processes keep running. The practical approach is to narrow scope first, then shorten lifespan second, then remove permanence third. For high-risk secrets, the safest assumption is that inheritance equals exposure until proven otherwise. NHIMG’s 2024 ESG Report: Managing Non-Human Identities shows how common compromise and suspected compromise already are, which makes M&A a multiplier rather than a special case.

There is no universal standard for exactly how much inherited access is acceptable during TSA, but the operational rule is simple: if an identity cannot be owned, explained and time-boxed, it should not survive integration.

Related resources from NHI Mgmt Group

• Why do shadow IT apps create identity risk even when users still have valid SSO access?
• Why do non-human identities create compliance risk even when policies exist?
• Why do unmanaged software licenses create identity risk as well as cost waste?
• Why does shadow IT create identity governance risk?