Accountability should sit with the integration owner, identity governance lead, and system owners who can certify access across the merged estate. If responsibility is split between old operating models, revocation and review slow down. The merged organisation needs one accountable process for entitlements, evidence, and exception handling.
Why This Matters for Security Teams
After a merger closes, identity risk does not pause for organisational charts or legal entity changes. Access entitlements, service accounts, privileged roles, and inherited exceptions all remain active until someone owns the cleanup. That is why accountability must be explicit: one integration owner can drive decisions, one identity governance lead can evidence them, and system owners can certify what still needs access. NIST’s Cybersecurity Framework 2.0 is clear that governance and response need named ownership, not shared assumptions.
This is especially important because post-deal environments often contain far more NHIs than teams expect. NHI Management Group notes that NHIs outnumber human identities by 25x to 50x in modern enterprises in the Ultimate Guide to NHIs, which means merger work quickly becomes a control problem, not just a records problem. When identity ownership is ambiguous, revocation stalls, privileged access persists, and audit evidence becomes fragmented across legacy operating models. In practice, many security teams encounter identity exposure only after inherited access has already been used, rather than through intentional post-close review.
How It Works in Practice
The accountable party should be the person or function with authority to coordinate remediation across both legacy organisations. In most deals, that means the integration owner sets the timeline, the identity governance lead runs entitlement decisions, and system owners certify whether access is still required. This is not a committee role. It is a decision path with clear escalation when a business unit, application owner, or former IT team disagrees.
Operationally, the merged organisation should treat identity risk as a workstream with evidence. Current guidance suggests three controls matter most: inventory, certification, and revocation. Inventory establishes what identities exist, including service accounts and API keys; certification confirms who still needs what; and revocation removes access when the business need no longer exists. NHI Management Group’s Top 10 NHI Issues highlights why this is hard in practice: missing visibility, excessive privilege, and weak rotation all compound during transitions. The Ultimate Guide to NHIs also shows why post-merger cleanup must include secrets stored outside vaults, because entitlement review alone does not remove credential exposure.
- Assign one accountable owner for the merged identity program, not one owner per legacy company.
- Map every application and privileged account to a named certifying system owner.
- Track exceptions with expiry dates and documented business justification.
- Verify revocation completion, not just approval, before closing remediation tickets.
Where possible, align the post-close process to the NIST CSF 2.0 govern and protect functions so accountability is measurable, repeatable, and auditable. These controls tend to break down when the integration spans multiple directories, outsourced admins, or applications whose owners no longer exist in the target operating model.
Common Variations and Edge Cases
Tighter identity control often increases short-term operational overhead, requiring organisations to balance speed of integration against the risk of preserving unsafe access. That tradeoff becomes sharper when the acquired company uses different directory services, local admin conventions, or unmanaged NHIs embedded in code and CI/CD pipelines. In those cases, there is no universal standard for exact handoff timing yet, so best practice is evolving around a single accountable process rather than a fixed organisational title.
A common exception is a carve-out or staged TSA environment, where some access must remain temporarily active for continuity. Even then, accountability should not be split. The integration owner still owns the exception register, while system owners certify the minimum access needed and expiry dates. Another edge case is where business units resist revocation because service disruption is feared; here, the evidence burden should shift to the system owner to justify continued access. The real failure mode is usually not lack of policy, but diffused responsibility across inherited teams that each assume someone else will close the gap.
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.OV-01 | Post-merger identity risk needs explicit governance and oversight ownership. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Mergers expose unmanaged NHIs, stale secrets, and unclear ownership. |
| NIST AI RMF | GOVERN | Governance function requires accountable oversight for high-impact operational risk. |
Name one accountable owner for merger identity risk and track closure evidence through governance reviews.
