the acquisition gave us 40 new admins

A 500-person SaaS company acquired a 120-person competitor in early 2025. The transaction closed in March. The integration plan was thoughtful on paper. Engineering systems would be unified over nine months. Sales would merge in phase two. HR would consolidate to one HRIS by Q4. The customer base would be migrated to the acquiring company’s platform over eighteen months.

The identity integration plan was three lines long. “Provision acquired employees on the acquiring company’s SSO. Maintain acquired company’s systems for six months during transition. Retire acquired company’s systems by Q4.”

In October, eight months after close, the security lead at the combined company ran a full identity audit. The findings were as follows. The acquired company’s Google Workspace still existed, with 120 accounts still active. The acquired company’s Active Directory still existed, with 180 accounts active (including former employees who had left before the acquisition but whose accounts had never been cleaned up). The acquired company’s Okta tenant still existed, with 45 applications still federated. The acquiring company’s Okta tenant had been extended to cover the acquired employees, with 120 accounts active there. The cross-linked access between the two environments was a graph that nobody could fully draw. Approximately 40 people across the combined company had administrative access to systems they didn’t know existed, because those systems came over from the acquisition and nobody had explicitly granted or denied the access, it had simply inherited forward.

This pattern repeats across most M&A transactions. The deal closes. The integration plan focuses on business systems. The identity integration happens in the background, imperfectly, and leaves artifacts that persist for years.

This essay is about those artifacts. What they are, why they show up, why they rarely get resolved, and what a better M&A identity integration looks like.

the acquisition is an identity event the size of the target company

Most companies treat an acquisition as a business event. Financial models get updated. Product roadmaps get merged. Go-to-market plans get integrated. HR systems get consolidated on a quarterly timeline.

From an identity perspective, an acquisition is functionally equivalent to hiring the entire target company as new employees, plus inheriting the entire target company’s SaaS footprint, plus absorbing the target company’s vendor relationships, plus taking on the target company’s non-human identities, plus assuming responsibility for the target company’s departed-but-not-deprovisioned accounts.

The identity work required is at least as large as the business integration work. It is almost never resourced at that scale. A typical M&A integration team has engineering, product, finance, HR, and operations representation. Identity is either subsumed into IT, which is usually two people in mid-market, or treated as part of HR, which handles the employee-level provisioning but has no capacity to handle the system-level integration.

The asymmetry between the size of the identity problem and the resources allocated to solving it produces the pattern you see consistently. Business integration: slow but deliberate. Identity integration: partial and abandoned.

the two IdPs problem

The cleanest case of M&A identity integration is when both companies run on the same identity provider, both on Okta, both on Entra, both on Google. In that case, the integration is roughly a matter of merging groups and populating the new users.

Most acquisitions don’t have this. The acquiring company is on one IdP, the acquired company is on another. Sometimes the acquired company is using multiple IdPs for historical reasons. Sometimes the acquired company never consolidated on one.

The default during the transition period is to run both IdPs. Acquired employees authenticate to acquired systems through the old IdP. Acquiring employees authenticate to acquiring systems through the new IdP. Where cross-access is needed, guest accounts or secondary identities get provisioned in one environment or the other.

This arrangement is supposed to be temporary. In practice, it persists for twelve to thirty-six months, depending on how ambitious the consolidation plan was and how often the plan slipped. During that period, every identity decision is ambiguous. Which IdP should own this user? Which system is canonical? If a user is in both IdPs, what’s the source of truth?

The ambiguity doesn’t resolve itself. It resolves when someone explicitly does the work to migrate accounts, re-federate applications, and retire the old IdP. That work is painful enough that it rarely finishes on the original timeline. Some companies simply stop trying. The old IdP continues to exist, with an increasingly stale but non-empty account list, managed by increasingly fewer people.

Five years after the original acquisition, the old IdP is an archaeological artifact that only a handful of people know still exists. It federates a dozen legacy applications that nobody has migrated. It authenticates a hundred accounts that nobody has reviewed. It is a security exposure that shows up in no dashboard, because nobody is monitoring it.

