M&A identity complexity is reshaping access governance models

At a glance

What this is: This is an analysis of how mergers and acquisitions create multi-identity-provider access governance problems and why orchestration matters more than forced standardisation.

Why it matters: It matters because IAM, IGA, and PAM teams must govern users, groups, and entitlements across multiple identity systems without breaking access during integration.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read Opal Security's analysis of M&A access management across identity systems

Context

Mergers and acquisitions create an identity governance problem as much as a business integration problem. When two organisations keep separate identity providers, email namespaces, and entitlement models, access decisions become harder to resolve, review, and audit across the combined estate.

The core issue is not simply technical integration. IAM and IGA teams have to preserve operational continuity while avoiding duplicate identities, inconsistent attributes, and fragmented approval paths. That makes access governance across multiple sources of truth a standing programme issue, not a one-time migration exercise.

This is where lifecycle and entitlement governance become more important than platform standardisation alone. A practical M&A identity model has to support ongoing access reviews, cross-system identity resolution, and controlled coexistence while the organisation decides what, if anything, should eventually be consolidated.

Key questions

Q: How should security teams govern access when two companies keep separate identity providers after an acquisition?

A: Security teams should govern access with a clear source-of-truth model, deterministic identity matching, and unified review workflows. The goal is not to eliminate every directory immediately. It is to make provisioning, approvals, and deprovisioning consistent across systems while preserving which platform owns each user population and entitlement.

Q: Why do mergers and acquisitions make identity governance harder for IAM teams?

A: M&A introduces duplicate identities, inconsistent attributes, and fragmented approval paths across multiple directories and applications. IAM teams must keep access working while the organisation operates several identity systems at once, which means governance depends on correlation, ownership, and lifecycle control rather than a single global directory.

Q: What do security teams get wrong about standardising identity platforms after an acquisition?

A: The common mistake is assuming immediate standardisation is the safest path. In practice, forced migration can break workflows, create audit gaps, and delay governance. A better approach is to preserve operational continuity first, then consolidate only where the business can tolerate the change.

Q: Who is accountable for access reviews when users exist in multiple identity systems?

A: Accountability should remain with the organisation that owns each entitlement and lifecycle event, even when the person appears in more than one directory. Reviews should be unified, but the source system that granted access must remain visible so remediation, offboarding, and audit evidence stay traceable.

Technical breakdown

Multiple identity providers create conflicting sources of truth

In an acquisition, each company often keeps its own identity provider, directory, and application permissions for a period of time. That creates overlapping sources of truth for the same person, especially when email addresses, usernames, and authoritative attributes do not match. Access governance then depends on identity resolution logic that can map one person across systems without collapsing distinct administrative domains. The hard part is not just syncing accounts. It is preserving which system owns which attributes, entitlements, and lifecycle events while still allowing a single governance view across the merged environment.

Practical implication: define which identity systems remain authoritative for each population before attempting cross-system access governance.

Why hub-and-spoke and multi-source models behave differently

A hub-and-spoke model centralises governance through one primary authority and pushes downstream provisioning into acquired systems. A multi-source model treats several directories as peers and resolves conflicts through policy rather than hierarchy. Both can work, but they produce different audit, review, and offboarding patterns. The first simplifies oversight but can force integration pressure. The second preserves autonomy but demands stronger conflict resolution and identity correlation rules. The architectural choice determines how quickly access decisions can be made and how much manual reconciliation the programme will need.

Practical implication: choose the operating model based on integration horizon, not on an assumed need for immediate standardisation.

ABAC in M&A depends on tag isolation, not attribute merging

Attribute-based access control becomes unreliable when two organisations use the same attribute names differently or store them in different systems. If engineering, contractor, or clearance labels are merged too aggressively, policies can grant access on the wrong basis. A safer pattern is to preserve source-specific attribute namespaces and evaluate them separately. That keeps access decisions tied to authoritative context rather than flattened metadata. In M&A environments, ABAC succeeds when the control plane respects the boundaries between systems instead of pretending they do not exist.

Practical implication: keep source-specific attributes separate so access policies do not inherit bad metadata from one directory into another.

NHI Mgmt Group analysis

Architectural diversity is now the default security condition in M&A. The article shows that every acquisition introduces another identity provider, another directory model, and another set of access rules that cannot be erased overnight. The assumption that one corporate standard can absorb every acquired environment quickly is increasingly unrealistic. Practitioners should treat heterogeneity as a persistent operating state, not a temporary exception.

