Should IAM teams re-evaluate their NHI tooling choices after a major acquisition?

Why This Matters for Security Teams

A major acquisition is not just a corporate event. It changes identity sprawl, ownership boundaries, and the number of places where secrets, service accounts, API keys, and workload tokens can be hidden. In practice, tooling that looked adequate in a single environment often fails when it has to reconcile duplicate vaults, inherited privileges, and inconsistent revocation workflows across two operating models.

The underlying issue is usually visibility and control, not simply feature count. NHIs already outnumber human identities by 25x to 50x in modern enterprises, and only 5.7% of organisations have full visibility into their service accounts, according to NHI Mgmt Group’s Ultimate Guide to NHIs. After an acquisition, that gap widens because the combined environment often includes overlapping PAM, vault, RBAC, and CI/CD controls that do not agree on ownership or lifecycle state. NIST’s NIST Cybersecurity Framework 2.0 is useful here because it forces the discussion back to governance outcomes: identify, protect, detect, respond, and recover. In practice, many security teams discover their tooling gaps only after the first inherited key needs emergency revocation, rather than through planned integration testing.

How It Works in Practice

Re-evaluating NHI tooling after an acquisition should start with three questions: can the platform inventory every machine identity, can it map each identity to a business owner, and can it revoke or rotate access without manual escalation. That sounds basic, but post-merger environments often expose a mismatch between the way teams think identities are managed and the way they are actually deployed across code, pipelines, vaults, and cloud accounts.

The most practical test is to trace one service account or API key from creation to retirement across both organisations. If the tool cannot show where the credential was issued, where it is used, who owns it, and what happens when the parent system is retired, then it is not providing lifecycle control. NHI Mgmt Group’s Top 10 NHI Issues is a good reference for the kinds of failures that appear repeatedly: weak visibility, overprivilege, inconsistent rotation, and secrets stored outside managed systems. If the acquisition introduces more third-party integrations or inherited legacy tooling, the risk increases further because secrets can exist in places the acquirer never scans. The NHI research also shows that 79% of organisations have experienced secrets leaks, with 77% causing tangible damage, which is a strong signal that integration work should treat secret governance as a merger-critical control, not a cleanup task.

• Inventory all NHIs across both estates before consolidating tooling.
• Map each identity to an owner, workload, and decommissioning path.
• Test revocation in live-like conditions, not just in vendor demos.
• Verify rotation, expiry, and vault sync across pipelines, clouds, and legacy apps.

Tooling selection should also be checked against policy enforcement. If RBAC is static while the environment is dynamic, the platform may record entitlements but still fail to enforce intent at runtime. These controls tend to break down when the acquisition includes many legacy services with hard-coded secrets, because the identities cannot be centrally governed until the code and deployment patterns are changed.

Common Variations and Edge Cases

Tighter NHI controls often increase integration overhead, requiring organisations to balance consolidation speed against operational disruption. That tradeoff matters because not every acquired system can be moved into a new vault or PAM stack immediately, and some environments will need a phased coexistence model.

Best practice is evolving, but current guidance suggests separating two decisions: whether the current tooling is still fit for purpose, and whether the migration can happen in one step. In many acquisitions, the answer is no to the second question even if the first is yes. For example, a strong platform may still need connectors, policy translation, or compensating controls before it can govern both estates consistently. If the acquired business relies heavily on ephemeral workloads or CI/CD-generated secrets, the minimum acceptable test is whether the tool can support short-lived credentials and fast revocation without breaking release pipelines. That is where the lessons from the Cisco DevHub NHI breach and the broader 52 NHI Breaches Analysis become relevant: breach paths often begin with credentials that outlive the systems they were meant to protect.

Acquisitions also create edge cases around ownership. A platform may identify an NHI but still fail to answer who can approve access removal after a divestiture, regional carve-out, or platform merger. In those cases, the right move is to treat tooling evaluation as part of operational due diligence, not just as a post-close security project.

Related resources from NHI Mgmt Group

• When should teams prioritise NHI governance over other IAM work?
• What does the Cisco acquisition of Astrix Security mean for NHI tooling?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams make NHI best practices usable across the business?