How should security teams assess identity risk during an acquisition or merger?

Why This Matters for Security Teams

Mergers and acquisitions compress identity risk into a short diligence window, which is exactly when teams are least likely to have clean data. The main failure is not just missing accounts, but missing the relationships that let those accounts keep acting after close: inherited admin roles, shared service credentials, stale API keys, and third-party access paths. That makes identity review a transaction-risk issue, not an IT housekeeping task.

Current guidance suggests aligning the review to both the target’s operating model and the acquirer’s control baseline, using the NIST Cybersecurity Framework 2.0 as a practical backbone for inventory, access control, and recovery planning. NHIMG’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which is why transaction teams often discover scope problems late.

In practice, many security teams encounter identity exposure only after application cutover or vendor consolidation has already expanded access paths.

How It Works in Practice

Identity risk assessment during a merger works best when it is treated as a structured inventory and entitlement exercise, not a one-time questionnaire. Start by mapping all identities that can authenticate, authorize, or automate actions: employees, contractors, privileged users, service accounts, workload identities, API keys, certificates, and externally managed integrations. Then trace where each identity is used, who owns it, how it is authenticated, whether it is shared, and what business process breaks if it is revoked.

For non-human identities, the critical questions are whether the credential is long-lived, whether it has excessive privilege, and whether it is tied to a secrets manager or sitting in code, config, or CI/CD. NHIMG research in the 52 NHI Breaches Analysis and Top 10 NHI Issues shows why this matters: hidden NHI paths are often the fastest route from inherited access to post-close compromise.

• Build a pre-close identity register with owners, privilege level, TTL, and last-use evidence.
• Classify access by business criticality, not just by directory group or app name.
• Review dormant accounts, shared secrets, orphaned integrations, and external service providers.
• Validate that termination and rotation processes work before Day 1, not after.

For transaction planning, use zero trust and identity governance principles to decide what must be reauthenticated, reissued, or revoked immediately after signing. Where possible, require just-in-time elevation, separate admin domains, and step-up verification for any identity that would survive the merger boundary. These controls tend to break down when the target relies on embedded secrets in legacy applications because there is no reliable ownership trail or rotation mechanism.

Common Variations and Edge Cases

Tighter identity scrutiny often increases diligence cost and can slow deal execution, so organisations must balance speed against the risk of inheriting unbounded access. That tradeoff is especially acute in carve-outs, distressed acquisitions, and cloud-heavy targets where ownership boundaries are unclear and documentation is incomplete.

There is no universal standard for this yet, but current guidance suggests treating certain patterns as high risk by default: shared root credentials, unmanaged third-party access, long-lived tokens with no rotation evidence, and cross-tenant admin relationships. These are the cases where a clean directory export can still hide material exposure.

Teams should also watch for environments where identity and workload boundaries are blurred. In CI/CD, SaaS-to-SaaS integrations, and managed service ecosystems, the acquirer may inherit machine-to-machine access that is invisible to traditional IAM reviews. That is why the Ultimate Guide to NHIs is useful for post-close planning: identity sprawl is usually wider than the transaction team expects, and revocation gaps can persist long after Day 1.

Related resources from NHI Mgmt Group

• How should security teams handle identity verification during login for regulated applications?
• How should security teams assess a vendor’s ownership claims during due diligence?
• How should security teams govern reusable identity credentials across blockchains?
• How should security teams connect fraud monitoring with identity governance?