what arrives with an acquired company

• a second identity providerwith its own admins and policies
• its SaaS stackoften overlapping with yours
• admin accountsgranted for reasons nobody on your side knows
• service accountsrunning jobs nobody has mapped
• OAuth grantsapps connected by people who have since left
• cross-federation trustset up quickly during the integration

needs a decisionusually handled

inherited permissions without inherited context

When employees from an acquired company get provisioned into the acquiring company’s systems, they typically come with a set of permissions that approximate what they had at the acquired company. The translation is imprecise. A Senior Engineer at the acquired company maps to a Senior Engineer role at the acquiring company, which has a default permission template. The template is applied. The employee is productive on day one of the integration.

What’s lost in the translation is the context. The acquired Senior Engineer had specific permissions at the acquired company because of specific projects they worked on, specific teams they supported, specific historical grants. Those specific permissions don’t carry over. What carries over is the role label, and the role template of the acquiring company fills in the rest.

This sounds like a feature, starting fresh on the acquiring side, but it produces a specific problem. The acquired employee, still working with their old team, still accessing the old company’s systems through the transitional arrangement, now has two sets of access. The old set, still intact on the old systems. The new set, granted by the template on the new systems.

Over the transition period, the employee accumulates access on both sides. The old access is supposed to be retired when the systems are decommissioned. The decommissioning timeline slips. The old access persists. The new access is granted on day one. The combined footprint is larger than either side would have granted on its own.

Eighteen months in, the employee has access to both the old collaboration tools and the new ones, both the old code repositories and the new ones, both the old customer records and the new ones. When the old systems are finally retired, if they’re ever retired, the access in those systems may or may not be cleanly removed. In most cases, the retirement process turns off the systems without explicitly revoking access in them, because turning off the system is assumed to revoke access. For systems that are genuinely decommissioned, this is true. For systems that get “retired” by being migrated into a holding state for reference, access persists.

the acquiring company inherits the acquired company’s problems

The acquired company, on the day of the acquisition, has whatever identity problems it had before the acquisition. If the acquired company had not deprovisioned departed employees well, the acquiring company inherits those accounts. If the acquired company had accumulated OAuth grants, long-lived tokens, and service accounts with unclear ownership, the acquiring company inherits all of it.

This is a non-trivial inheritance. A mid-market company that has been running for ten years has an identity mess of its own making. When that company is acquired, the mess becomes the acquirer’s mess. The acquirer, which may have been investing in its own identity hygiene, suddenly owns a parallel identity environment with none of the hygiene.

Due diligence in M&A typically covers financials, customer contracts, product technology, key personnel, and legal exposure. It rarely covers identity state. The typical due diligence question is “does the target company use SSO?”, answered yes or no. The follow-up question, “what is the actual state of the target’s identity graph?”, is not asked, because asking it and acting on the answer would require a level of access to the target’s systems that M&A processes don’t provide pre-close.

The consequence is that the acquirer learns about the inherited identity problems post-close, often months post-close, when somebody runs an audit and discovers what was actually there.

Specific items that typically surface in these post-close audits. Accounts for former employees of the target company dating back years, never cleanly deprovisioned. Service accounts with unclear ownership and elevated privileges. SaaS subscriptions paid for by the target company that nobody at the acquirer knew about. Third-party integrations with standing access to target systems that nobody can identify. Contractor and partner access arrangements that pre-date the acquisition and have no current business sponsor.

These items are all exploitable. None of them were disclosed during due diligence, because nobody at the target company had a list of them, and the acquirer’s diligence process didn’t know to ask.

the divestiture case is worse

The inverse pattern, when a company divests a business unit, has a similar shape with worse outcomes.

When a business unit is spun off or sold to another buyer, the employees, systems, and data of that unit need to be cleanly separated from the parent company. The separation is usually called a Transition Services Agreement (TSA), which specifies what the parent continues to provide to the divested unit for a period of time.

