Who is accountable for revoking machine credentials after an acquisition closes?

Why This Matters for Security Teams

Acquisition close is not just a legal milestone. It is the point at which inherited machine credential, service accounts, API keys, certificates, and automation tokens become either controlled assets or undocumented attack paths. If revocation ownership is vague, old identities often persist across mergers, carve-outs, and environment stitching, creating hidden lateral movement opportunities. That is why lifecycle control is a core theme in the NHI Lifecycle Management Guide and the OWASP Non-Human Identity Top 10.

The practical failure is usually not technical inability to revoke. It is that no integration owner, application owner, or platform owner is explicitly assigned to decide whether a credential should be rotated, transferred, or killed. That gap matters because static secrets do not age out on their own, and post-close environments frequently contain more machine identities than anyone can inventory quickly. NHI Management Group’s research on the Guide to the Secret Sprawl Challenge shows how quickly undocumented secrets become operational debt once they spread across systems and teams. In practice, many security teams discover credential ownership only after a newly acquired environment has already been used as an entry point.

How It Works in Practice

Accountability should be assigned at the same level as control. The integration team coordinates the post-close program, but the inherited system owners, application owners, and platform owners must execute the actual credential decisions for their services. That means each credential needs an owner, a decision, and a deadline. The decision is usually one of three actions: revoke immediately, rotate to a newly controlled identity, or transfer under documented custody.

For machine credentials, the process should be tied to the asset register and the cutover plan, not to an informal cleanup ticket. A workable sequence is:

• Inventory all NHIs, secrets, certificates, and automation accounts in the acquired environment.
• Map each credential to a business service, runtime, or pipeline owner.
• Mark credentials as revoke, rotate, or retain with a named approver.
• Use short-lived replacement credentials where possible, rather than extending legacy secrets.
• Confirm revocation with logs, not just ticket closure.

This is also where evidence matters. The 2024 Non-Human Identity Security Report from Aembit found that 88.5% of organisations say their non-human IAM practices lag behind or are merely on par with human IAM, which helps explain why inherited credentials often slip through acquisition programs. Current guidance suggests treating revocation as a transition control, not a cleanup activity, and documenting it alongside access reviews, dependency mapping, and decommissioning. For identity design, the NIST SP 800-63 Digital Identity Guidelines reinforce the principle that identity proofing and lifecycle controls must be tied to accountable processes, even when the identity is non-human. These controls tend to break down when the acquired estate spans hybrid and multi-cloud systems because owners cannot reliably see where each secret is actually used.

Common Variations and Edge Cases

Tighter post-acquisition control often increases operational overhead, requiring organisations to balance rapid containment against business continuity. That is especially true when a credential supports a shared integration, a third-party connector, or a legacy batch job with unclear downstream dependencies.

There is no universal standard for this yet, but best practice is evolving toward time-boxed exceptions with explicit expiry dates and named approvers. If a credential cannot be revoked immediately, the integration team should still assign an interim owner, enforce a revocation date, and require compensating controls such as network restriction, rotation to a new secret, or conversion to ephemeral access. In regulated environments, legal hold or contractual transfer obligations may delay revocation, but those cases still need documented accountability and a tracked exit plan.

Edge cases are common when identity spans cloud tenants, outsourced operations, or shared administrative tooling. The right question is not whether a central review group can see the secret. It is whether a specific owner can prove that the credential is still required and safe to retain. Where that answer is missing, the credential should be treated as exposed until proven otherwise.

Related resources from NHI Mgmt Group

• Who is accountable when inherited NHI credentials remain active after a merger or acquisition?
• Who should be accountable for rotating and revoking machine credentials?
• When does a machine identity become a compliance problem?
• How do organisations reduce the dwell time of exposed credentials at scale?