Accountability should sit with the team that owns identity reconciliation, privileged access cleanup, and offboarding across the combined estate, not with infrastructure teams alone. When ownership is split between business integration and security operations, orphaned identities and unresolved entitlements tend to persist far beyond Day One.
Why This Matters for Security Teams
After a merger closes, identity risk does not disappear with legal completion. It shifts into the messy work of reconciling directories, cleaning up privileged access, and retiring duplicate or orphaned accounts across two estates. That accountability often becomes unclear because business integration teams focus on systems consolidation while security teams focus on control enforcement. The result is a gap where no one owns the full identity lifecycle.
This is where post-close failures usually start: service accounts remain active, stale entitlements survive, and offboarding lags behind business change. NHI Management Group has documented how severe this can become in the Ultimate Guide to NHIs, which notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. That figure matters in mergers because acquired environments often carry hidden, overprivileged identities into the combined estate. Current guidance from the NIST Cybersecurity Framework 2.0 reinforces that governance and risk ownership must be explicit, not implied.
In practice, many security teams encounter identity exposure only after a post-merger audit, incident, or failed decommissioning effort has already surfaced it.
How It Works in Practice
Accountability should be assigned to the function that can actually execute identity reconciliation end to end. In most mergers, that means a named owner spanning identity governance, privileged access management, and offboarding, with escalation paths into integration leadership. Security operations can enforce controls, but it rarely has enough context to decide which identities should survive the merger. Business integration teams may know which applications remain, but not which entitlements must be removed.
A practical operating model usually includes three stages:
- Inventory all human and non-human identities across both organisations, including directory objects, API keys, service accounts, and admin roles.
- Map each identity to a business owner, application owner, and technical custodian before cutover.
- Revoke, rotate, or reissue credentials only after ownership and necessity are confirmed.
This is also where evidence from NHIMG research is useful. The 52 NHI Breaches Analysis shows that identity-related exposure is rarely a one-time failure; it tends to persist when cleanup responsibilities are split. The broader Top 10 NHI Issues also highlights the operational drag created by poor visibility and weak lifecycle control. For post-merger governance, that means the accountable team needs authority to approve removals, force remediation deadlines, and verify that privileged access has been reduced in the combined environment.
These controls tend to break down when the acquired estate uses unmanaged secrets, shadow automation, or application owners who cannot be reached before Day One.
Common Variations and Edge Cases
Tighter post-merger identity control often increases coordination overhead, requiring organisations to balance speed of integration against the risk of leaving exposed access in place. That tradeoff becomes more pronounced when the acquired company has different IAM tooling, multiple directories, or heavy use of service accounts and embedded secrets.
There is no universal standard for this yet, but current guidance suggests assigning one accountable owner for the combined identity cleanup program, not separate owners per domain. In regulated environments, that owner may sit in security governance; in larger integrations, it may sit in an identity center of excellence with delegated authority from both business and security leadership. The key is that accountability must cover reconciliation, privileged access review, and offboarding together, because isolated ownership creates gaps.
Edge cases also matter. A carve-out may require the seller to retain limited access for a transition period, but that should be time-bound and reviewed under a formal exception process. Similarly, acquired third-party integrations may carry hidden credential dependencies that are not visible in standard directory reviews. NHI Management Group’s research in the Ultimate Guide to NHIs notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which is exactly why mergers amplify risk when ownership is unclear.
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 | GV.RM-06 | Merger identity risk needs explicit governance ownership and risk ownership. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Post-merger identity cleanup depends on finding all NHIs and their owners. |
| NIST AI RMF | AI RMF governance principles apply to accountability for identity lifecycle decisions. |
Use governance controls to define accountable owners for reconciliation, access cleanup, and offboarding.
