Why do mergers and acquisitions make NHI governance harder?

Why This Matters for Security Teams

Mergers and acquisitions turn NHI governance into a discovery problem before it becomes a control problem. The acquiring team inherits service accounts, API keys, certificates, bots, and agent identities that were created under different owners, naming conventions, and lifecycle rules. That creates blind spots in ownership, rotation, and revocation. NHIs are especially hard to normalise after a deal because credentials often outlive the system they were meant to support, and access models rarely line up cleanly with NIST Cybersecurity Framework 2.0 expectations for asset visibility and identity governance.

This is one reason NHI risk compounds during integration. In The State of Non-Human Identity Security, 85% of organisations lacked full visibility into third-party vendors connected via OAuth apps, which is a useful proxy for how quickly inherited access can outpace oversight. The same pattern appears in acquisition work: teams often receive authentication material before they receive context on why it exists, who owns it, and whether it still supports business automation. The fastest path to exposure is assuming all inherited credentials are intentional. In practice, many security teams encounter stale NHI access only after the first integration review or incident, rather than through intentional pre-close inventory.

How It Works in Practice

Effective M&A NHI governance starts with inventory, then classification, then controlled transition. The goal is to distinguish active automation from dormant or abandoned secrets, and then decide what should be rotated, re-issued, scoped down, or retired. That work cannot rely on human IAM playbooks alone because NHIs frequently sit outside standard joiner-mover-leaver workflows. Current guidance suggests combining discovery tooling with application owners, infrastructure logs, and secret stores so the team can identify which identities are tied to production processes, vendor integrations, or privileged admin tasks.

Practitioners usually need to map at least four things: who owns the workload, what the identity can reach, how long the secret remains valid, and whether the identity is shared across multiple systems. The lifecycle view in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful here, because post-deal remediation is really a lifecycle reset. Where possible, rotate secrets into short-lived formats, rebind access to named owners, and use PAM or JIT controls for anything privileged. For broader context on common failure patterns, Top 10 NHI Issues highlights why over-privilege and poor rotation keep resurfacing during cleanup.

• Build a single inventory of NHIs across both organisations before production cutover.
• Tag each identity by system owner, business function, privilege level, and expiry date.
• Replace long-lived secrets with ephemeral credentials where the application allows it.
• Force re-approval for inherited admin or vendor-linked access.

Where the merged environment includes older platforms, unmanaged scripts, or embedded credentials in CI/CD, these controls tend to break down because the identity may be hard-coded into the application logic and cannot be rotated without downtime.

Common Variations and Edge Cases

Tighter NHI control often increases integration overhead, requiring organisations to balance speed of merger execution against the risk of breaking business-critical automation. That tradeoff is especially visible when one company uses modern vaulting and the other still depends on static secrets, shared accounts, or undocumented service principals. There is no universal standard for this yet, so best practice is evolving toward risk-based segmentation rather than a single migration template.

Some identities are easy to retire because they belong to test systems or abandoned integrations. Others are embedded in revenue workflows, partner links, or operational technology, where immediate removal would interrupt service. In those cases, current guidance is to stabilise first, then reduce exposure in phases: move toward 52 NHI Breaches Analysis style lessons learned, enforce stronger logging, and require explicit business ownership before renewal. For governance framing, Ultimate Guide to NHIs — Regulatory and Audit Perspectives helps teams translate inherited identities into audit-ready controls.

In complex integrations, the hardest cases are shared secrets used by multiple applications, contractor-managed automations, and legacy identities with no clear owner. Those environments make revocation risky, but leaving access untouched is riskier still. The practical answer is to time-box exceptions, document compensating controls, and retire the identity as soon as the dependency is disentangled.

Related resources from NHI Mgmt Group

• What makes agentic AI an NHI governance issue?
• What is the difference between attack surface management and NHI governance?
• Why is NHI governance critical in the age of AI attacks?
• How should security teams make NHI best practices usable across the business?