Who should own security accountability in M&A integration?

Why This Matters for Security Teams

M&A integration creates a security ownership problem before it creates a technical one. Corporate development can define the deal terms, but it cannot validate whether the target environment has clean identity boundaries, rotatable secrets, or defensible offboarding. That burden sits with security, IAM, engineering, and the business owners who intend to inherit the environment. Without that shared accountability, unresolved access risk moves from diligence into production.

This is especially true for non-human identities, where inherited service accounts, API keys, OAuth grants, and automation credentials often outlive the deal team’s assumptions. NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, which helps explain why integration plans often miss what is already active in the acquired stack. The Ultimate Guide to NHIs and the NIST Cybersecurity Framework 2.0 both point to the same operational reality: ownership must be explicit, or access risk will be inherited by default.

In practice, many security teams encounter identity sprawl only after the acquisition has already been announced and the inherited credentials are still trusted by downstream systems.

How It Works in Practice

Accountability should be structured as a joint operating model, not a single handoff. Corporate development owns the deal conditions, but security owns the control requirements, IAM owns identity validation, engineering owns technical remediation, and application or platform teams own any remediation needed to keep critical services running. That division matters because M&A integration is not just inventorying users. It is proving whether the acquired environment can be safely folded into the parent’s trust model.

For NHIs, the practical sequence usually starts with discovery, then classification, then containment. Teams should identify service accounts, machine credentials, OAuth applications, certificates, CI/CD tokens, and automation agents, then determine which ones are business-critical, which ones can be retired, and which ones need to be reissued under the parent’s control plane. A useful pattern is to treat every credential as temporary until it is proven necessary. That means short TTLs, conditional approvals, and revocation paths that are tested before close, not after integration.

• Define one accountable executive for the integration risk register, then assign operational owners by control domain.
• Require pre-close identity due diligence for service accounts, secrets storage, third-party grants, and privileged automation.
• Use a quarantine or segmented trust zone until inherited non-human access is revalidated.
• Track remediation by system, not by team, so no critical credential is left behind in a gray area.

Current guidance suggests aligning this with zero trust principles and continuous verification rather than assuming inherited trust is acceptable. The State of Non-Human Identity Security shows why: organisations still struggle with visibility, rotation, and over-privilege, which means acquisition can easily import pre-existing weaknesses into a larger blast radius. These controls tend to break down when the target uses unmanaged automation across multiple cloud tenants because identity ownership becomes fragmented across platform teams and vendors.

Common Variations and Edge Cases

Tighter accountability often increases transaction friction, requiring organisations to balance speed against the cost of slowing or conditioning close. That tradeoff is real, especially when legal, finance, and business sponsors want a clean signing timeline while security teams need time to inspect identity dependencies.

One common edge case is a carve-out or partial acquisition, where the security owner for a credential changes multiple times during transition. Another is a regulated environment where inherited identities must be preserved temporarily for audit or continuity reasons. In those cases, current guidance suggests documenting a time-bound exception with named owners, expiration dates, and a revocation plan rather than leaving the asset in shared custody.

Another complication is the use of third-party managed services or outsourced operations. If the acquired environment depends on vendor-run automation, accountability must include contract and access governance, not just internal IAM. The non-human identity estate may also be larger than the human estate, so a human-centric approval model will miss the true blast radius. NHIMG’s research on the Ultimate Guide to NHIs makes clear that offboarding and rotation are still inconsistent across organisations, which is exactly why M&A plans need explicit ownership before integration starts.

Related resources from NHI Mgmt Group

• How should security teams think about a compromised integration like Drift?
• Who should own marketplace fraud accountability when losses appear late?
• Who should own IaC risk governance when DevOps and security share the same environment?
• How should security teams prioritise NHI remediation in cloud environments?