Security diligence in M&A is now an identity governance issue

At a glance

What this is: This is a 1Password discussion about why security diligence in acquisitions and partnerships has become an identity governance problem, not just a corporate development issue.

Why it matters: It matters because IAM, security, and product leaders need to evaluate how inherited access, technical debt, and partner trust affect post-deal governance and operational risk.

Context

M&A and strategic partnerships create identity governance risk because the buyer or integrator inherits more than a product or revenue stream. It also inherits access paths, technical debt, internal process gaps, and the security posture of another organisation.

In this context, due diligence is not just a legal or finance exercise. For IAM, PAM, and broader security governance teams, the question is whether identity, access, and integration controls can absorb the new relationship without importing unmanaged risk.

Key questions

Q: What breaks in an acquisition when inherited access is not mapped before close?

A: Unmapped inherited access turns diligence gaps into operational risk. Service accounts, privileged roles, partner connections, and undocumented exceptions can persist into the combined environment, making integration slower and exposing the buyer to hidden trust relationships that were never reviewed under its own governance model.

Q: Why do partnerships create access risk even when no acquisition is involved?

A: Deep partnerships often create shared trust through connected systems, delegated rights, and authenticated integrations. That can extend one organisation’s access decisions into another organisation’s environment. When the relationship changes, the access often persists unless someone owns offboarding, monitoring, and revocation. That is why partnership governance has to include lifecycle controls, not just legal terms.

Q: What are the signs that M&A diligence is too shallow for identity governance?

A: Warning signs include undefined ownership for inherited accounts, late discovery of privileged exceptions, missing offboarding plans for duplicate access, and integration timelines that assume security cleanup can happen later. Those symptoms show the transaction was assessed as a deal, not as a living identity environment.

Q: Who should own access cleanup during post-merger integration?

A: Ownership should sit across corporate development, security, engineering, and the business leader responsible for the acquired capability, with one team accountable for the access transition end to end. If ownership is fragmented, identity rationalisation is usually delayed until customer impact or audit pressure forces action.

Technical breakdown

Inherited access and technical debt in M&A

In an acquisition, the buyer inherits the target’s identity estate along with its systems. That can include service accounts, privileged access paths, third-party connections, and undocumented exceptions that were tolerable in the target’s environment but become liabilities after integration. The practical issue is not just what exists on paper, but what access remains active after the deal closes and the systems begin to merge. If those identities are not inventoried and rationalised early, the post-close environment can carry forward hidden trust relationships that undermine governance and complicate containment.

Practical implication: inventory inherited identities and privileged paths before integration decisions are finalised.

Why partnerships turn trust into shared risk

A partnership is not a loose commercial arrangement once systems, users, or data paths are integrated. At that point, one company’s security failure can become the other company’s customer problem, brand problem, and support problem. This is especially true when access is federated, APIs are interconnected, or support workflows cross organisational boundaries. The security model changes from isolated control to shared accountability, which means diligence must assess not only the partner’s controls but also the operational blast radius if those controls fail.

Practical implication: assess partner-facing access and integration points as shared-risk channels, not as ordinary vendor relationships.

Post-close integration is the real governance test

The hardest part of M&A is often not the announcement but the integration phase. Identity decisions made during diligence need to survive product integration, employee retention risk, and changes to control ownership after close. That means access reviews, onboarding and offboarding, privileged role mapping, and customer trust messaging all need to line up before the deal is operationalised. The governance gap appears when teams treat diligence as a pre-close checkpoint instead of the beginning of a lifecycle that extends well into the integration period.

Practical implication: build identity offboarding, access rationalisation, and control ownership into the integration plan before close.

Breaches seen in the wild

• Okta support system breach 2023: A support service account credential saved in a personal Google profile let attackers take HAR files and hijack five Okta customers' sessions.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

M&A security diligence is now an identity governance discipline, not a point-in-time security review. The article’s central point is that acquisitions and partnerships inherit identity, access, and trust relationships along with the business itself. That makes diligence part of the identity lifecycle, because access that is not understood before close will become harder to govern after integration. Practitioners should treat pre-close assessment as the start of governance, not a separate exercise.

Deal risk is increasingly a question of inherited control surface, not just target valuation. A company can buy revenue, technology, and talent, but it also buys every exception, service account, and unresolved access dependency attached to those assets. That is why technical diligence cannot be deferred to remediation after close. The control surface being acquired may be the real constraint on integration speed.

Partnerships now behave like distributed access agreements, which means trust must be engineered, not assumed. Once two organisations connect products, support paths, or customer workflows, the relationship becomes operationally shared. A failure on one side can affect the other side’s brand and customer obligations. Practitioners should evaluate partnerships with the same seriousness they apply to privileged third-party access and federation governance.

Integration is a lifecycle problem: identity offboarding, role mapping, and accountability all shift at once. The article makes clear that the post-close phase is where many deals fail in practice. Retaining key staff, preserving architectural intent, and communicating control expectations to customers all depend on a governance model that extends beyond signing day. The practical conclusion is that M&A readiness belongs in identity programme planning, not only in corp dev.

What this signals

Inherited trust is the hidden control plane in M&A: once systems or support paths connect, the security posture of the acquired or partnered organisation becomes part of the buyer’s operating model. That shifts diligence from a document review to an access and integration exercise, because unresolved identities can become live dependencies on day one.

Dealmakers often talk about product, talent, and revenue, but the identity layer determines whether those assets can be safely operationalised. In practice, the faster a transaction moves, the more important it becomes to know which access paths must be retired, which must be federated, and which must be re-certified before customers feel the change.

For practitioners

• Map inherited identity and access assets before close Build a pre-close inventory of service accounts, privileged roles, partner connections, and other access paths that will survive the transaction. Use that inventory to identify which identities must be reviewed, remediated, or retired as part of integration.
• Treat technical diligence as a deal gate Require security and engineering sign-off for material exposure in the target’s identity and infrastructure posture. If unresolved access or architecture issues would slow integration or increase customer risk, escalate them as transaction risks rather than post-close cleanup.
• Define trust boundaries for partnerships early Document which systems, data flows, support processes, and access routes will be shared with a partner before integration begins. That boundary should determine review scope, logging expectations, and who owns remediation if controls fail.
• Align integration ownership across product, security, and corp dev Assign clear owners for identity rationalisation, customer communication, and privilege cleanup before announcement day. Integration fails fastest when no single team owns the access transition end to end.

Key takeaways

• Acquisitions and partnerships import identity, access, and trust dependencies, so security diligence belongs inside M&A governance.
• The hardest failures emerge after close, when inherited accounts, partner connections, and ownership gaps collide with integration pressure.
• Practitioners need a pre-close access inventory, explicit trust boundaries, and clear integration ownership before the transaction becomes operational.

Key terms

• Inherited Access: Inherited access is permission a tool receives from a connected user, service account, or integration rather than from a purpose-built identity. It often hides privilege expansion because the tool appears lightweight while actually operating under broad, durable entitlements.
• Trust Boundary: A trust boundary is the point where one system’s authority should stop and another system’s authority should begin. For internal automation, weak trust boundaries let monitoring, remediation, and execution share privileges that should have remained separate.
• Identity-led rationalisation: A software optimisation approach that uses identity, usage, and lifecycle data to decide what to keep, remove, or consolidate. It treats access and spend as linked governance problems rather than separate finance and security exercises.
• Post-Close Integration: Post-close integration is the process of combining systems, identities, data, and security operations after a transaction completes. It is a high-risk phase because control mismatches and rushed consolidation can create gaps attackers exploit. Strong integration links remediation, identity alignment, and continuous monitoring across the merged environment.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.