Accountability should sit with the team that owns the merged identity programme, not with whichever side originated the account. That team needs authority to approve scope changes, remove dormant identities, and enforce the lifecycle baseline across both estates. If accountability is split, orphaned access tends to survive the integration window.
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.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Inherited secrets need rotation and retirement to remove stale access. |
| NIST CSF 2.0 | PR.AC-4 | Merged estates need one authority to manage access and exceptions. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero trust helps limit blast radius when inherited machine access is unclear. |
Use NHI-03 to force rotation, revoke dead accounts, and verify each inherited secret still has a business owner.
