What are the signs that identity governance is not keeping pace during post-merger integration?

Common warning signs include orphaned accounts, unmanaged shadow IT access, incomplete visibility into local and machine identities, and legacy identities whose ownership or purpose is unknown. If teams cannot explain why an account exists, who owns it, or whether it still needs access, identity controls are already lagging the integration.

Why Post-Merger Integration Exposes Identity Governance Gaps

Post-merger integration is where identity sprawl becomes visible. Two directories, two access models, and two sets of local exceptions often get stitched together faster than ownership can be rationalised. That is how orphaned accounts, duplicate entitlements, and undocumented service identities survive the first integration wave. For practitioners, the real signal is not volume alone; it is the inability to explain why a given identity exists, who is accountable for it, and whether its access still matches business need. NHI Management Group research on the 2024 ESG Report: Managing Non-Human Identities and the State of Non-Human Identity Security shows how often organisations already struggle with visibility and control before a merger increases complexity.

identity governance lags when integration teams focus on account migration, single sign-on, and directory consolidation without first defining ownership, lifecycle, and review responsibilities. The result is that local admins preserve access “just in case,” machine identities remain undocumented, and shadow IT continues operating outside central oversight. Current guidance from the NIST Cybersecurity Framework 2.0 reinforces the need for governance and asset visibility, but merger conditions make those controls harder to maintain. In practice, many security teams discover the gap only after a post-close audit or an access incident reveals that nobody can explain why the account was never removed.

What Weak Identity Governance Looks Like During Integration

During a merger, identity governance is failing when inventory, approval, and review processes no longer match the pace of business change. That usually appears first in the edges of the environment: service accounts owned by teams that no longer exist, contractor access that survived the transaction, local admin accounts with no central record, and OAuth or API connections inherited without a clear business owner. The problem is not just missed cleanup. It is that the organisation has lost the ability to make timely, defensible decisions about access.

Practical checks that usually expose the issue include:

• Accounts exist in the target estate but no owner can explain their purpose.
• Access reviews are happening, but reviewers are approving items they do not recognise.
• Machine identities and secrets are missing from the merger inventory, even though they can still authenticate.
• Inherited applications retain broad entitlements because no one wants to break the integration path.

This is where identity governance should tie back to the control discipline in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially reviewable access assignment, account lifecycle, and system inventory expectations. The operational test is simple: if the merger team cannot produce a current inventory and a named owner for each identity class, the governance model is already behind. These controls tend to break down when the combined organisation inherits multiple identity stores, local exceptions, and undocumented machine-to-machine trust paths because remediation cannot keep up with the volume of exceptions.

Where Integration Teams Commonly Misread the Risk

Tighter integration controls often increase friction, requiring organisations to balance speed of consolidation against the need to preserve business continuity. That tradeoff is real, but it is often mismanaged by treating every access exception as temporary. In practice, “temporary” becomes the default state after Day 1, and the exception list turns into the operating model. Current guidance suggests using merger-specific risk tiers for identities, because not every account deserves the same review depth. A payroll integration account, a plant-floor service identity, and a contractor mailbox do not carry the same failure mode, even if they appear similar in the directory.

Another common blind spot is assuming human identity controls will cover machine identities automatically. They will not. Local scripts, application tokens, API keys, and service principals often bypass the merger playbook because they sit outside standard joiner-mover-leaver workflows. That is where governance breaks down fastest. The second blind spot is confusing “merged” with “managed.” A consolidated directory does not mean access has been validated. If the team cannot map identity to owner, system, and business purpose, the merger has only hidden the problem, not solved it. Organisations should use post-merger reviews to prove that every retained identity still has a defensible reason to exist, not just a historical one.

Related resources from NHI Mgmt Group

• What are the signs that an IAM program is not keeping pace with governance needs?
• What are the signs that AI governance controls are not keeping pace with adoption?
• What are the signs that a third-party integration is failing from a governance perspective?
• Why is it important to integrate identity and data governance?