Why do mergers create such a large non-human identity risk?

Mergers often inherit service accounts, API keys, and certificates that were created under different governance standards and are poorly documented. Those identities can survive longer than human employees because they are not visible in ordinary HR-driven processes. That makes them a persistent attack path unless they are discovered and reviewed early.

Why This Matters for Security Teams

Mergers amplify NHI risk because identity inventories do not merge cleanly. Human joins and exits are usually visible to HR, but service accounts, API keys, certificates, automation tokens, and embedded secrets often survive as orphaned assets across both estates. Current guidance suggests treating this as an identity discovery problem first, then a privilege problem second. NIST Cybersecurity Framework 2.0 reinforces that asset visibility and access control must be continuous, not assumed during integration work.

The operational issue is not just that more NHIs exist, but that inherited NHIs often carry old trust relationships, weak rotation practices, and unknown dependencies. NHIMG’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, while 71% of NHIs are not rotated within recommended time frames. Those conditions are especially dangerous during acquisition when teams are trying to stabilise systems quickly.

In practice, many security teams discover the most dangerous inherited identities only after a post-merger incident, not through planned integration hygiene.

How It Works in Practice

The merger problem starts with incomplete inventory. Each company may use different vaults, naming conventions, CI/CD tools, and certificate authorities, so the combined environment often contains duplicate accounts, shadow service principals, and secrets stored outside approved systems. The first task is to build a unified discovery process across cloud, SaaS, on-premises, and pipeline tooling, then classify identities by workload, owner, privilege, and expiration.

From there, the practical control set is straightforward:

• Identify all NHIs and map them to business services before any trust is inherited.
• Revalidate every secret, token, and certificate for ownership, scope, and rotation status.
• Reissue credentials where provenance is unclear, rather than trying to preserve old trust chains.
• Apply least privilege and remove stale entitlements that were justified by legacy architecture.
• Track dependencies so revocation does not break production unexpectedly.

This aligns with the risk patterns described in 52 NHI Breaches Analysis, where exposed secrets and weak lifecycle control repeatedly turn into lateral movement paths. For implementation, the NIST Cybersecurity Framework 2.0 provides the right operating model: know what exists, know who or what can access it, and continuously verify that access remains justified. The real challenge is speed. During integration, business teams want systems to stay up, so expired or undocumented NHIs are often left running temporarily and then forgotten. These controls tend to break down when post-merger teams lack a single owner for shared platforms because no one can safely approve revocation or reissuance.

Common Variations and Edge Cases

Tighter NHI control often increases integration overhead, requiring organisations to balance merger speed against identity assurance. That tradeoff is real, especially when legacy platforms cannot support modern vaulting, workload identity, or short-lived credentials.

Best practice is evolving, but current guidance suggests prioritising high-risk NHIs first: externally exposed APIs, privileged automation, certificates with broad trust, and secrets embedded in build systems. A staged cutover is usually safer than a big-bang rotation, because some services depend on hard-coded credentials or undocumented certificate chains that cannot be changed immediately.

There is also a documentation gap that is easy to underestimate. A newly acquired team may insist an account is “temporary,” yet temporary identities often become permanent once the original engineers leave. The Top 10 NHI Issues and Ultimate Guide to NHIs — Key Challenges and Risks both point to the same operational pattern: excess privilege, weak rotation, and limited visibility compound quickly when two identity cultures are forced together. The safest merger posture is to assume every inherited secret is active until proven otherwise.

Related resources from NHI Mgmt Group

• Why do Office preview vulnerabilities create such a large identity risk?
• Why do non-human identities create more risk than many human accounts?
• Why do non-human identities create more remediation risk than many human accounts?
• Why do compromised credentials create such a large breach risk in healthcare systems?