Security teams should start with discovery, then classify every inherited service account, key, token, and certificate by owner, privilege, and lifespan. After that, they should freeze new long-lived credentials, remove orphaned identities, and set one merged governance baseline for rotation, scoping, and decommissioning. The goal is to stop inherited access from becoming permanent.
Why This Matters for Security Teams
M&A is one of the fastest ways to inherit invisible NHI risk. Service accounts, API keys, certificates, OAuth grants, and automation tokens often arrive with unclear ownership, weak rotation, and no shared retirement plan. During integration, teams tend to focus on human access first, while machine access quietly keeps running in production, CI/CD, and third-party connectors. That is exactly where attackers look for persistence and lateral movement.
The practical problem is scale and exposure. NHI Mgmt Group research shows that only 5.7% of organisations have full visibility into their service accounts, and 97% of NHIs carry excessive privileges, which makes inherited access broad as well as hard to trace. Guidance from Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and the NIST Cybersecurity Framework 2.0 both point toward discovery, governance, and continuous control validation as the starting point.
In practice, many security teams only discover inherited NHI sprawl after a merger closes and an orphaned credential is already being used in production.
How It Works in Practice
The first step is a merger-wide inventory that groups every inherited NHI by business service, technical owner, privilege level, dependency, and expiry. That inventory should include secrets in code, CI/CD variables, vaults, and endpoint stores, not just directory objects. From there, classify what is critical, what is over-scoped, and what can be disabled immediately. This is where a merged baseline matters: one set of rules for rotation, scoping, approval, and decommissioning avoids the common trap of letting each acquired business unit keep its old habits.
Security teams should also freeze the creation of new long-lived credentials during the transition unless there is a documented exception. Best practice is to move high-risk automation toward NHI Lifecycle Management Guide style controls, where ownership, review cadence, and retirement are explicit. For offboarding, the operational goal is to revoke or rotate inherited secrets as soon as a service is rehomed, retired, or replatformed.
- Map each NHI to a named owner and a system owner, then remove anything orphaned.
- Reduce privileges before migration, not after, using RBAC and PAM only where they still fit the workload.
- Rotate keys, tokens, and certificates on a fixed schedule, with shorter TTLs for high-impact systems.
- Log usage before and after cutover so stale access can be identified and removed safely.
NIST’s identity and governance guidance aligns with this approach, and the NHI issue set documented in Top 10 NHI Issues highlights why rotation, visibility, and ownership failures usually travel together. These controls tend to break down when the acquired environment is packed with hard-coded secrets in legacy scripts and release pipelines because the dependency map is incomplete.
Common Variations and Edge Cases
Tighter credential control often increases integration overhead, requiring organisations to balance faster business continuity against slower, safer cutover. That tradeoff is especially sharp when the target company runs customer-facing services, regulated workloads, or vendor-connected workflows that cannot tolerate abrupt shutdowns. Current guidance suggests handling those exceptions with temporary compensating controls rather than leaving old access in place indefinitely.
There is no universal standard for exactly how fast every inherited secret must be retired, but the direction is clear: shorten lifespans where possible and treat exceptions as time-bound. For third-party integrations, be more cautious still, because vendor-connected OAuth apps and shared certificates often outlive the business process that created them. The Ultimate Guide to NHIs — Regulatory and Audit Perspectives is useful here because auditors usually care less about whether a merger was difficult and more about whether inherited access was governed, reviewed, and revoked.
Teams should also watch for one-off technical exceptions such as embedded appliance credentials, cross-cloud service principals, and emergency break-glass accounts. Those can be retained temporarily, but only with explicit owner approval, logging, and a dated removal plan. M&A programs fail when exceptions become the new normal and nobody is accountable for decommissioning them.
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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Rotation and lifecycle control are central to inherited NHI cleanup. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access review fits post-merger NHI governance. |
| NIST AI RMF | GOVERN and MAP functions support accountable AI-era identity governance. |
Assign accountability, document exceptions, and monitor inherited machine access continuously.
