Identity integration after a merger

Identity integration after a merger: why the first 90 days differ from a normal SSO project

After a merger, the first goal is cross-company access, and directory consolidation comes later. The acquiring company and the acquired company each run their own directory, their own identity tenant and overlapping applications, and staff on both sides need to reach what they require within days, not after a multi-year migration. A greenfield SSO project assumes one authoritative source of identity. A merger has two, each with its own naming rules, group model and joiner and leaver process, and both must keep working while neither side has agreed to give up control. That changes the design: the first step is usually a brokering layer that trusts both directories without merging them, using Keycloak with its identity brokering and LDAP or Active Directory user federation, or ZITADEL or authentik as the broker. The choice depends on which protocols the shared applications speak and who will operate the layer, so confirm both in each environment.

Three questions shape the first 90 days. First, which directory is authoritative for each application, and who decides when a user exists in both. Second, what trust is temporary: a broker set up for a transition period needs an end date, a named owner and a plan for removing the trust relationship once applications have moved. Third, audit scope. If the acquired business is excluded from internal control assessment for a period, the exclusion is time-limited and must be disclosed, so the team needs logs of who signed in to which system, from which directory, from the first day of brokering. Regulated targets add obligations on top: an EU target's data may be accessed by acquirer staff in a third country only under a valid transfer mechanism, and a HIPAA covered entity needs unique user identification to survive the migration. Confirm these with counsel and the auditor before the first trust is configured.

Consolidation should follow the applications, not the org chart. Move low-risk, widely used applications first, then the identity provider itself, and retire the interim trust only when every application has a single source of identity. Duplicate accounts are the hardest part, because matching on email address alone creates errors when people share names or change surnames. Ask the implementation partner how they will match, merge and disable duplicates, and what evidence they will keep. Consider midPoint, the open source identity governance platform, only when joiner, mover and leaver rules across both companies are too complex to manage by hand, since it adds a second system to run. Whatever is chosen, agree in writing what the interim layer will cost to operate, who patches it and how it will be tested before the first user depends on it.

Which regulatory requirements shape the merged identity design

This table maps each regulation that often applies during a merger to what it means for the identity build, such as keeping a per-company source of truth and a log of cross-company grants. Read each row against the regulators that cover the acquirer and the target, since scope depends on sector, listing status and where data sits. The main takeaway is that access evidence and change records must survive the integration, not only the end state.

Requirement	What it asks for	Implication for the identity build
SEC ICFR scope exclusion for an acquired business	Management may exclude a newly acquired business from its internal control assessment for a limited period, with disclosure of the exclusion and its significance	Track when each acquired directory and application enters scope, and keep account and access records for the acquired estate from day one so the first assessment has evidence
IT general controls on access and program changes	Controls over access to programs and data and over program changes, evaluated where they support financial reporting risks	Document who can approve cross-company grants, separate those approvals from administrators, and log every change to federation, mapper and provisioning rules
SEC Form 8-K Item 1.05 and third-party oversight	Prompt disclosure of material cybersecurity incidents, and annual description of oversight of third-party service providers	Ensure the identity provider and any partner-operated components feed logs to a place that supports fast incident scoping across both companies
NIS2 entity details and change notification	Covered entities give their competent authority contact details, sector and service locations, and notify changes without delay and within two weeks	After a merger changes entity names, IP ranges or service locations, build a checklist that updates identity-related registrations and contact records inside that window
DORA ICT register and exit planning	Financial entities keep a register of ICT arrangements and tested exit strategies for services supporting critical or important functions	Record the identity platform, its hosting and its operators as ICT arrangements, and test a fallback path before retiring the acquired company's identity provider
HIPAA unique user identification and audit controls	Unique user identification, audit controls recording activity in systems holding ePHI, and person or entity authentication	Do not reuse accounts across the two companies during merged access, keep one identifier per person, and retain audit trails through duplicate account cleanup
FTC Safeguards Rule multi-factor authentication and logging	MFA for any individual accessing customer information systems, and monitoring and logging of authorized user activity	Apply MFA to cross-company access paths, including brokered logins from the other company's directory, and log those sessions with the acting account's origin
GDPR Article 28 instructions and transfers	Processors act only on documented controller instructions, including for transfers, and records of processing describe security measures	When acquirer staff can view EU personal data, write the access instructions and transfer basis first, then limit brokered access to the roles and datasets those instructions name

