Ownership should sit with security, IAM, and the deal team together, because access decisions affect both business value and technical risk. Corp Dev needs the transaction context, while security needs authority to flag identity exposure, limit inherited access, and enforce the stricter policy model until the merged environment is stable.
Why This Matters for Security Teams
Acquisition access is not a routine joiner-mover-leaver event. The deal team is optimizing for continuity, diligence, and time-to-close, while security is responsible for preventing inherited access from becoming a post-close breach path. That tension matters because the merged identity estate often includes service accounts, API keys, automation tokens, and privileged integrations that were never designed for rapid absorption.
NHI Management Group’s Ultimate Guide to NHIs shows how common this exposure is in practice, including the finding that 97% of NHIs carry excessive privileges and only 5.7% of organisations have full visibility into their service accounts. Those two realities make acquisition governance a control issue, not just a legal or operational one. A buyer can inherit access paths that outlive the transaction logic behind them, especially when the target has weak inventory, no clean offboarding process, or credentials embedded in code and CI/CD systems.
The right owner is therefore a decision-making group, not a single function. Security should own the control standard, IAM should own implementation, and Corp Dev should own business context. In practice, many security teams encounter excessive inherited access only after integration has already started, rather than through intentional pre-close identity review.
How It Works in Practice
Ownership works best when access decisions are split into three layers: business necessity, technical risk, and execution. Corp Dev identifies what must remain available for continuity, security decides what must be isolated or revalidated, and IAM translates that decision into accounts, entitlements, and revocation actions. For non-human identities, that usually means treating every inherited secret, token, certificate, and service account as untrusted until verified.
A practical acquisition workflow usually includes:
- Inventory all known identities before close, including NHIs tied to applications, cloud workloads, CI/CD, and vendors.
- Classify each access path by business criticality and privilege level.
- Apply a default deny posture for inherited non-human access until the owner, purpose, and expiration are confirmed.
- Rotate or re-issue secrets after close, rather than assuming inherited credentials remain safe.
- Use time-bound exceptions for transitional access, with explicit expiry and revocation ownership.
This aligns with the control direction in the OWASP Non-Human Identity Top 10, which emphasizes that unmanaged machine identities and secrets are a common source of privilege sprawl. It also matches the broader guidance in the Ultimate Guide to NHIs — Key Challenges and Risks, where lack of visibility and weak lifecycle discipline create avoidable exposure during transitions. The operational point is simple: acquisition access should be approved once, implemented fast, and revisited continuously until the environment is stable. These controls tend to break down when the target uses undocumented automation or shared credentials because ownership and provenance cannot be reliably reconstructed.
Common Variations and Edge Cases
Tighter access control during an acquisition often increases integration overhead, requiring organisations to balance continuity against the cost of revalidation and temporary downtime. That tradeoff is real, especially when revenue-generating systems or regulated workloads must stay live through the transition.
Best practice is evolving for carve-outs, divestitures, and cross-border deals. In some cases, the acquiring company should not immediately merge identity stores at all. Instead, current guidance suggests maintaining a temporary boundary with separate IAM policy, short-lived credentials, and explicit break-glass approvals until asset ownership and data flows are fully mapped. For highly privileged NHIs, there is no universal standard for this yet, but the safer pattern is to require re-attestation and secret rotation before any production trust is granted.
The main edge case is when the target has no reliable identity inventory. In that environment, the “owner” of access decisions must also own the remediation plan, because approving access without visibility creates a blind spot that security cannot later unwind cleanly. The same applies when third-party vendors hold credentials on behalf of the target, since those relationships can survive the acquisition even when internal users do not.
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 |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Acquisitions inherit unmanaged machine identities and secret sprawl. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions must be reviewed and constrained during M&A. |
| NIST AI RMF | GOVERN | Ownership of access decisions needs clear accountability and oversight. |
Assign governance for acquisition access decisions, approvals, and exceptions before integration begins.
