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

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.

Why This Matters for Security Teams

After an acquisition, the hardest part is usually not getting accounts created. It is deciding which identity system is authoritative for which population, how access is matched across both environments, and how to keep approvals and removals from drifting into manual exceptions. Without that clarity, teams end up with duplicate identities, orphaned entitlements, and inconsistent revocation timing.

This is especially important because identity sprawl is often where post-merger risk shows up first. NHI Management Group notes that only 5.7% of organisations have full visibility into their service accounts, and 92% expose NHIs to third parties in some form, which shows how easily access can fragment across systems. That risk maps directly to acquisition scenarios, where human and non-human access models often collide with little standardisation. The NIST Cybersecurity Framework 2.0 is useful here because it emphasises governance, asset visibility, and access control as operational disciplines rather than one-time projects.

In practice, many security teams only discover the governance gap after a terminated employee, vendor, or admin still has live access in the legacy directory.

How It Works in Practice

The practical answer is to preserve separate identity providers while creating one access governance layer above them. That means security defines the source of truth for each identity population, then uses deterministic matching rules to tie records together across directories, HR systems, and SaaS applications. The objective is not to unify every directory immediately. It is to make provisioning, approval, certification, and deprovisioning follow the same policy even when the platforms remain separate.

A workable operating model usually includes:

• Authoritative ownership by population, such as one IdP for employees and another for contractors or a newly acquired subsidiary.
• Deterministic identity matching using stable fields such as employee ID, immutable email history, or validated external subject identifiers.
• Unified joiner-mover-leaver workflows so access changes are processed once and propagated to both systems.
• Central review and attestation so managers and app owners certify access through one process, not two disconnected admin consoles.
• Logging and evidence retention that show who approved access, where it was provisioned, and when it was removed.

That approach aligns with the control themes in the OWASP Non-Human Identity Top 10, especially around over-privilege, secret lifecycle, and ownership. It also fits the lifecycle guidance in the Ultimate Guide to NHIs, which stresses that offboarding and revocation must remain consistent even when the enterprise has multiple control planes. For acquisition work, current guidance suggests starting with the highest-risk apps, then extending the same matching and review logic to lower-risk services once identity quality improves. These controls tend to break down when one IdP uses mutable identifiers and the other relies on local-only usernames, because deterministic matching becomes unreliable and manual exceptions multiply.

Common Variations and Edge Cases

Tighter governance often increases integration overhead, so organisations have to balance consistency against the reality of two independent operating models. That tradeoff is most visible when the acquired company has regulatory obligations, a different directory schema, or heavily customised application provisioning that cannot be migrated quickly.

Best practice is evolving, but most programmes handle edge cases in one of three ways: keep separate directories with a shared governance layer, federate one IdP into the other for selected apps, or gradually converge populations over time. There is no universal standard for this yet, so the choice depends on audit scope, separation-of-duties requirements, and how much trust exists in identity data quality. The key is to avoid treating “temporary coexistence” as permission to let approval chains, role mappings, and offboarding logic diverge.

The State of Non-Human Identity Security highlights how low confidence and poor visibility are common even before an acquisition adds complexity, and that makes conservative governance more important, not less. For teams aligning to broader control frameworks, NIST Cybersecurity Framework 2.0 supports a phased approach, while NHI-specific governance in the Top 10 NHI Issues reinforces the need to keep ownership, rotation, and revocation explicit. The hardest cases are acquired environments with overlapping admins and legacy service accounts, because hidden privilege can survive long after the directory merger discussion is finished.

Related resources from NHI Mgmt Group

• How should security teams govern DNS when it supports identity and access flows?
• How should security teams govern Slack access like other high-value identity systems?
• How should security teams govern non-human identities that have persistent access?
• How should security teams govern API keys used for generative AI access?