Who is accountable for inherited access after an M&A event?

Accountability should sit with the acquiring organisation’s identity and security leadership, but each inherited account still needs a named business owner. Without explicit ownership transfer, access reviews become unreliable and deprovisioning stalls. Governance teams should require ownership assignment as part of every integration milestone.

Why This Matters for Security Teams

After an M&A event, inherited access is rarely a clean IAM problem. It is an ownership problem, a change-management problem, and often a records problem. Security teams need to know who can approve access, who can revoke it, and who is accountable when inherited service accounts, API keys, or admin entitlements remain active longer than intended. That is especially important because NHI governance gaps are common: NHI Mgmt Group reports that only 20% of organisations have formal offboarding and revocation processes for API keys in its Ultimate Guide to NHIs.

The practical risk is that inherited access often crosses business boundaries before the integration team has mapped systems, owners, and dependencies. Security leadership may inherit the technical controls, but business ownership still has to move with the asset. Without that transfer, access reviews become ceremonial, exceptions linger, and deprovisioning is delayed by uncertainty over who is allowed to approve the cutover. Current guidance from the OWASP Non-Human Identity Top 10 aligns with this reality: ownership is part of control, not an afterthought.

In practice, many security teams only discover the accountability gap after a post-close access review has already stalled or an inherited account has been used outside the acquired organisation’s normal operating model.

How It Works in Practice

The acquiring organisation is typically accountable for the inherited access estate from day one, because it now controls the environment, the monitoring, and the risk decisions. But that does not mean identity and security teams should own every account individually. Each inherited account still needs a named business owner, and that owner should be tied to a specific system, process, or revenue function. The goal is to make every access decision traceable to someone who understands why the access exists and whether it still should.

A workable M&A intake process usually includes:

• Inventory inherited NHIs, human admin accounts, shared logins, and secrets.
• Assign an interim owner for every access item before the migration completes.
• Validate the owner during application rationalisation and data mapping.
• Require explicit approval for retention, reduction, or revocation.
• Log ownership transfer as part of the integration milestone, not after it.

This is where governance and implementation meet. If the acquirer is consolidating identity stores, the control question is not just whether an account authenticates, but whether it still has a legitimate business purpose. NHI teams should use the same discipline described in the Ultimate Guide to NHIs — Key Challenges and Risks: visibility first, ownership second, then lifecycle action. External guidance such as the CISA Identity and Access Management resources supports this pattern by emphasizing accountable access governance and lifecycle control.

These controls tend to break down when the acquisition includes unmanaged service accounts embedded in legacy applications because no one can prove which team still depends on them.

Common Variations and Edge Cases

Tighter ownership controls often increase integration overhead, requiring organisations to balance speed of consolidation against auditability and operational continuity. That tradeoff is especially visible in large deals, carve-outs, and regulated environments where some inherited access must remain temporarily active while systems are disentangled.

There is no universal standard for this yet, but current guidance suggests treating these cases differently:

• Carve-outs: the divesting entity may retain accountability for some identities until separation is complete, but the cutover date and revocation plan must be explicit.
• Shared platforms: ownership can be split between central IT and business application owners, but revocation authority should still be unambiguous.
• Third-party access: inherited vendor accounts need the same ownership transfer, because supplier dependencies often survive the acquisition.
• Orphaned credentials: if no business owner can be identified, the default should be to quarantine, restrict, or revoke after risk review.

The key edge case is incomplete records. When the target company lacks clean identity inventories, security teams should not assume continuity equals legitimacy. That is where the 52 NHI Breaches Analysis is useful as a reminder that inherited trust without ownership discipline is a repeatable failure pattern, not a one-off merger issue. The same caution appears in the OWASP Non-Human Identity Top 10, where lifecycle oversight and access governance are treated as ongoing controls rather than one-time clean-up tasks.

Related resources from NHI Mgmt Group

• Who is accountable when a contractor still has privileged cloud access after departure?
• Who is accountable when third-party access remains active after the task is complete?
• Who is accountable when inherited compromise is discovered after a deal closes?
• Who is accountable when a device still has access after administrators believe it has been revoked?