When Systems Marry in Haste: The Identity Reckoning After an Acquisition
Photo: Solomon203, CC BY-SA 4.0, via Wikimedia Commons
The deal closes on a Friday. By Monday, integration teams are mapping finance systems, reconciling customer contracts, and drafting organization charts. Identity is usually somewhere near the bottom of the list, filed under IT cleanup. That ordering is understandable. It is also dangerous.
When two enterprises merge, their identity systems collide. Directories overlap. Accounts duplicate. Contractors from the acquired company retain access to shared applications. Service accounts created for legacy workflows continue to run. Privileged accounts exist without a clear owner. Verification standards differ from one side to the other, and no one can say with certainty which identities were checked rigorously and which were grandfathered in.
The result is a quiet form of credential chaos. It rarely announces itself as a security incident. It appears as an integration delay, a help desk ticket, or an access review that cannot be completed because the data is incomplete. Then, months later, an attacker logs in through an orphaned account or a trust relationship that no one remembered to close.
The Deal Closes, the Credentials Remain
Acquisitions create a temporary trust bridge between two organizations. Employees need access to each other's systems. Shared folders are opened. Email trusts are established. Single sign-on may be federated before the directory is fully reconciled. Every bridge is a convenience, and every convenience is a potential path for lateral movement.
The risk is compounded by asymmetry. The acquirer may have a mature identity program with multifactor authentication, privileged access management, and regular reviews. The acquired company may have a lean IT team, local administrator accounts, undocumented service accounts, and a password vault that only one departed employee understood. The integration team inherits all of it, often without a complete inventory.
Why Identity Becomes IT Cleanup
M&A integration projects are measured by synergy, cost savings, and speed. Identity work is measured by tickets closed and accounts migrated. That framing turns a security risk into a housekeeping task. The project plan asks whether accounts have been consolidated, not whether every credential can be traced to a verified person or a documented non-human owner.
There is also an ownership gap. HR owns employee records. IT owns directories. Security owns monitoring. Payroll owns bank details. During a merger, those functions may report through different leaders, follow different timelines, and use different definitions of verification. No single team is accountable for the identity of the combined enterprise.
Warning Signs of Hidden Verification Gaps
- The combined organization cannot produce a complete inventory of accounts, service accounts, and privileged access across both entities.
- Duplicate identities exist for the same person, with different verification status and different permissions.
- Shared accounts remain active because no one can determine who uses them.
- Local administrator accounts from the acquired company survive integration without review.
- Multifactor authentication standards differ by business unit or legacy application.
- Contractors and temporary workers from the acquired company retain access after their sponsors leave.
- Service accounts have no documented owner, purpose, or expiration date.
- Background check and identity verification standards were not compared before integration.
A Post-Merger Identity Checklist
- Conduct identity due diligence before close, not after the first access review fails.
- Inventory human and non-human identities across both organizations, including privileged, shared, and dormant accounts.
- Assign a named owner to every non-human identity and every privileged account.
- Suspend dormant and orphaned credentials before merging directories.
- Establish a single verification baseline for employees, contractors, and third parties.
- Replace shared credentials with scoped, short-lived cryptographic identities where feasible.
- Record every identity creation, permission change, and deprovisioning event in a tamper-evident audit log.
- Monitor cross-domain access during the transition and review trust relationships weekly.
- Revalidate identity after any material change, including role changes, bank detail updates, and privilege escalation.
Building a Shared Source of Truth
A blockchain-based identity layer offers a practical answer to the merger problem: a shared, verifiable source of truth that both organizations can trust without depending on one side's directory. Verifiable credentials can bind an identity to its issuer and its verification history. Decentralized identifiers can reduce duplication across domains. Immutable audit logs can show when access was granted, changed, or revoked, even when the underlying systems remain separate.
The goal is not to merge every directory on day one. It is to create a trustworthy identity record that survives the integration. When the next acquisition arrives, the enterprise should be able to answer a simple question: who and what can act inside our systems, and on whose authority? If that question cannot be answered, the deal is not fully closed.