How Keycloak brokers logins across two separate directories

Identity brokering lets the merged environment trust each legacy directory without forcing anyone to move accounts first. In Keycloak, the merged realm registers each legacy source as an upstream identity provider: an OpenID Connect or SAML 2.0 broker to a second Entra ID or Okta tenant, or a user federation link to an LDAP or Active Directory forest. Staff keep their home credentials and sign in at the familiar prompt, and every application behind the merged realm receives tokens from one issuer. Keycloak supports single sign-on, identity brokering, LDAP and Active Directory user federation, and OpenID Connect and SAML 2.0 for this pattern, so the core design is supported. The exact flow, claim handling and first-login behavior should be confirmed in a proof of concept against both real tenants before any cutover date is set.

Directory federation and brokering do different jobs, and the choice should follow the source system. LDAP and Active Directory user federation can read or synchronize accounts from an existing directory, which suits a same-forest or read-only dependency on the acquired company's Active Directory. Brokering to a second cloud tenant relies on that tenant's own sign-in and MFA, so the merged realm inherits its assurance level and should be tested against the policies that apply there. In a multi-customer setting, ZITADEL organizations go further: each customer organization can point to a different identity provider, which fits a shared platform where each partner keeps its own directory. Confirm which of these patterns your deployment will use and whether the target services need one token issuer or several.

Two decisions shape the rest of the project and should be made before the first user signs in. The first is attribute mapping: decide which upstream claims or LDAP attributes populate the username, email, department and group memberships, and which values the merged realm treats as authoritative for each. The second is the authoritative account when a person has accounts in both directories. Common options are linking the two identities by a verified email address or employee number, or keeping them separate until an administrator or HR-driven process merges them. Automatic linking on email alone can attach one person's access to another person's account, so write the matching rule down and test duplicates and shared mailboxes explicitly.

Which open source platforms fit a merger identity layer

A merger identity layer usually needs three things: a way to trust the other company's directory now, a target identity provider for later consolidation, and a process to remove duplicate accounts. The platforms below cover different parts of that job, and their license terms matter once the two companies share one identity estate.

Keycloak as the broker

Keycloak supports identity brokering, LDAP and Active Directory user federation, and OpenID Connect and SAML 2.0, so it can accept logins from the acquired company's directory without moving users first. It is a strong fit when the target has Active Directory and many SAML or OIDC applications. Check the version you deploy, since Keycloak 26.8.1 was released on October 13, 2026, and confirm how the realm model will handle two sets of groups. Keycloak is licensed under Apache-2.0, which imposes few obligations when the combined company redistributes or modifies it.

ZITADEL for isolated tenants

ZITADEL separates tenants as instances with full data isolation and as organizations inside an instance, and each customer organization can use a different identity provider. That suits a merger where each company must keep its own administration and user data for a period. It federates with Entra ID, Okta and LDAP and supports SCIM v2 for provisioning. Its core is licensed under AGPL-3.0, so confirm with counsel whether network use of a modified version creates source disclosure duties for the combined company.

authentik for flexible federation

authentik is MIT licensed except for its enterprise directory, which has a separate enterprise license. It is a candidate when the team wants a Python-based, self-hosted provider with flows that can be customized for a brokered login. Brokering features for the specific target directories, such as Entra ID or an older LDAP estate, must be confirmed in a proof of concept before selection. Check early whether any feature the integration depends on sits inside the enterprise directory, because that changes the license and support terms.

FreeIPA for Kerberos estates

FreeIPA fits when the acquired or target company runs a central Linux estate with Kerberos, host-based access control and internal certificate authorities. It can hold the directory for those hosts and serve as a trust anchor for Windows domain trusts, but it is less suited to hundreds of web applications that expect SAML or OIDC. Decide whether the goal is to host the directory or only to federate it. Review the license and support model of the distribution you choose before combining estates under one contract.

midPoint for duplicate cleanup

