Why do acquisitions increase IAM and PAM risk so quickly?

Why This Matters for Security Teams

Acquisitions compress months of identity risk into days. The buyer inherits accounts, service principals, shared secrets, privileged sessions, and trust relationships before those assets have been validated against the acquirer’s policy baseline. That is why IAM and PAM risk spikes so quickly: the environment is not just larger, it is temporarily less knowable. NHI findings often reveal the same pattern at scale, and NHIMG’s Top 10 NHI Issues shows how unmanaged access paths and stale secrets remain common even outside M&A events.

The practical problem is that legacy exceptions tend to survive the deal. A retired admin account, a third-party support token, or a broad PAM role may still work long after the business justification has vanished. Current guidance from the NIST Cybersecurity Framework 2.0 emphasizes governance and asset visibility, but acquisitions are where those controls are most often incomplete in execution. In practice, many security teams encounter privilege abuse only after integration has already widened the blast radius rather than through intentional review.

How It Works in Practice

The risk is usually highest in the first integration window, when identity teams are reconciling directories, PAM vaults, federation trusts, and application-specific access. At that point, the buyer must decide what to preserve, what to map, and what to revoke. The hardest part is that every inherited identity can have a different owner, purpose, and expiry assumption. If those attributes are missing, the safe default is often to over-retain access, which creates standing privilege.

Security teams typically reduce that risk by moving through four steps:

• Inventory all human and non-human identities, including service accounts, API keys, break-glass users, and vendor access.
• Map each identity to a business owner, an application dependency, and a current justification.
• Reissue or rotate secrets into the acquiring organisation’s control plane rather than trusting inherited credentials.
• Apply PAM reviews, session logging, and short-lived access where the inherited privilege cannot be removed immediately.

For non-human identities, the issue is often worse than with human users because workloads can continue to authenticate silently after the organisational chart has changed. NHIMG’s 2024 Non-Human Identity Security Report found that 88.5% of organisations say NHI practices lag human IAM, which aligns with the reality of post-acquisition cleanup. That is why many teams pair discovery with tighter runtime controls, using intent-based approval, ephemeral credentials, and workload identity rather than long-lived static secrets. The guidance is strongest where identity repositories are current and federated access is already rationalised; these controls tend to break down when multiple legacy directories, unmanaged SaaS tenants, and outsourced operations must be merged at once because ownership and dependency data are incomplete.

Common Variations and Edge Cases

Tighter post-merger access control often increases operational overhead, requiring organisations to balance containment against business continuity. That tradeoff is especially sharp in regulated services, 24x7 support environments, and deals that include critical production systems. Best practice is evolving, but there is no universal standard for how aggressively to cut inherited access on day one versus after validation.

Some acquisitions are relatively clean because both sides already use central SSO, modern PAM, and short-lived credentials. Others are difficult because the target runs local admin sprawl, embedded secrets, or vendor-maintained access paths that are undocumented. In those cases, the safest approach is often phased containment: freeze new privilege grants, rotate secrets, and require re-approval for privileged sessions before attempting full cleanup. NHIMG research on OWASP NHI Top 10 is also relevant here because inherited service identities can be chained into broader compromise if they are left active. Acquired environments that rely on unmanaged third-party support, shadow IT, or cross-tenant trust usually resist clean remediation because the access model was never designed for rapid ownership transfer.

Related resources from NHI Mgmt Group

• Why do mergers and acquisitions increase IAM and NHI risk so quickly?
• Why do Salesforce integrations increase NHI risk?
• Why do AI agents increase IAM and PAM risk?
• Why do mergers and acquisitions increase privileged access risk so quickly?