Who is accountable for inherited access risk in an acquisition, and what should they prioritise first?

Why This Matters for Security Teams

In an acquisition, inherited access risk becomes the buyer’s problem at closing, not after the integration team finishes its review. That matters because identity sprawl, stale service accounts, and undocumented secrets usually sit outside the clean boundary lines shown in deal documents. Current guidance from OWASP Non-Human Identity Top 10 and NHI Management Group’s Ultimate Guide to NHIs both point to the same operational reality: the hardest part is not policy writing, it is finding what actually exists.

For security teams, the immediate mistake is treating inherited access as a post-close hygiene task instead of a live exposure problem. The acquiring company owns the residual risk, even when the target created it, because the combined environment now accepts the blast radius. That means discovery, access mapping, and ownership transfer must start before privileges are used in production integration. In practice, many security teams encounter inherited NHI exposure only after a failed access review or an incident during migration, rather than through intentional due diligence.

How It Works in Practice

The first priority is to build a trustworthy inventory of human and non-human access across the target environment. That includes service accounts, API keys, certificates, vault entries, CI/CD secrets, and application-to-application trust paths. The goal is not a theoretical list, but a working map of who or what can reach which systems, under what conditions, and with what authority. NHI Management Group’s Ultimate Guide to NHIs — Key Challenges and Risks notes that visibility remains a major gap, which is why acquired environments often hide the riskiest access paths until they are actively probed.

Once discovery begins, prioritisation should follow exposure and business criticality, not organisational charts. High-risk accounts are usually those with broad lateral movement potential, persistent credentials, or direct access to production, finance, customer data, or deployment pipelines. The practical sequence is:

• Identify all privileged and machine-to-machine identities.
• Score access by sensitivity, reach, and whether the credential is static or ephemeral.
• Review segregation of duties conflicts and inherited exceptions.
• Transfer ownership for critical accounts to named operators in the acquiring organisation.
• Rotate or revoke secrets that lack a clear business need.

For control design, NIST SP 800-53 Rev. 5 Security and Privacy Controls provides a useful baseline for access enforcement and account management, while NIST Cybersecurity Framework 2.0 reinforces governance and risk response as ongoing functions rather than one-time checks. These controls tend to break down when the acquired estate includes shadow IT, hard-coded credentials in automation, or undocumented third-party integrations because ownership cannot be assigned quickly enough.

Common Variations and Edge Cases

Tighter acquisition controls often increase integration friction, requiring organisations to balance speed of consolidation against the risk of disabling business-critical workflows. That tradeoff is real, especially when the target runs legacy systems, regulated workloads, or outsourced operations with unclear support boundaries.

There is no universal standard for this yet, but current guidance suggests treating temporary continuity access as an exception with an expiry date, not as a reason to defer remediation. If an acquired application must stay online, the buyer should isolate it, reduce its trust relationships, and document every exception with an owner and review date. In higher-risk deals, the right first move may be to segment inherited identities before merging directories or federation paths.

One useful signal is the concentration of hidden non-human identity risk. NHI Management Group’s Ultimate Guide to NHIs reports that 97% of NHIs carry excessive privileges and only 5.7% of organisations have full visibility into their service accounts. That does not mean every acquisition has the same exposure, but it does mean the buyer should assume the target’s access model is more permissive than documented until proven otherwise. In practice, inherited access risk becomes urgent when integration teams inherit credentials faster than they can assign accountable owners.

Related resources from NHI Mgmt Group

• When does JIT access create more risk than it reduces?
• Should organisations prioritise external exposure or internal credential governance first?
• How should security teams prioritise NHI remediation in cloud environments?
• Why do non-human identities create more audit risk than human accounts?