Brokering gives access quickly, but it leaves two accounts for one person. midPoint is an identity governance platform that can correlate accounts across sources, apply joiner, mover and leaver rules, and drive reviews of what each person still holds. It is licensed under the European Union Public License 1.2 or later, and the 4.8 Curie long-term support release is supported until October 17, 2028. Plan the correlation rules and the source of truth before the first automated change, because mistaken merges are hard to reverse.

Phased rollout: from cross-company access to one identity provider

This sequence lets staff from both companies reach each other's applications early, then moves applications and accounts onto one identity provider in controlled stages, with evidence at each gate.

Inventory applications and map identity data flows
The integration team, with application owners from both companies, lists every application, its protocol (SAML, OIDC, LDAP or Kerberos), its user store, its admin owners and the attributes it reads from the directory. Data flows are mapped so you can see where identity data moves, which systems hold personal data, and whether any cross-border access would count as a transfer under EU rules. Done means the application inventory is signed off by both sides and every application has a named owner and a recorded protocol.
Design the broker and prove it with one application
Engineers choose how the two directories will be brokered, usually by federating each company's directory into a broker such as Keycloak, authentik or ZITADEL, and define attribute mapping and trust configuration. A proof of concept connects one application from each company to the broker, so the team can test login, claims, group mapping and logout before anything reaches users. Done means the proof of concept passes agreed test cases and the design is written up as an access matrix that shows which user groups can reach which applications.
Run a pilot with logging for a limited group
A defined pilot group from each company receives cross-company access to a short list of applications. Authentication events, group assignments and access decisions are logged to the monitoring stack so the security team can review who used what and whether any access was refused in error. Rollback steps are written and rehearsed before the pilot opens. Done means the pilot group's access is reviewed against the access matrix and the pilot findings are recorded with owners for each fix.
Identify duplicate accounts with matching rules
Identity engineers and HR data owners compare the two user populations and propose matching rules, such as matching on verified employee identifiers first and email addresses second, with manual review for ambiguous cases. Accounts that represent the same person are linked rather than deleted, and any conflicts are routed to a named reviewer. Done means a reconciliation report lists matched, unmatched and disputed accounts, the rules used for each, and the sign-off from HR and application owners.
Migrate applications in waves with exit criteria
Applications move to the consolidated identity provider in waves, grouped by risk and dependency. Each wave has a cutover runbook that lists the configuration changes, the test plan, the rollback path and the user communication. A wave closes only when defined exit criteria are met, such as successful logins for all target groups, no open high-severity access defects and confirmed audit logging. Done means every wave has a signed exit record and the runbook is archived for audit.
Decommission legacy trusts and document the end state
Once every application is on the consolidated provider, the team removes temporary trusts, brokered connections and duplicate directory links, and confirms that no application still depends on them. Retained records, such as access logs and the reconciliation report, are kept under the organization's retention rules. Done means a decommissioning record confirms each trust was removed, the access matrix reflects the final state, and the audit evidence is filed with the security and compliance teams.

Deployment patterns for interim and consolidated identity

A single identity broker in one region is usually the fastest interim step. The broker sits between the two existing identity providers, trusts both over SAML or OIDC, and lets staff from each company sign in to the other's applications without moving accounts. It is a short-lived bridge, not a long-term destination, and its own availability becomes a shared dependency for both companies.

Database: Keycloak supports MariaDB, Microsoft SQL Server, MySQL, Oracle Database, PostgreSQL (14 to 18), EnterpriseDB Advanced, Amazon Aurora PostgreSQL and Azure SQL. The development file database is for testing only.
Install path: The Keycloak Operator, installed through Operator Lifecycle Manager, manages Keycloak, KeycloakRealmImport, KeycloakOIDCClient and KeycloakSAMLClient resources.
Upgrade control: Set operator updates to manual approval mode, which the Keycloak Operator documentation strongly recommends, so an upgrade never lands during an integration cutover.
Schema changes: Keycloak migrates its schema automatically at startup by default. For a broker that will carry both companies, consider manual migration, which the upgrading guide suggests for large deployments.
Single point of failure: One region means one outage domain. Confirm recovery targets with both business owners before go-live.

Before committing, confirm which applications need brokered login and whether any of them require the acquirer's staff to reach EU systems.

Evidence auditors and regulators ask for during an integration

