Why do mergers and acquisitions create IAM risk so quickly?

Why This Matters for Security Teams

Mergers and acquisitions compress identity risk into a very short window because two different trust models have to operate as one before the organisation has time to rationalise them. Directory merges, application sprawl, and mismatched approval chains often leave inherited access in place long after it should have been reviewed. That is why IAM becomes one of the fastest-moving control failures after close, not a later cleanup item.

This is especially dangerous for non-human access, where service accounts, API keys, and automation credentials can be hidden inside application stacks and overlooked by human-centric reviews. NHIMG research shows that 88.5% of organisations say their non-human IAM practices lag behind or merely match their human IAM maturity, which helps explain why post-deal normalisation so often starts from a weak baseline. Guidance in the NIST Cybersecurity Framework 2.0 reinforces the need to understand current-state identity controls before combining environments.

In practice, many security teams discover privilege overlap only after a user or workload has already inherited access from the acquired environment.

How It Works in Practice

The IAM risk curve rises immediately because M&A activity usually prioritises business continuity over identity clean-up. Accounts, groups, federation paths, and privileged roles are often preserved to avoid disrupting finance, ERP, customer systems, or automation pipelines. The problem is that the merged environment now contains two sets of assumptions about who can access what, who approves it, and how quickly it should be revoked.

For human access, teams typically start with account inventory, privileged access review, and exceptions handling. For non-human access, the work is harder because workloads do not always have a single owner, and credentials may be embedded in CI/CD jobs, orchestration tools, or third-party integrations. That makes discovery and normalization central to the first 30 to 90 days. NHIMG’s Top 10 NHI Issues and Ultimate Guide to NHIs — Key Challenges and Risks both reflect the same operational reality: secrets and workload identities are frequently distributed across systems that are not designed for rapid inheritance.

• Build an authoritative inventory of users, service accounts, API keys, certificates, and federated trust links.
• Map legacy approval paths to the target operating model before cutover, not after.
• Identify standing privilege and revoke or reissue access on a time-bound schedule.
• Force owners for every non-human identity, including automation and integration accounts.
• Validate that secrets rotation, logging, and deprovisioning work across both environments.

Where possible, align the combined program to identity governance principles in NIST CSF 2.0, because post-merger risk is often a visibility problem before it becomes a technical one. These controls tend to break down when the acquired company relies on undocumented service accounts and shared secrets embedded in production workflows, because ownership cannot be assigned fast enough to revoke access safely.

Common Variations and Edge Cases

Tighter access control often increases operational friction, requiring organisations to balance rapid integration against the risk of breaking critical business services. That tradeoff is most obvious when the acquired company runs regulated workloads, outsourced administration, or deeply embedded automation that cannot tolerate immediate credential changes.

There is no universal standard for M&A identity integration timing, but current guidance suggests treating high-risk access first: privileged admin roles, externally exposed workloads, and secrets used by production integrations. The most common exception is carve-out transactions, where partial separation can delay full IAM convergence and force temporary trust relationships. Another edge case is cloud-to-cloud acquisition, where both organisations already use modern federation but still differ in role design, token lifetimes, and secret distribution patterns.

The biggest mistake is assuming that identity normalisation can wait until after functional integration. NHIMG research on the Ultimate Guide to NHIs — Why NHI Security Matters Now shows why that is rarely safe: weak inherited controls become the new baseline quickly, especially for machine identities that are difficult to see and even harder to unwind.

Related resources from NHI Mgmt Group

• Why do mergers and acquisitions create identity risk even when the acquirer has strong IAM controls?
• Why do self-service employee workflows create IAM risk if they are not governed?
• Why do inconsistent semantics create risk for IAM and AI governance?
• Why do automated content pipelines create identity risk for IAM teams?