Why do non-human identities become riskier after a merger?

Why This Matters for Security Teams

After a merger, NHI risk rises because identity sprawl is not just duplicated, it is also reinterpreted. Two organisations may use the same service account name, the same API key pattern, or the same vault process, but mean very different things by ownership, revocation, and acceptable lifetime. That is why hidden trust paths survive due diligence and why post-close integration often exposes more risk than the original breach surface.

This is not hypothetical. NHI exposure is already common: the Ultimate Guide to NHIs — Key Challenges and Risks 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. In a merger, those two weaknesses combine fast: poor visibility makes inherited access hard to find, and weak rotation makes inherited access hard to kill.

Security teams often assume the main task is unifying directories, but the real issue is proving which NHI still has legitimate business purpose after systems, vendors, and teams change. The NIST Cybersecurity Framework 2.0 is useful here because it pushes teams toward inventory, governance, and continuous monitoring rather than one-time cleanup. In practice, many security teams encounter residual access only after a post-merger application outage, a secrets review, or an audit has already exposed it.

How It Works in Practice

The merger problem usually appears in four places. First, identity naming breaks: one company may treat a service account as disposable deployment plumbing, while the other treats it as a controlled production principal. Second, credential lifetime breaks: long-lived keys, certificates, and tokens survive beyond their original business need. Third, authorisation breaks: RBAC inherited from two organisations may overlap in ways that create unintended privilege chains. Fourth, ownership breaks: no one can confidently answer who can revoke, rotate, or approve the NHI after integration.

Good practice is to inventory every NHI, classify it by workload, owner, and business function, then reconcile it against live access paths. Current guidance suggests using zero standing privilege, just-in-time access, and short-lived credentials wherever operationally possible. That means moving away from static, always-on secrets toward task-bound issuance and revocation, especially for deployment pipelines, integrations, and machine-to-machine API use. The Top 10 NHI Issues and JetBrains GitHub plugin token exposure illustrate how quickly exposed credentials become durable risk when they are not rapidly rotated or revoked.

• Build a merged NHI inventory before consolidating IAM policies.
• Tag each identity with owner, workload, environment, and expiry expectation.
• Rotate or replace long-lived secrets before enabling cross-company trust.
• Review RBAC overlaps for privilege chains, not just direct entitlements.
• Use PAM and approval workflows for break-glass access, not permanent access.

For control design, NIST Cybersecurity Framework 2.0 supports the inventory and recover steps, while the Ultimate Guide to NHIs — Why NHI Security Matters Now is a practical reminder that secrets often persist far longer than teams expect. These controls tend to break down when one acquired environment still depends on hard-coded credentials inside CI/CD and code repositories because revocation can disrupt production before replacements are ready.

Common Variations and Edge Cases

Tighter revocation often increases operational friction, so organisations have to balance merger-speed against assurance. That tradeoff is especially visible when acquired systems are legacy, outsourced, or embedded in customer-facing workflows that cannot tolerate downtime. Best practice is evolving, but there is no universal standard for how quickly every inherited NHI must be cut over.

Edge cases usually involve shared vendors, unmanaged integrations, and secrets embedded in code or build tooling. In those environments, intent-based authorisation is more reliable than static entitlement checks because the same NHI may need different access depending on whether it is migrating data, syncing records, or supporting a temporary coexistence bridge. Where possible, use workload identity, ephemeral secrets, and runtime policy checks so the identity proves what it is and the request proves what it is trying to do. That approach aligns with the OWASP NHI Top 10 and with NIST Cybersecurity Framework 2.0 principles around governance and continuous control.

For merger programmes, the most common failure is not malicious abuse but inherited ambiguity: an NHI is left active because no one can prove it is safe to remove. That is why NHI governance needs explicit owner transfer, expiry rules, and post-close validation, not just a directory merge. In the real world, residual access usually survives because integration teams optimize for continuity first and identity cleanup second.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?
• Why do non-human identities create more audit risk than human accounts?
• How should security teams govern non-human identities in Salesforce?