Treat M&A as a live identity governance problem from the first negotiation. Security teams should inventory users, contractors, applications, devices, and delegated access early, then decide which identities will remain active after integration. The safest approach is to align diligence, deprovisioning, and logging with the actual deal structure, not with optimistic assumptions about post-close cleanup.
Why This Matters for Security Teams
Mergers and acquisitions compress months of identity risk into a few weeks of integration pressure. The danger is not only duplicate accounts, but inherited service accounts, stale API keys, shared admin access, and delegated trust that no one on the acquiring side can fully explain on day one. NHI Management Group research shows that only 20% of organisations have formal offboarding and revocation processes for API keys, while 97% of NHIs carry excessive privileges, which makes M&A a high-risk identity event rather than a simple IT consolidation. See the Ultimate Guide to NHIs and the NIST Cybersecurity Framework 2.0 for the governance baseline.
Security teams often get pressured to “stabilise first, clean up later,” but identity risk does not pause for integration work. Every surviving account, integration token, VPN exception, and contractor credential becomes part of the combined attack surface. The practical question is not whether the target environment is trusted, but which identities can be justified, monitored, and revoked on a deadline. In practice, many security teams encounter post-close identity sprawl only after an external audit, incident review, or failed application cutover has already exposed the problem.
How It Works in Practice
The safest M&A approach is to treat identity as a parallel workstream from diligence through Day 1 and Day 100. That means building a full inventory of human and non-human identities, mapping where each one authenticates, and identifying who owns the authority to keep it alive. The 52 NHI Breaches Analysis and the Top 10 NHI Issues both reinforce a recurring pattern: identity exposure is rarely isolated, because one compromised credential often reveals adjacent systems, secrets, or delegated access paths.
Operationally, teams should separate identities into decision buckets:
- Keep and re-authorise for business-critical functions.
- Keep temporarily under short-lived exception with named owner and expiry.
- Revoke immediately because the access is orphaned, duplicated, or unnecessary.
- Rebuild where inherited trust is too opaque to validate.
For non-human identities, this often requires secret discovery, token rotation, service account review, and application-by-application cutover planning rather than blanket directory synchronization. Current guidance suggests using least privilege, strong logging, and revocation evidence as non-negotiable controls, aligned with NIST CSF 2.0. Where possible, move high-value workload access to short-lived credentials and monitored federation instead of preserving static secrets simply because the deal timetable is tight.
M&A also needs a clear exception model. If an acquired business cannot fully integrate on Day 1, the temporary trust boundary should be explicit: limited network reach, tighter conditional access, separate admin paths, and continuous review of active tokens and delegated permissions. These controls tend to break down when legal close happens before technical ownership is assigned, because nobody can confidently approve or revoke the inherited access paths.
Common Variations and Edge Cases
Tighter identity controls often slow integration, so organisations have to balance deal velocity against the cost of unmanaged access. That tradeoff is especially visible when the target company uses shared service accounts, embedded secrets in code, or partner-managed integrations that are hard to disentangle without downtime. Best practice is evolving here, and there is no universal standard for exactly how much inherited access can remain temporarily live.
Regulated sectors usually need stronger evidence of who had access before and after close, while software-heavy acquisitions may need more emphasis on NHI discovery and secret rotation. In carve-outs, divestitures, and cross-border deals, ownership questions can be even harder than technical ones: a credential may be valid, but no longer permissible once the operating entity changes. The safest posture is to assume that every identity crossing the transaction boundary is suspect until it is revalidated, because hidden trust relationships are common in both humans and machine identities. For a deeper NHI lifecycle view, the Ultimate Guide to NHIs — Key Challenges and Risks remains the clearest starting point.
Teams should also remember that post-close cleanup is not the same as post-close control. If logging, revocation, and ownership review are not established immediately, the combined environment can remain exposed long after the integration project is declared complete.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | M&A requires identity inventory, access authorization, and continuous control of inherited access. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Inherited secrets and service accounts are a core NHI exposure during acquisitions. |
| NIST AI RMF | Risk governance should cover identity exposure introduced by automated and AI-enabled integrations. |
Assign accountability, assess identity risk, and document controls as part of the M&A governance process.
Related resources from NHI Mgmt Group
- How should security teams reduce identity risk in compliance automation programmes?
- Why do mergers and acquisitions create identity risk even when the acquirer has strong IAM controls?
- How should security teams handle identity governance when full IGA still leaves blind spots?
- How should security teams handle risks from AI browser extensions?
