What breaks is accountability. Service accounts, tokens, and automation identities can survive the transaction with no clear owner, no agreed revocation path, and no verified rotation plan. That leaves the merged environment exposed to stale access, privilege inheritance, and hidden dependencies that human-only diligence will miss.
What fails first when diligence treats every identity as human?
Transaction teams usually look for named administrators, job roles, and access approvals, but non-human identities do not fit that model. The issue is not only missed credentials, it is missed control ownership: the buyer cannot tell which service accounts, tokens, or automation identities are business-critical, who can revoke them, or which system depends on them. That makes the deal’s access picture incomplete from day one.
M&A diligence that ignores non-human identities also creates a false sense of closure. The target may appear clean because human accounts were reviewed, while machine access still spans integrations, scripts, CI/CD jobs, SaaS connectors, and shared accounts. Without that inventory, the buyer inherits access paths it did not approve and cannot readily explain to auditors, operators, or incident responders.
A useful way to think about the break is that diligence stops being a control exercise and becomes a document exercise. If the review cannot answer where each non-human identity lives, what it authenticates to, and whether it has an owner, then the merger inherits hidden access rather than governed access. NHIMG’s Ultimate Guide to NHIs frames this as a lifecycle and governance problem, not a narrow inventory task.
Why does hidden machine access become a post-close liability?
Hidden machine access becomes a liability because it survives organisational change better than human access does. Employees leave, titles change, and deal teams reassign responsibilities, but scripts, API keys, service principals, and workload credentials often keep working unless someone deliberately finds and rotates them. That creates stale access, duplicate privileges across both sides of the transaction, and paths that still trust the old environment long after the legal entity has changed.
The hardest failures are usually indirect. One integration depends on another, a token is embedded in a build job, or a certificate is tied to an old owner and an old renewal path. Those dependencies can break months later during a password reset, a cloud migration, or a decommissioning project. NHIMG’s Service Account Security Guide and Guide to NHI Rotation Challenges both reinforce that access continuity depends on discovery, ownership, and rotation, not just initial provisioning.
In practical terms, the merger inherits two risks at once: privilege inheritance from the target, and dependency failure in the combined estate. If the surviving identity still has production reach, then compromise potential remains. If the surviving identity is revoked too aggressively, business processes can fail. That is why the diligence output must be more than a spreadsheet of accounts; it needs a revocation and continuity plan for each non-human identity class.
What does good diligence need to establish before close?
Good diligence needs to establish four things: what the non-human identity is, who owns it, what it can access, and how it will be retired, renewed, or transferred. The buyer should know whether the identity is tied to a service, a pipeline, a vendor integration, or an automation workflow, because each one has a different blast radius and a different cutover method.
The review should also distinguish between identities that can be rotated safely and identities that require coordinated change windows. Tokens used by integrations, certificates that support production traffic, and secrets embedded in deployment tooling all behave differently during integration. NHIMG’s Joiner-Mover-Leaver (JML) Guide is useful here because the same lifecycle logic applies to leavers in a company and to identities that must be removed, transferred, or re-owned during a transaction.
In diligence terms, the minimum acceptable outcome is a mapped revocation path with a named owner for each material identity. If the team cannot show where rotation will happen, what breaks if it is delayed, and who signs off on the exception, then the identity is still effectively orphaned even if it is documented. The NHI Ownership and Accountability Guide is directly relevant because ownership is the control that turns discovered access into governed access.
Risk and Threat Considerations
Leaving non-human identities out of M&A diligence creates exposure that is easy to miss and hard to unwind. The merged environment can inherit dormant but still-valid credentials, overprivileged integrations, and third-party access paths that no one has the authority to revoke quickly, which makes both accidental outage and malicious abuse more likely.
Failure mechanism: ownership gaps allow old service accounts, tokens, and automation identities to persist after close, while inherited permissions and hidden dependencies keep them operational.
Impact: attackers or insiders can exploit stale machine access for persistence, lateral movement, data access, or disruption, and the business can also break its own integrations when it finally tries to clean up the mess.
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 |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers credential rotation and lifecycle control for machine access inherited in M&A. |
| IA-9 — Service Identification and Authentication | Applies to service-to-service and workload identities that must be validated during diligence. | |
| AC-6 — Least Privilege | Non-human identities in M&A often inherit excessive access that should be reduced. | |
| Recommendation — Inventory authenticators and enforce rotation or revocation before closing inherited access. Verify and document service authentication paths before approving post-close connectivity. Reduce inherited machine privileges to the minimum needed for each retained integration. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Diligence must establish who can access what and under which conditions. |
| A.5.18 — Access rights | Supports review, transfer, and removal of rights attached to inherited identities. | |
| Recommendation — Map access rights for non-human identities and remove unapproved paths during integration. Review and reassign or revoke inherited access rights for every retained identity. | ||
| CIS Controls v8 | CIS-5 — Account Management | Directly addresses discovery, ownership, and removal of orphaned and stale accounts. |
| Recommendation — Identify, own, and disable orphaned service accounts and tokens before they persist into the merged estate. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | M&A diligence failures often leave non-human identities active after ownership changes. |
| NHI-05 — Overprivileged NHI | Inherited machine identities often keep excess access after a merger. | |
| Recommendation — Build a formal offboarding path for every non-human identity affected by the transaction. Right-size inherited NHI privileges before allowing the merged environment to operate. | ||
Practitioner Guidance
What to prioritise: Start with identities that can affect production, data movement, or privileged automation, because those create the fastest route to both compromise and operational failure. A low-risk internal script account is not the same as a token that can deploy code or reach customer data.
What to verify: For each material non-human identity, verify an owner, an authenticating mechanism, an expiry or rotation method, and the downstream systems that will fail if it is removed. If any one of those is missing, treat the identity as unresolved rather than merely undocumented.
Common mistake: Teams often postpone machine-identity work until integration planning, but by then they have already committed to a cutover timeline without knowing which access paths are brittle. The safer rule is to identify the revocation dependencies before legal close, not after operational integration starts.
Practitioner takeaway: The right diligence question is not “does this environment have accounts?”, it is “can we explain, own, and safely retire every non-human identity that can still act after the transaction?”