M&A Identity Integration: Merging Multiple Identity Providers After Acquisition

The deal closes on Friday. By Monday, people from both companies need to access shared resources, join Teams meetings, and reach each other’s internal tools. Meanwhile, Company A runs Okta, Company B runs Entra ID, and nobody planned for this during due diligence.

This scenario plays out constantly in enterprise IT. Identity consolidation after M&A is consistently ranked as one of the top integration challenges, yet it rarely gets adequate attention before the deal closes.

The Timeline Reality

Identity integration after M&A happens in three phases, whether you plan for it or not:

• Day 1-30: Emergency access — people need to work together now
• Month 2-6: Tactical federation — both systems coexist with trust between them
• Month 6-18: Strategic consolidation — migrate to a single IdP

Trying to compress this timeline leads to outages and frustrated users. Each phase has different goals and different risk profiles.

Day 1: Emergency Federation

The immediate need is cross-organization access without requiring everyone to have accounts in both systems.

Option A: IdP-to-IdP Federation (SAML/OIDC)

Configure a federation trust between the two IdPs. Users authenticate at their own IdP, and the other organization’s apps trust the assertion.

For Okta (Company A) federated with Entra ID (Company B):

1. In Entra ID, add Okta as an External Identity Provider under Cross-tenant access settings
2. In Okta, add Entra ID as a SAML Identity Provider
3. Configure attribute mapping so both systems understand each other’s user claims

This gives you cross-org SSO within days, not months.

Option B: Shared SaaS App Access

For immediate collaboration needs (Teams, Slack, Confluence), the fastest path is:

1. Enable B2B Guest Access in Entra ID (if Company B uses Microsoft 365)
2. Invite Company A users as guests — they authenticate against their own Okta
3. Set up the reverse for Company A’s SaaS apps

Guest access isn’t pretty, but it works on Day 1 while you plan the real integration.

Option C: VPN/Network-Level Trust

For legacy apps that don’t support federation, establish a site-to-site VPN or network peering between the two organizations. Users access the other org’s apps via network connectivity and authenticate locally. Temporary and ugly, but sometimes necessary for mainframe or thick-client apps.

Month 2-6: Tactical Coexistence

Choose the Target Platform

Before migrating anything, decide which IdP wins. This is a political and technical decision:

Sometimes neither platform is the right answer. If Company A runs a legacy on-prem IdP and Company B runs a basic cloud IdP, a third platform migration might be more efficient than forcing either to scale.

Identity Reconciliation

The messiest part of M&A identity work: matching user accounts across two systems.

Build a reconciliation pipeline:

# Simplified account matching logic
def reconcile_accounts(source_users, target_users):
    exact_matches = []
    probable_matches = []
    conflicts = []
    unmatched = []

    target_by_email = {u['email'].lower(): u for u in target_users}
    target_by_upn = {u.get('upn', '').lower(): u for u in target_users}

    for src in source_users:
        email = src['email'].lower()
        upn = src.get('upn', '').lower()

        if email in target_by_email:
            target = target_by_email[email]
            if src['first_name'] == target['first_name'] and src['last_name'] == target['last_name']:
                exact_matches.append((src, target))
            else:
                # Same email, different name — could be a conflict
                conflicts.append((src, target, 'name_mismatch'))
        elif upn in target_by_upn:
            probable_matches.append((src, target_by_upn[upn], 'upn_match'))
        else:
            unmatched.append(src)

    return exact_matches, probable_matches, conflicts, unmatched

Exact matches: Merge automatically — link the two accounts. Probable matches: Review with HR for confirmation. Conflicts: Manual resolution required — could be the same person with a name change, or two different people with the same email (surprisingly common in large organizations). Unmatched: Net new accounts to create in the target system.

Unified Directory Design

Decide on the attribute schema for the combined organization:

• UPN format: [email protected] vs [email protected] — do you unify under a single domain?
• Group naming convention: Company A uses APP-Expense-Admins, Company B uses Expense_Admin_Group
• Organizational hierarchy: Department codes, cost centers, and manager chains need alignment

Don’t underestimate this work. Attribute schema mismatches cause application authorization failures that are hard to debug.

Month 6-18: Strategic Consolidation

Application Migration Waves

Same approach as any IAM migration, but with the added complexity of two user populations:

Wave 1: Shared SaaS apps — Move both organizations’ users to the target IdP for common apps (Office 365, Salesforce, etc.)

Wave 2: Company A’s internal apps — Migrate Company A’s applications to trust the target IdP

Wave 3: Company B’s internal apps — Migrate Company B’s applications

Wave 4: Decommission the losing IdP

The Group and Role Problem

This is where M&A identity integration gets painful. Both companies have:

• Application-specific roles (Admin, User, ReadOnly)
• Security groups for access control
• Nested group hierarchies
• Dynamic groups based on attributes

You can’t just merge them. Company A’s “Admin” role in Expense App has different permissions than Company B’s “Admin” role in their Expense App (which might be a different product entirely).

Strategy: Create a new unified RBAC model that maps both organizations’ existing roles to a common set. This often requires application-level changes, not just IdP changes.

Communication Plan

The #1 failure mode in post-M&A identity integration isn’t technical — it’s communication. Users see:

• Different login pages
• Password reset emails from an unfamiliar system
• MFA enrollment requests they don’t understand
• Access denied errors for resources they had yesterday

Prepare:

• Email templates for each migration wave explaining what changes and what to do
• Help desk scripts for the top 10 expected issues
• Rollback criteria — define what constitutes “bad enough to roll back” before you start

Vendor-Specific Considerations

Merging Two Okta Tenants

Okta doesn’t natively support tenant merge. Options: Okta Professional Services engagement, MightyID automated migration tool, or manual recreation of users/groups/apps in the target tenant.

Merging Okta and Entra ID

Establish SAML/OIDC federation during coexistence, then migrate Okta users and apps to Entra ID (or vice versa) using SCIM provisioning and manual app reconfiguration.

Merging Two Entra ID Tenants

Use Microsoft’s cross-tenant migration tools: Cross-tenant user synchronization for identities, and manually migrate Enterprise App registrations. B2B collaboration handles the coexistence period.

Merging with Keycloak

Keycloak’s Admin REST API makes bulk user import relatively straightforward. Export from the source IdP, transform to Keycloak’s JSON format, and import via API. Federation for coexistence uses standard SAML/OIDC.

Lessons From the Field

Start identity planning during due diligence. The earlier you understand the identity landscape, the better your integration timeline estimates.

Don’t consolidate on Day 1. Federation first, consolidation later. Every M&A identity disaster I’ve seen was caused by trying to merge too fast.

Budget for the unexpected. Shadow IT apps, forgotten service accounts, and undocumented federation trusts always surface during migration. Build 30% buffer into your timeline.

Keep both help desks active. Until consolidation is complete, users need support from people who understand their specific system. Cross-training help desk staff takes time.