This table lists the records an auditor, supervisor or regulator is likely to ask for when two companies connect their identity systems. Each row names the evidence, what it must show, and the component that usually produces it, so you can confirm the source before cutover. The main takeaway is that most of this evidence has to be captured while the work happens, because it is hard to reconstruct later.

Evidence	What it must show	Component that produces it
Cross-company access matrix and approvals	Which users from each company can reach which applications, who approved each grant, and when it was reviewed	midPoint reports for entitlements, plus the approval records from your request workflow
Broker configuration export	The identity providers trusted for cross-company login, their mappers, client settings and the change history of each	Keycloak admin events and realm exports, or ZITADEL audit records for the equivalent organization settings
Log of cross-company logins with unique user identification	Each sign-in traced to one named account in the source company, with the target application and time	Keycloak admin and login events forwarded to the SIEM, or ZITADEL audit logs in the logging pipeline
Duplicate account reconciliation report	Accounts matched across both directories, the rule used to match them, who resolved exceptions and what was disabled or merged	midPoint reconciliation reports, with exception sign-off kept in the change record
DORA register entries and exit plan for ICT services	For financial entities, the identity services and their providers recorded in the ICT register, plus tested exit and transition plans for services supporting critical functions	Your third-party register and runbooks; the identity platform inventory and exit test records from the project
Change records for IT general control areas	Approved changes to program logic, access to programs and data, and computer operations for the identity systems involved in the integration	Ticketing and change management system, linked to Keycloak or ZITADEL configuration exports and deployment logs
NIS2 update record for changed entity details	Updated entity name, contact details, IP ranges, sector and service Member States sent to the competent authority, with the date sent	Your compliance register and submission records; confirm the notification path with the competent authority

How much does merger identity integration cost and how long does it take?

What drives the cost of identity integration after a merger?

The cost follows the amount of identity work in scope, not a standard package. The main drivers are the number of applications that must trust the other company's users, the number of directories and identity providers that must be connected, the volume of duplicate accounts that need matching and cleanup, the MFA rollout across both user populations, and how much compliance evidence the work must produce. Each driver changes the effort in a different phase, so ask the partner to price them separately. Software licensing for open-source components is usually not the largest line item; integration, testing and change management usually are.

Can our in-house team integrate two identity providers without a partner?

A capable in-house team can do it if it has people who know the applications, the directories and the identity protocols in use, and enough capacity alongside day-to-day operations. The common gaps are protocol work for legacy applications, duplicate account matching across directories, and running a brokered login under production load with a rollback plan. Confirm these skills honestly before deciding. Many organizations split the work: internal staff own application owner decisions and access policy, while an implementation partner handles the broker build, testing and documentation under a written scope.

What does our side need to provide for the integration to run on time?

The work depends on client inputs that DeployOpen cannot supply. Plan for named application owners who confirm login flows, claims and roles, read-only or service access to both directories, and approved change windows for each application cutover. Security and compliance staff should confirm which evidence they need and who reviews it. Missing owner availability is one of the most frequent causes of delay, so agree on these contacts and decision dates before the scope is signed.

Can a SaaS identity provider replace an open-source broker after a merger?

A SaaS identity provider can replace a self-hosted broker if it supports the protocols, directories and data residency your applications and regulators require. Compare the per-user subscription, the migration effort for each application, and the exit path if you later leave the service. Verify whether the SaaS vendor can federate the directories you hold and where identity data is stored. DeployOpen implements self-hosted open-source platforms inside the client's own infrastructure and does not resell SaaS services. A DeployOpen fixed-scope quote covers the written deliverables, such as the broker build, application integrations, testing, documentation and handover, agreed before work starts.

How do DORA exit strategy and EU Data Act switching rules affect an identity platform?

If your organization is a financial entity under DORA, Article 28 requires a register of ICT service arrangements and, for services supporting critical or important functions, tested exit strategies and transition plans. An identity broker often supports such functions, so document how you would move logins and user data to another provider or on-premises. The EU Data Act requires data processing service providers to support switching to another provider or to on-premises infrastructure, with a maximum two-month notice period, a 30-day transitional period, porting of exportable data, and no switching charges from 12 January 2027. Ask any SaaS vendor how these rules are reflected in its contract, and confirm applicability with your legal team.

What should we ask for in a quote for merger identity integration?