TSAs create long transition windows during which the divested unit continues to use the parent’s systems, but as an external entity. The identity arrangements during this period are ad hoc. Sometimes the parent maintains the divested employees as guests in the parent’s IdP. Sometimes the divested unit stands up its own IdP with cross-connections to the parent. Sometimes the divested unit gets a copy of the parent’s systems, exported and migrated.

None of these arrangements is clean. The divested unit’s employees, while they remain on parent systems, have varying levels of residual access to parent data. The parent’s employees, during the transition, may have access to divested unit data that they should no longer have. The cross-access during the TSA is hard to audit and even harder to cleanly terminate.

When the TSA ends, the theoretical state is that the divested unit is fully independent and the parent no longer has any identity cross-over. The actual state is that artifacts remain. Old accounts exist in both IdPs. Old OAuth grants persist. Legacy integrations continue. The cleanup that was supposed to happen at TSA end was not explicitly planned, so it mostly doesn’t happen.

A parent company that has done three divestitures over five years typically has residual identity connections to all three divested entities. Some of those entities may no longer exist as separate companies. The residual connections continue regardless.

what a clean M&A identity integration looks like

The pattern that works is resourced differently from the default.

A dedicated identity integration workstream, staffed with people whose only job for the duration of the integration is identity. Not a side project of an IT generalist. Not a subtask of HR integration. A named team with named leadership and a timeline separate from other workstreams.

A pre-close identity discovery phase as part of due diligence. The discovery doesn’t require live access to target systems. It requires questionnaires, document reviews, and interviews with the target’s IT and security leadership. The goal is to produce an inventory of the target’s identity footprint, including IdP usage, SaaS footprint, service accounts, and known issues. This inventory feeds the integration plan.

A day-one integration plan with a time-bound scope. The first ninety days focus on consolidating authentication and establishing canonical IdP ownership. Months four through nine focus on application federation consolidation. Months ten through eighteen focus on decommissioning legacy systems and cleaning up residual access.

A decommissioning protocol that explicitly includes access revocation. When a legacy system is retired, the retirement plan includes a step for explicitly revoking all accounts and grants in that system before turning it off. This sounds redundant, the system is being turned off, but the explicit revocation produces audit trails and ensures that any cloud-based remnants (snapshots, backups, read-only archives) don’t retain access.

An exit audit at the end of the integration. The audit verifies that the acquired company’s IdP is fully retired, all accounts have been migrated or closed, and no residual cross-connections remain. The audit is signed off by named executives on both sides of the integration. Without the audit, the integration is considered incomplete regardless of what the business-side integration says.

Most M&A integrations don’t do this. The cost is high and the benefit is invisible until something bad happens. The typical M&A integration spends tens of millions on business integration and under a million on identity integration. The asymmetry produces the residual problems that show up three to five years later in security incidents.

a clean identity integration, in order

1. 1inventory on day oneEvery identity provider, app, account and grant that comes with the deal.
2. 2choose one identity providerDecide which one survives before migrating anything.
3. 3map roles, then migrateTranslate their roles into yours instead of copying permissions.
4. 4retire the old provider and the trustIntegration ends when the second login path is gone.
5. 5review inherited adminsEach one gets an owner and a reason, or loses the role.

the exercise

If your company has completed an acquisition in the last three years, run this audit.

Pull the complete list of identity artifacts from the acquisition. This includes: every IdP that came over from the acquired company, every SaaS application federated with any of those IdPs, every account in each of those IdPs and applications, every service account inherited from the acquired environment, every OAuth grant inherited, and every cross-federation arrangement established during the integration.

For each of these artifacts, ask two questions. Is it still needed today? Is the ownership clear?

For anything that is not needed, retire it. For anything with unclear ownership, either establish ownership or retire it.

If you have completed multiple acquisitions, the audit is necessary for each one. The residual artifacts from each acquisition are distinct and don’t resolve themselves through subsequent integrations.

Your acquisition closed on paper three years ago. Your identity graph didn’t close. It quietly absorbed the target’s identity graph, and both graphs are still there, intertwined, waiting for someone to separate the inherited-and-retired from the inherited-and-retained.

The separation only happens if you make it happen. M&A integration doesn’t finish on its own.