Who is accountable when acquired systems stay outside identity governance?

Why This Matters for Security Teams

When acquired systems remain outside identity governance, the issue is not just unfinished integration. It is an active control gap: orphaned accounts, inherited admin rights, stale entitlements, and audit evidence that no longer matches reality. NHI Management Group research on lifecycle and audit perspectives shows these gaps are where organisations lose visibility first, then control. The operational risk is compounded when the acquired estate still relies on local admins or unmanaged secrets.

That is why identity owners, IGA teams, and compliance functions remain accountable until the estate is pulled into policy, logging, and review cycles. NIST Cybersecurity Framework 2.0 treats identity as a core governance function, not a one-time project milestone, and NIST SP 800-53 Rev. 5 reinforces that access enforcement and account management must be continuously controlled, not assumed after a transaction closes. In practice, many security teams discover the inherited access sprawl only after a failed audit, a privilege review, or an incident in the newly acquired environment.

For background on how unmanaged identities become recurring exposure, see Ultimate Guide to NHIs and the survey findings in 2024 ESG Report: Managing Non-Human Identities.

How It Works in Practice

Accountability should be defined in the acquisition playbook before system migration begins. The practical question is who owns identity assurance for each environment, what evidence is required, and when the acquired estate is deemed governed. Best practice is to map acquired accounts, service identities, API keys, certificates, and legacy admin paths into a single inventory, then decide which identities are to be merged, remediated, rotated, or retired.

That work usually needs three layers of control. First, establish ownership for every identity class, including system accounts and privileged service identities. Second, enforce policy checkpoints for access review, credential rotation, and logging before any broad production integration. Third, align the evidence trail so internal audit can see when exceptions were approved and when they were closed. NIST CSF 2.0 is useful here because it frames identity governance as ongoing risk management rather than a one-time technical task.

• Inventory every human and non-human identity in the acquired environment.
• Assign an accountable owner for remediation, review, and exception closure.
• Rotate inherited secrets and remove shared or undocumented credentials.
• Require logging, review, and evidence capture before full trust is granted.
• Retire duplicate or unused accounts as part of the integration timeline.

NHIMG’s Top 10 NHI Issues and Ultimate Guide to NHIs — Regulatory and Audit Perspectives both reflect the same pattern: governance fails when teams treat acquisition as an IT conversion rather than an identity-risk transition. These controls tend to break down when the acquired estate includes unmanaged legacy platforms, because identity evidence, ownership, and revocation paths are often missing or inconsistent.

Common Variations and Edge Cases

Tighter identity control often increases integration effort, requiring organisations to balance speed of consolidation against the cost of mapping legacy entitlements and remediating exceptions. That tradeoff is especially visible in carve-outs, partial acquisitions, and regulated environments where business continuity limits how quickly access can be cut or restructured.

There is no universal standard for this yet, but current guidance suggests the accountable party remains the organisation that acquired the estate until governance transfer is complete. In some deals, day-to-day technical ownership may sit with infrastructure or operations teams, while risk acceptance stays with IAM, IGA, or compliance leaders. The key is not where the servers physically sit, but whether a named control owner can prove who has access, why they have it, and when it will be reviewed.

Edge cases often include unmanaged third-party integrations, outsourced admin models, and M&A scenarios where local business units resist central policy. Those situations require explicit exception registers, time-bound remediation plans, and executive sign-off on residual risk. For an industry view of how quickly overprivilege translates into incident exposure, the 2026 Infrastructure Identity Survey reports that 67% of organisations still rely heavily on static credentials despite the risks they pose to autonomous systems.

Related resources from NHI Mgmt Group

• Who is accountable when disconnected applications stay outside identity governance?
• Why is it important to integrate identity and data governance?
• Who is accountable when disconnected apps remain outside identity governance?
• How should IAM teams handle systems that are outside their identity governance tools?