Ask for a written scope that lists each application, directory and identity provider in scope, the protocol per application (SAML or OIDC), and the duplicate account handling method. Request the phases, the acceptance criteria for each phase, and the deliverables such as configuration exports, runbooks and test records. Ask which items are excluded, how change requests are priced, what the client must provide, and how long the scope stays valid. Also ask how the partner handles MFA enrollment for both user groups and how it tests rollback before any cutover. Compare quotes on the same written scope, not on headline totals.

Does the engagement include compliance evidence for an acquisition review?

DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. For a merger, the evidence may include access control records, MFA configuration, change records and documentation of how duplicate accounts were removed. Agree the evidence list in the written scope, and confirm with your auditors which artifacts they will accept, including how the SEC treats an acquired business in internal control assessments.

Questions to ask an implementation partner before a merger integration

Start with how the partner maps the applications that hold both companies' data. Ask for a written inventory that records, for each application, which directory is its source of truth, which protocol it uses (SAML, OIDC or LDAP bind), who owns it on each side, and whether it carries EU personal data that a non-EEA acquirer's staff would reach remotely. Ask how that inventory feeds the decision on which applications are brokered first and which are consolidated later. Then ask how duplicate accounts are matched: on employee ID, verified email, or name alone, and who signs off each merge decision. A good answer names a data owner on each side and a rollback path for every merge batch, and it does not rely on a fuzzy name match running unattended.

Next, ask how brokering is tested before cutover. The partner should show a test plan covering a federated login from each direction, a claim mapping check for the attributes each application expects, a deprovisioning test for a leaver in the source directory, and a failover test when one legacy directory is unreachable. Ask how the second company's MFA policy is handled: whether the broker enforces its own factor set, accepts the upstream assurance level, or applies a step-up rule to sensitive applications, and who approves that choice. Ask which high availability design the broker will use and how the partner validates it. For Keycloak, for example, confirm the database and cluster design with the vendor documentation before the quote is signed, and ask what staff can still log in to when one directory is down.

Finally, ask how evidence is produced for ICFR and DORA scope. Under the SEC's ICFR guidance, IT general controls over access to programs and data are the areas auditors examine, so ask for exports of realm or organization configuration, admin role assignments, access review records and change logs for each phase. Ask whether the partner will record which acquired systems are excluded from the ICFR assessment and for how long, since that determination belongs to management and the auditor. If the merged group is a DORA financial entity, ask how each brokering arrangement with an external provider is recorded in the register of information and how the exit plan for the identity service is documented. Confirm in writing who prepares those artifacts and who keeps them.

How DeployOpen scopes and supports a merger identity integration

DeployOpen plans, implements, integrates, documents and supports self-hosted open-source identity platforms inside the client's own infrastructure. For a merger, that means agreeing in writing which directories, applications and cross-company access paths are in scope before any configuration begins, then delivering the bridge, the consolidation phases and the account cleanup as fixed-scope work.

How we scope

Inventory both identity sources, applications and user populations before agreeing deliverables, so the written scope names each directory and system involved.
Confirm which cross-company access paths are needed first, and which applications must remain on their current identity provider during the transition.
Agree in writing whether any remote access from one company's staff to the other's EU personal data is in scope, so transfer and contract questions are settled early.

How we build

Configure identity brokering between the two directories so staff sign in with their home credentials while the target applications stay unchanged.
Map attributes and group or role claims between the two sides, then test sign-in, token contents and access decisions against agreed test cases.
Build duplicate-account detection and merge rules, run them against copies of the data first, and record every matching decision for review.

How we hand over

Deliver configuration exports, runbooks and architecture documentation for the bridge, the consolidation phases and the account cleanup steps.
Document each phase's cutover, rollback and acceptance criteria so the client's own staff can operate the identity provider after handover.
Provide the configuration and access evidence the client's auditors or assessors will ask for, while leaving the assessment itself to them.

How we support

Test upgrades of the identity platform in a staging copy before any production change, and keep the change record for each release applied.
Offer ongoing support, upgrades and continuous testing as a retainer, separate from the fixed-scope integration work.
Re-test cross-company access after each consolidation phase, so newly migrated applications keep working as the second directory is retired.

Identity integration after a merger