Who should be accountable for inherited NHI risk in M&A?

Why This Matters for Security Teams

When NHI risk is inherited in an acquisition, the problem is not just who created the account; it is who can now govern it, prove its purpose, and remove it when it no longer belongs. That distinction matters because NHI sprawl often outlives the merger timeline, especially when service accounts, API keys, and pipeline tokens are duplicated across environments. NHI Management Group research shows that only 5.7% of organisations have full visibility into their service accounts, while 79% have experienced secrets leaks, with 77% causing tangible damage, which makes post-merger blind spots operationally expensive. Current guidance in Ultimate Guide to NHIs and NIST Cybersecurity Framework 2.0 is consistent on one point: accountability must map to the organisation that can enforce lifecycle control, not the organisation that historically owned the secret. In practice, many security teams discover inherited NHI exposure only after the integration window has already closed, rather than through intentional governance.

How It Works in Practice

The accountable team should treat inherited NHI estates like any other merged asset class: inventory first, classify second, then decide whether each identity is retained, remediated, or retired. That means the merged identity programme owns the decision rights for scope changes, exception handling, approval of continued use, and final offboarding. The operational pattern is to centralise governance while allowing technical remediation to be executed by platform, application, or infrastructure owners under that central authority. A practical workflow usually includes:

• Building a single post-close inventory from both estates, including dormant service accounts, CI/CD secrets, certificates, and machine tokens.
• Assigning one control owner for the merged NHI programme, with explicit authority to revoke access and force rotation.
• Revalidating each identity’s business purpose and dependency chain, especially where one side inherited access to the other’s systems.
• Replacing long-lived static secrets with JIT or short-lived credentials where the workload supports it.
• Moving high-risk accounts into stronger governance patterns such as PAM, RBAC review, and ZTA-aligned access checks.

This is also where breach history matters. The 52 NHI Breaches Analysis and the Top 10 NHI Issues show how quickly unmanaged machine credentials become attack paths when ownership is unclear. For implementation discipline, NIST CSF 2.0 and NIST Cybersecurity Framework 2.0 both point toward defined governance, continuous monitoring, and timely corrective action. These controls tend to break down when the acquisition includes legacy automation, because undocumented dependencies make revocation risky and teams delay cleanup until after the integration freeze.

Common Variations and Edge Cases

Tighter central control often increases remediation cost and transition friction, so organisations must balance speed of integration against the risk of leaving inherited identities active too long. There is no universal standard for this yet, but current guidance suggests that the merged identity owner should keep decision authority even when execution is delegated to local teams. That prevents the common failure mode where each side assumes the other will retire redundant credentials. A few edge cases need special handling:

• Shared platform accounts may need temporary dual oversight during cutover, but only with a defined expiry date and named approver.
• Regulated workloads may require evidence that access decisions were reviewed under formal policy, not simply carried over from the acquired company.
• Third-party managed services can obscure accountability, so contract owners and security owners should be mapped before revocation begins.
• If the inherited estate includes agentic automation or autonomous tooling, the risk profile is higher because tool-chaining can amplify access faster than a human reviewer expects.

For that reason, NHI governance should be aligned to the merged operating model, while workload identity, secret rotation, and offboarding remain continuous controls rather than one-time merger tasks. The Ultimate Guide to NHIs — Key Challenges and Risks and Ultimate Guide to NHIs — Why NHI Security Matters Now both reinforce the same operational lesson: the longer inherited identities remain in place, the harder it is to prove whether they are still needed. In practice, the riskiest exposures are usually found after normalisation work has started, not during the due-diligence checklist.

Related resources from NHI Mgmt Group

• Who is accountable when inherited NHI credentials remain active after a merger or acquisition?
• Why do leaked secrets remain such a persistent NHI risk?
• What makes idle secrets such a serious NHI risk?
• What is the main NHI risk in ServiceNow integrations?