They should validate which credentials were intentionally transferred, rotate anything that was shared outside the approved vault, and retire accounts that no longer have a business owner. The goal is to remove ambiguity quickly so inherited access does not become permanent access. Post-close cleanup should be treated as part of the deal, not an afterthought.
What changes when an acquisition closes
Closing is the point where inherited access must be converted from deal-era convenience into controlled operational ownership. Credentials that were useful during diligence, transition support, and data-room access can become unnecessary exposure once the buyer owns the environment. The practical question is not only whether a secret still works, but whether anyone can still justify using it.
The first task is inventory with intent. Teams need to separate credentials that were formally transferred, credentials that were temporarily shared for the transaction, and credentials that were never meant to survive close. That distinction matters because a valid secret without a clear owner is effectively orphaned access, and orphaned access tends to persist longer than anyone expects.
A useful way to think about post-close cleanup is to treat credentials like other transferred operational assets: what remains should be documented, owned, and reviewable. Anything else should move toward rotation, replacement, or retirement. For a broader identity and access lens on this problem, see Ultimate Guide to NHIs — What are Non-Human Identities, which frames machine and application credentials as governed access material, not permanent fixtures.
Which credentials should be rotated, revoked, or retained
Credentials that were shared outside the approved vault, copied into email threads, embedded in scripts, or handed to external advisers should normally be rotated first. The same applies to any secret that crossed environments or existed as a temporary bridge during integration. If the credential was used to reduce friction during the deal, that is usually a sign it should not remain in steady-state production.
Some credentials can be retained, but only when there is a clearly assigned business owner, a documented purpose, and a defined renewal or expiry path. Long-lived API keys, service tokens, and shared administrative logins are the most common trouble spots because they are easy to forget and hard to trace later. The goal is not to preserve every working secret, but to preserve only the access that the post-close operating model actually requires.
Practical rotation work is usually easier when supported by a secrets program rather than ad hoc cleanup. NHIMG’s Secrets Management Guide is useful here because it ties rotation, centralisation, and secretless patterns to a normal operating model instead of a one-time remediation sprint.
How to stop inherited access from becoming permanent access
Post-close cleanup fails when nobody can answer who owns a credential, where it is stored, or what downstream systems depend on it. That is why owner reassignment and decommissioning have to happen together. If a credential no longer has a business owner, the safer default is removal, not preservation for future convenience.
Deal teams also need a clear cutoff for temporary access. A credential that was acceptable during transition should not survive simply because it still works. Once the approved vault or replacement control is live, the temporary path should be retired, and any remaining credentials should be checked for scope creep, duplicate use, or hidden dependencies.
For teams dealing with many transferred credentials, the strongest control is usually disciplined lifecycle management rather than one more manual review pass. API Key Management Guide is a good model for that lifecycle thinking because it covers scoping, revocation, and response when a key has been exposed.
Risk and Threat Considerations
Post-acquisition credentials are high risk because they often sit in the gap between legal close and operational hardening. That window is attractive to attackers and dangerous for defenders: a secret that was legitimate during diligence may still authenticate long after its original justification has expired, especially if no one has a clean inventory.
Failure mechanism: Temporary transfer access, shared vault paths, and orphaned accounts create replayable access that survives the transaction. If those credentials are reused in production or never rotated after close, a former support path becomes standing access.
Impact: The result can be unauthorized access, difficult attribution, and a widened blast radius across systems that were never meant to share the same secret history. At scale, the business impact is not just one exposed account, but lingering uncertainty about what else still authenticates.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Acquisition close creates orphaned and temporary credentials that must be retired or transferred cleanly. |
| NHI-02 — Secret Leakage | Deal-era sharing and vault bypass can leave credentials exposed outside approved storage. | |
| NHI-07 — Long-Lived Secrets | Post-close cleanup must prevent temporary access from turning into permanent access. | |
| Recommendation — Retire inherited credentials that no longer have an approved owner or business purpose. Rotate any credential that left the approved vault or was shared through informal channels. Replace long-lived inherited secrets with shorter-lived or centrally managed credentials. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Post-close cleanup is fundamentally about rotating, revoking, and managing authenticator lifecycle. |
| AC-2 — Account Management | Orphaned and unowned accounts must be disabled or removed after acquisition close. | |
| Recommendation — Rotate, revoke, and lifecycle-manage inherited authenticators promptly after close. Disable or remove accounts that no longer have an assigned business owner. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | The question concerns reassignment and retirement of credentials after ownership changes. |
| A.5.18 — Access rights | Inherited access should be validated, reduced, and removed once no longer justified. | |
| Recommendation — Reassign or retire identities and credentials as part of post-close ownership cleanup. Review and revoke access rights that are no longer justified after the acquisition closes. | ||
| CIS Controls v8 | CIS-5 — Account Management | The answer depends on inventorying, disabling, and removing stale accounts and credentials. |
| CIS-6 — Access Control Management | Transferred credentials need least-privilege validation and rapid revocation of unnecessary access. | |
| Recommendation — Inventory and remove stale accounts and credentials immediately after close. Restrict inherited access to only the minimum required for the post-close operating model. | ||
Practitioner Guidance
What to prioritise: Start with credentials that are shared, cross-environment, or not stored in the approved vault. Those are the highest-value cleanup targets because they are easiest to overlook and hardest to defend if they leak.
What to verify: Before trusting a credential, verify three things: who owns it now, whether it is still needed, and whether it has any undocumented downstream consumers. If any of those answers is unclear, treat rotation or retirement as the default decision.
Practitioner takeaway: The cleanest post-close posture is not “all inherited access removed immediately”, it is “every remaining credential has a named owner, a documented purpose, and a short path to retirement.”
Related resources from NHI Mgmt Group
- Who is accountable for revoking machine credentials after an acquisition closes?
- How can organisations reduce the risk of stale API keys and machine tokens?
- When should organisations rotate credentials after a supply chain incident?
- When should organisations rotate credentials after suspected secret exposure?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org