Cross-system identity resolution is an access governance control, not a convenience feature. When the same person exists in multiple directories with different identifiers, review, approval, and audit processes can no longer rely on a single record. That means identity correlation becomes part of the control plane for IAM, IGA, and lifecycle governance. The practical conclusion is that merged environments need deterministic mapping rules before they need migration projects.

ABAC fails when attribute meaning is flattened across organisational boundaries. A department tag, contractor flag, or clearance attribute is only useful if its source and semantics remain intact. Once acquisition teams normalise everything into a single shared namespace too early, policies become brittle and can produce false grants. The field lesson is that access policy design must preserve source authority instead of forcing premature semantic uniformity.

M&A security exposes a lifecycle problem disguised as an integration problem. Access does not just need to be provisioned across systems. It needs to remain reviewable, revocable, and attributable as people move between parent, subsidiary, contractor, and legacy populations. That makes lifecycle governance the real test of whether the combined identity architecture is manageable. Practitioners should measure whether access can still be governed after the deal closes, not only whether the integration succeeded.

Identity blast radius is the concept this article sharpens. Every additional identity platform expands the number of places where access can drift, duplicate, or outlive business need. The question is no longer whether the enterprise can standardise everything, but how much governance risk it accepts while the systems remain distributed. Security teams should design for containment first and consolidation second.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
• Cross-system lifecycle control becomes easier to prioritise after reading NHI Lifecycle Management Guide, which covers provisioning, rotation, offboarding, and visibility.

What this signals

Identity blast radius: the combined environment becomes more fragile when every acquisition adds another directory, approval path, and entitlement model. That fragility is not solved by trying to erase heterogeneity; it is reduced by making correlation, review, and offboarding explicit programme controls. Teams that already struggle with service-account visibility should treat multi-IDP M&A as a multiplier on the same governance problem.

Because 97% of NHIs carry excessive privileges, many acquired environments arrive with entitlement sprawl already embedded in them. That matters for M&A programmes because the integration phase can inherit over-privileged accounts before security teams even finish mapping systems. The practical response is to make entitlement reduction part of the acquisition playbook, not a post-integration cleanup task.

Teams operating under NIST Cybersecurity Framework 2.0 should align merged identity oversight to the identity and access functions first, then work outward to detect and respond. The control question is whether the combined estate can still answer who has access, why they have it, and how quickly it can be withdrawn when business need changes.

For practitioners

• Define source-of-truth ownership by population Document which identity provider owns employees, contractors, subsidiaries, and legacy accounts before any integration work begins. Use that ownership model to drive provisioning, deprovisioning, and approvals across systems.
• Build cross-directory identity matching rules Create deterministic correlation logic for duplicate people, including email aliases, secondary usernames, and merged employee records. Test the rules against real acquisition data before relying on them for reviews or access decisions.
• Preserve attribute namespaces across systems Keep source-specific tags and attribute semantics separate so access decisions do not inherit collisions from different directories. Apply policy to the authoritative attribute source rather than flattening metadata too early.
• Run unified access reviews across all connected systems Review a person’s access holistically across parent and acquired identity providers, including temporary elevations, group memberships, and direct grants. Reconcile review findings against the actual source system that issued each entitlement.

Key takeaways

• M&A turns identity governance into a multi-system correlation problem, not just an integration project.
• Access reviews, attribute ownership, and offboarding need to work across every surviving identity provider in the combined organisation.
• The right question is whether the enterprise can still govern access coherently while architectural diversity remains in place.

Key terms

• Source Of Truth: The system that owns authoritative identity data for a specific population or attribute. In M&A, different directories may remain authoritative for different groups, so governance depends on clearly separating ownership rather than forcing a single global record too early.
• Identity Resolution: The process of determining that two or more records refer to the same person or entity. In multi-IDP environments, it is a governance control as much as a data task, because access reviews and deprovisioning depend on accurate matching across systems.
• Attribute-Based Access Control: An access model that grants or denies permissions based on attributes such as department, role, or clearance. In acquisition scenarios, it only works well when the source and meaning of each attribute remain intact across identity systems.
• Identity Blast Radius: The amount of governance risk created when access, identity data, and entitlements are spread across multiple systems. The more directories and approval paths that exist, the more places access can drift, duplicate, or survive longer than intended.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Opal Security: Scaling Security through M&A and multi-IDP access management. Read the original.