Accountability should sit with the organisation that now owns the combined control environment, but business and technical owners must remain explicit for each identity domain. The merged entity should define who approves privileged access, who owns service account lifecycle actions, and who verifies compliance evidence. Clear accountability prevents gaps when responsibilities shift during integration.
Why This Matters for Security Teams
After a security platform merger, access and entitlement decisions are rarely just an IAM exercise. The merged organisation inherits overlapping service accounts, API keys, admin roles, and approval paths, and each can map to a different business owner or technical steward. If accountability is unclear, privileged access can persist long after integration work is complete.
This is especially risky for non-human identities, where identity sprawl and weak lifecycle governance often outlast the merger itself. NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, while 97% of NHIs carry excessive privileges. That combination creates a predictable governance gap unless ownership is explicitly reassigned during transition. The Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10 both stress that entitlement control fails when responsibility is implied rather than assigned.
In practice, many security teams discover ownership gaps only after a stale privileged account is used during integration, rather than through intentional entitlement review.
How It Works in Practice
Accountability should move to the organisation that now operates the combined control environment, but the operating model must still distinguish business approval from technical administration. The merged entity needs a clear decision chain for privileged access, service account lifecycle actions, and evidence collection. That means naming who approves access, who implements changes, and who validates that the change met policy.
A practical merger playbook usually includes:
- A single entitlement register for both legacy environments, with one owner per account, token, or API integration.
- Explicit approval authority for high-risk access, especially PAM paths and break-glass roles.
- Lifecycle ownership for non-human identities, including rotation, offboarding, and revocation.
- Evidence ownership for audits, so compliance artifacts are produced from the merged control plane rather than by informal handoffs.
That model aligns with NIST control expectations for access enforcement and auditability in NIST SP 800-53 Rev 5 Security and Privacy Controls, and it is reinforced by NHIMG guidance on lifecycle governance in the Ultimate Guide to NHIs — Key Challenges and Risks. For merged environments, the main objective is not just to merge directories, but to merge decision rights with traceable accountability.
Where this breaks down is in hybrid estates with disconnected vaults, multiple ticketing systems, and duplicated admin teams, because no one can prove which owner has final authority over a given entitlement.
Common Variations and Edge Cases
Tighter entitlement governance often increases integration overhead, requiring organisations to balance merger speed against control clarity. That tradeoff becomes visible when legacy business units resist central approval, or when one platform still needs local emergency access while the other has already moved to standardised governance.
Best practice is evolving, but current guidance suggests three common variants. First, if one company is legally acquiring the other, accountability usually follows the surviving control owner. Second, if two entities are operating under a transitional services arrangement, accountability may remain split temporarily, but only with written RACI-style ownership and expiry dates. Third, if a third-party integrator is operating privileged tooling, that party can administer access, but it should not own approval authority or compliance sign-off.
For NHI-heavy mergers, the most important edge case is service account ownership. A platform may migrate while the identity still authenticates against the old vault, which is why entitlement decisions must be tied to runtime control, not to the application team that built the original integration. The NHIMG State of Non-Human Identity Security highlights why this matters: lack of credential rotation and over-privileged accounts remain leading causes of compromise. In these cases, accountability fails when merger teams assume migration equals ownership transfer.
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 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Merged estates often hide excessive or unclear NHI entitlements. |
| CSA MAESTRO | GOV-02 | Merger governance needs explicit accountability for agent and workload access. |
| NIST AI RMF | GOVERN | Autonomous or semi-autonomous systems need accountable oversight after consolidation. |
| NIST CSF 2.0 | PR.AC-1 | Identity and access policies must be owned and enforced after merger. |
| NIST Zero Trust (SP 800-207) | ID | Zero Trust requires clear identity authority across merged platforms. |
Assign governance ownership for access decisions, exceptions, and audit evidence in the merged environment.
Related resources from NHI Mgmt Group
- Who should be accountable when app access decisions affect security, compliance, and spend?
- How should security teams evaluate identity security platform consolidation after a major product announcement?
- How should security teams implement role mining in identity governance without over-automating access decisions?
- Who is accountable when access review scoping decisions create audit gaps or miss high-risk roles?
