Why identity governance after a merger is a different problem
The acquirer's CISO or head of IT inherits two directories, an access baseline on the acquired side that nobody has measured, and a date by which the first control evidence must exist. The job is not simply to create accounts for the new workforce. It is to reconcile identities across both estates, find out who holds what access today, and produce evidence that the combined environment is governed. Reconciliation and evidence come before provisioning, because provisioning a mess only copies it into the acquirer's systems.
The short answer is that midPoint fits the governance layer: it holds the identity records, joiner, mover and leaver rules, access requests, and certification campaigns across both sources. It does not act as an access management or SSO server, as the project itself notes in its Evolveum FAQ, so single sign-on and secrets handling belong to separate components chosen and sized on their own. Plan for the boundary early, including which directory is authoritative for each population during the transition, since that choice decides which records midPoint reconciles against.
The regulator in view changes the sequence. A US SEC registrant may exclude a newly acquired business from its internal control assessment for a limited period, but the exclusion has a one-year ceiling and must be disclosed, so the acquired access baseline must still be controlled inside that window. An EU entity under NIS2 or DORA must keep its service and provider records current, and DORA expects tested exit and transition plans for critical services. Where EU personal data becomes reachable from a non-EEA acquirer's staff, remote access may count as a GDPR transfer, so access grants for that population need legal review before they are made. Confirm the applicable deadlines with your counsel and your auditors, since they set the order of the work.
Which regulatory requirements shape the first 90 days after close
This table maps each regulatory requirement that tends to bite during integration to what it means for the identity build, such as unique IDs before accounts are merged. Read it as a checklist for the first 90 days, and confirm each obligation with counsel and your regulator, since applicability depends on your entity type, listing status and where data is processed.
| Requirement | What it asks for | What it means for the identity build |
|---|---|---|
| SEC ICFR treatment of an acquired business | Management may exclude a newly acquired business from its ICFR assessment for up to one year and not across more than one annual report, with the exclusion and its significance disclosed | Inventory which target systems touch financial reporting and get their access controls documented early, so the exclusion window is not spent discovering orphaned finance accounts |
| SEC Form 8-K Item 1.05 and third-party oversight | Material cybersecurity incidents are reported within four business days of materiality determination, and annual reports describe oversight of third-party service providers | Keep current, queryable records of who holds access to which systems, including vendor and contractor accounts, so incident scoping and third-party oversight can be answered quickly |
| NIS2 entity details | Named entities must notify their competent authority of changes to contact details, IP ranges, sector and service Member States without delay and within two weeks | Add the acquired entity and any new IP ranges to the change register, and assign owners who can confirm changes inside the two-week limit |
| DORA register and exit strategies | Financial entities keep a register of ICT service arrangements and tested exit strategies for services supporting critical or important functions | Record which identity services, such as directories and SSO, are provided by the acquirer or a third party, and document how their identity data could be exported and moved |
| GDPR Article 28 instructions and Chapter V transfers | Processors act only on documented controller instructions, including for transfers, and remote access to EU personal data from a third country is a transfer | Before non-EEA acquirer staff receive access to EU target systems, document instructions and a Chapter V transfer tool, and scope access by role rather than granting broad remote admin |
| HIPAA unique user identification and business associate terms | Access control requires unique user identification, audit controls must record activity in ePHI systems, and business associate contracts flow Security Rule terms to subcontractors | Do not merge shared or generic accounts into the combined directory until each person has a unique ID, and confirm the acquired business associate contracts cover identity providers and subcontractors |
| FTC Safeguards MFA and logging | Covered financial institutions must use multi-factor authentication for any individual accessing an information system and must monitor and log authorized user activity | Enforce MFA on the target's systems and any federated access during cutover, and confirm logs from both directories flow into one place before the first certification campaign |
What the acquired estate looks like before any tooling is chosen
Before choosing midPoint or any other tool, the acquiring organization needs a written inventory of every identity source it is about to inherit, because reconciliation must precede joiner automation. Automating joiners on top of two unreconciled directories copies the target's errors into the combined estate. Start with the authoritative HR feed from the target, which decides who is an employee, contractor or leaver, and compare it against what the target's directories actually contain. Confirm the employment status codes, effective dates and manager relationships in that feed, since these fields drive every later rule.
Next, map the directories and the accounts that sit outside them. Identify the Active Directory or Microsoft Entra ID forests and tenants in the target, whether they have trusts with the acquirer's environment, and which applications authenticate against them. Then list the local application accounts, SaaS administrator roles, shared mailboxes and service accounts, contractor identities held in separate directories, and privileged accounts such as domain administrators, cloud global administrators and database owners. Privileged and service accounts often have no owner in HR, so flag them for a named accountable owner before any automation touches them.
This inventory explains why three problems appear after a merger. Duplicate identities form when the same person has an account in each company's directory, often under different naming conventions and with no shared employee number. Orphaned accounts remain when an HR record closed years ago but the local application account was never disabled because no system was told. Excess entitlements accumulate when people moved between roles on the target side and kept their old group memberships. A useful first check is to count, for each target system, how many accounts match an active HR record on a shared identifier, and to treat the unmatched remainder as the work list for a decision by each system owner (illustrative: a payroll application with accounts for former contractors will look very different from an HR portal).
Which open source platforms fit the combined estate
A merger identity program usually needs three layers: a governance core that reconciles and reviews accounts, an SSO layer that authenticates users into applications, and a secrets store for the service accounts that connect them. The cards below cover what each open source option contributes and what to confirm before choosing.
midPoint as the governance core
midPoint is the IGA core for reconciliation, role modeling, leaver processing and certification campaigns across two directories. Its ConnId connectors include LDAP, Active Directory, Microsoft Entra ID, SCIM2, CSV and DatabaseTable, so you can read both estates before any account moves. Confirm that each source system you need has a supported connector, since integration catalog status ranges from supported to community and experimental.
Licensing and support path
midPoint is licensed under EUPL-1.2 and Evolveum states it has no enterprise edition, so the software carries no license fee and cost sits in connector work, role modeling and support. Plan around the release path: 4.8 Curie is a long-term support release supported until October 17, 2028, while midPoint 4.9 support ends October 18, 2026. Confirm which release your partner will deploy and when it moves off 4.9.
Keycloak as the SSO layer
Keycloak is Apache-2.0 licensed and supports OpenID Connect, SAML 2.0, identity brokering and LDAP and Active Directory user federation, which lets the acquired and parent workforce sign in through one front door during coexistence. midPoint does not act as an SSO server, so it sits beside Keycloak rather than replacing it. Confirm how federation trust and attribute mapping will be agreed between the two directories before cutover.
authentik or ZITADEL as alternatives
authentik (MIT, with a separate enterprise directory) and ZITADEL (AGPL-3.0, with SCIM and SAML 2.0 support) are alternatives to Keycloak for the SSO layer. Choose between them only after you map existing federation needs, including which directories must stay authoritative, which applications need SAML, and how the license terms of each fit your legal review. Confirm these points with the vendor and your partner, not from this summary.
OpenBao for connector credentials
midPoint connectors need service account credentials for both directories and target systems, and those secrets should not sit in configuration files. OpenBao is MPL-2.0 licensed and manages, stores and distributes secrets, so it can hold connector credentials during the merger. Confirm which secret rotation and access audit features your team needs, and how the vault will be backed up and recovered.
Vault license as a constraint
HashiCorp Vault version 1.15.0 and later is licensed under the Business Source License 1.1 with IBM named as licensor, which is not an OSI-approved open source license. If your acquirer or target already standardizes on Vault, check the license terms with legal before expanding its use to connector credentials, since a second secrets store adds operational work during a merger.
How the integration runs from discovery to the first certification
The sequence turns two directories and two sets of entitlements into one governed population, with each phase closing on a written artifact that the next phase depends on. By the end, the combined estate has a documented source-of-truth map, cleaned access, tested leaver handling and decision records from a first certification campaign.
Decide authoritative sources and build the source-of-truth map
The client's identity, HR and business owners agree which system is authoritative for each identity attribute and each target application in both organizations, including which HR feed starts the acquired workforce's lifecycle. DeployOpen documents these decisions in a source-of-truth map that names the owner of each attribute and the system of record for each target. The step is complete when the client's sponsors sign the map and the open questions are logged with named owners.
Collect accounts and entitlements read-only
Using midPoint's ConnId connectors for the directories and selected target systems, DeployOpen configures read-only collection of accounts, group memberships and entitlements from both environments into a staging model. No write operations are enabled during this phase, so the source directories stay unchanged while the data is gathered. The step closes with a reconciliation report that shows matched, unmatched and conflicting accounts per system, reviewed with the client's directory administrators.
Match identities and resolve duplicates
Matching rules pair accounts that belong to the same person across the two directories, using agreed attributes such as employee number, verified email and HR identifiers. Ambiguous matches go to a manual queue where the client's HR and IT owners decide, and the decision is recorded against the account. The unique identifiers from each source are preserved as correlation keys, so the audit trail can still trace every account back to its original system. The step is complete when every identity has either one confirmed link or a documented exception.
Clean up orphaned and excess access before go-live
Accounts with no owner, accounts tied to leavers, and entitlements beyond what the person's current role needs are listed by system. Each system owner reviews their list and signs a decision for every item: keep with a stated reason, remove, or transfer to a new owner. DeployOpen applies only the signed decisions, and the removals are logged with the decision reference. The step is complete when no unowned account remains in scope and every exception has a signed justification.
Build the role model from observed access
Instead of starting from job titles alone, the team groups the cleaned entitlements by how people actually use them, then compares those groups with the acquirer's existing role catalog and the target's job families. Business owners confirm which roles reflect real need and which grant access that no one should hold. The output is a role model with named owners, a description of each role's entitlements, and a list of roles still waiting for a decision. Changes to roles are approved by the owners before they are configured in midPoint.
Test joiner, mover and leaver for the combined population
DeployOpen configures joiner, mover and leaver rules in midPoint for both legacy populations, driven by the authoritative sources named in the first step. Test cases cover a new hire, a transfer between the two organizations and a leaver, and each case is run in a non-production environment against the target systems. The team measures how long each leaver takes to lose access and records the results in a test report that the client signs off. The step is complete when the leaver timing meets the client's stated requirement and the report is accepted.
Run the first certification campaign on the combined estate
The client selects the scope, reviewers and campaign schedule, and midPoint routes access reviews to managers and system owners for the combined population. Reviewers approve or revoke each entitlement, and revocations are applied through the connectors after the campaign closes. Each decision is stored as a decision record that names the reviewer, the date and the justification. The campaign is complete when every item has a recorded decision, the revocations are confirmed in the target systems, and the records are exported as evidence for the client's auditors.
Evidence auditors and regulators ask for after a merger
This table maps each piece of post-merger evidence to the component or record that produces it, and to the question it answers for an auditor or regulator. Use it to decide which midPoint outputs, approval records and register entries to preserve from day one. DeployOpen prepares this evidence; auditors, supervisors and regulators reach their own conclusions on it.
| Evidence | Produced by | Question it answers | Confirm before go-live |
|---|---|---|---|
| Reconciliation reports and match decisions | midPoint reconciliation runs against both directories, with recorded correlation rules and manual match decisions | How were accounts from the acquired directory matched to identities, and who approved unmatched or ambiguous cases? | Retention period for run reports and the owner who signs off on each match batch |
| Change history and approvals for account moves | midPoint audit records of provisioning, role assignments and approval workflow decisions | Was each access change for an acquired user authorized, and when was it applied? | Audit log export format and whether logs are forwarded to the central SIEM |
| Certification campaign records and reviewer decisions | midPoint certification campaign definitions, reviewer decisions, remediation actions and completion status | Did an accountable owner review inherited and excess access on the combined estate, and was revoked access removed? | Campaign scope, reviewer assignment rules and the cadence the auditor expects for the first cycle |
| Leaver timing logs for acquired staff | midPoint timestamps for disable and removal actions, joined to HR termination or divestiture dates from source systems | How quickly were accounts of departing or transferred staff removed after the separation event? | Authoritative source for separation dates in the acquired HR system and its data quality |
| Transfer tool and processor instruction records for EU personal data | Contract files, documented instructions to processors, and records of processing updated for the acquired estate | Is there a lawful basis for remote access from a non-EEA acquirer, and are processor instructions documented? | Whether a Chapter V transfer tool is in place before any non-EEA staff receive access to EU systems |
| DORA register entries for acquired ICT arrangements | The entity's register of information on ICT service arrangements, updated to include identity services and hosting used by the acquired business | Are all ICT arrangements that support critical or important functions recorded, including those inherited through the deal? | Which entity-level and consolidated register owners are responsible, and the timing of updates |
| SEC scoping disclosure inputs | Acquisition date, business description, significance measures and the list of systems excluded from the internal control assessment | Which acquired business was excluded from the ICFR assessment, and is the exclusion disclosed and time-limited? | Acquisition date and significance figures from finance, reviewed by the external auditor |
What to ask an implementation partner before signing
Start with the directory reconciliation plan, because it decides whether the acquirer's production access survives the first week. Ask the partner to show, in writing, which directory remains authoritative for each population, how the two forests or tenants will be joined (trust, sync or a midPoint-side correlation), and what happens to a user who matches on both sides. Ask for the cutover sequence with a rollback step for each stage, and ask whether any acquirer account will be disabled or re-scoped before the target's joiners and movers have been reconciled. Ask how duplicate identities are handled: the matching rules, the confidence thresholds, and who approves a merge that the rules cannot decide. For shared and service accounts, ask how each one is inventoried, assigned an owner, and either re-homed or retired, with the decision recorded.
Ask how EU personal data is handled during integration before any target data leaves its current environment. Ask who will hold administrative and read access to target systems, including staff of a non-EEA acquirer, and whether that access is treated as a transfer under the EDPB's guidance on Chapter V. Ask for the transfer tool in use, the documented controller instructions the partner will work under as a processor (GDPR Article 28(3)(a)), and where the records of processing will describe the Article 32 measures. Ask for the same answers on any regulatory register the buyer maintains, such as the DORA register of ICT service arrangements if the target is a financial entity.
Ask how the first certification campaign will be designed and evidenced. Request the reviewer mapping for every target application, the rules for orphaned and excess access, the escalation path for reviewers who do not respond, and the format in which decisions are stored, including who can change a decision after it is made. Ask how the ICFR scope exclusion will be documented: the acquisition date, the systems in scope, the controls excluded, and the significance of the business, so that the buyer can satisfy the SEC staff conditions on excluding a newly acquired business. Finally, ask how midPoint long-term support upgrades will be scheduled around the campaign, given that midPoint's releases page lists support end dates for each line, and request the upgrade plan in writing before go-live.
How long, how much effort and what it costs to start after an acquisition
What cost components make up an identity governance project after a merger?
Cost falls into five components: connector work to read and write accounts in each directory and application, role modeling, data cleanup, infrastructure to host the platform, and support. Connector work and role modeling are usually the largest because each target system has its own account model and each acquired business has its own roles. Data cleanup is paid for in analyst and application owner time as much as in engineering. Infrastructure and support are the recurring part. The midPoint platform itself is open source under the European Union Public License 1.2 or later, so there is no platform license fee to budget, but Evolveum states that it has no enterprise edition, and any Platform or Product Support subscription you choose is a separate, quoted cost. Ask each vendor for its itemized components.
What makes the cost of a post-merger identity project go up or down?
The main drivers are the number of directories being reconciled, the number and age of legacy applications, the quality of the HR and directory data, and whether any identity data is governed by EU rules. Each additional directory or application adds connector and testing work. Poor data, such as duplicate accounts, shared mailboxes treated as people, or contractors with no end date, adds cleanup time before any automation can be trusted. Data that covers EU personal data also adds effort in documenting processing and checking where support staff can reach it, including from a non-EEA acquirer. Fewer, well-documented target systems and clean authoritative HR data push cost down.
Which parts of an identity governance program are one-time and which recur?
The one-time work includes discovery of both estates, connector build and testing, role modeling, the first data cleanup, and the first certification campaign setup. Recurring work includes running the platform, applying patches and upgrades, maintaining connectors when target applications change, operating joiner, mover and leaver flows, and running certification cycles at the cadence your policy sets. Platform support subscriptions, if you buy them, recur annually. midPoint 4.8 is a long-term support release supported until 17 October 2028, so plan upgrade effort against the support end dates on the midPoint releases page rather than assuming a single upgrade will last indefinitely.
What does the buyer need to provide before a fixed-scope engagement can start?
Before work starts, the buyer should provide access to both the acquirer and target directories, HR data for both workforces with a named authoritative source, a list of target applications with the owner of each, and read access to logs or entitlement exports so the team can find orphaned and excess access. You also need named decision makers who can approve role definitions, accept cleanup decisions and sign off on the certification scope. Legal or privacy staff should confirm which data crosses the boundary between the two organizations. Missing owners and slow decisions are among the most common reasons a plan stretches, so confirm their availability in the scope document.
Can an internal IT team run a post-merger identity governance project on its own?
An internal team can run it if it has engineers who know LDAP or Active Directory, Java and PostgreSQL operations, and identity concepts such as roles, entitlements and certifications, plus the time to do discovery and cleanup alongside its normal work. midPoint is written in Java and uses PostgreSQL as its native repository database, and multi-node deployments need a sticky load balancer and a shared database, so the platform needs ongoing operations skills. Many teams split the work: internal staff own HR data, application owners and approvals, while an implementation partner handles connectors, role modeling, testing and documentation. Decide early which skills you will keep in-house after handover.
What should I ask for in a fixed-scope quote for post-merger identity governance?
Ask for a written scope that lists each directory, application and connector in the first phase, the roles and access request flows included, the cleanup activities and who performs them, and the certification campaign you expect to run. The quote should separate one-time implementation from recurring items such as hosting, support and upgrades, and state what is excluded, such as additional target systems found during discovery. Ask how changes to scope are priced, what deliverables and documentation you receive, and what the buyer must supply and by when. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and it does not publish a price list, so the quote follows from that scope.
How do deadlines for acquired businesses affect the timing of identity work?
Timing depends on your reporting obligations. Under SEC staff guidance, a public company may exclude a newly acquired business from its internal control assessment, but not beyond one year from the acquisition date and not from more than one annual report, and the exclusion must be disclosed. IT general control areas such as access to programs and data are part of that evaluation where they address financial reporting risks. If you are an EU financial entity under DORA or an entity under NIS2, notify your authority of changes to your details within the required period. Confirm these deadlines with your legal and compliance teams, because they set the order of work more than any technical plan does.
Does EU data protection law change the cost of combining two identity estates?
Yes, when EU personal data is involved. Under EDPB Guidelines 05/2021, remote access to EU personal data from a third country, including for support or administration, is a transfer, so letting a non-EEA acquirer's staff administer an EU target's identity systems requires a Chapter V transfer mechanism. GDPR Article 28 also requires a processor to act only on documented instructions, and records of processing should describe the Article 32 security measures. Budget time for a data mapping exercise, transfer assessment and contract updates before the first account moves. Confirm the exact mechanism with your privacy counsel.
How DeployOpen scopes and supports integration work
This sequence shows how an acquired workforce's identity estate is scoped, reconciled, reviewed and handed over as a fixed-scope written engagement, with each step closing on a named artifact the client keeps. It sets expectations for what DeployOpen prepares and what remains the client's decision and the auditor's judgment.
Agree written scope and evidence boundaries
DeployOpen and the client agree a fixed scope in writing before work starts, covering the directories and HR sources in play, the target systems and connectors, the deliverables, and the named client owners for each decision. The agreement also states that DeployOpen prepares systems, controls and evidence but does not issue audit reports, attestations or certifications, which remain with independent auditors. The step closes when both parties have signed a scope document that lists in-scope systems, out-of-scope systems and the acceptance criteria for each deliverable. Ask for a quote that follows directly from this scope, and confirm whether ongoing support is priced as a separate retainer.
Inventory the acquired and combined estate
DeployOpen works with the client's IT, HR and security teams to list every directory, identity source, application and privileged account from both organizations, including the systems that sit outside central directories. Each item is recorded with its owner, its authoritative source and whether it is in or out of scope for the first campaign. The output is a system inventory and a source-of-truth map that the client approves before any data is moved. The step is complete when the client confirms the inventory is current and each open question has a named owner.
Reconcile accounts across both directories
DeployOpen matches identities across the two directories using agreed keys such as employee ID, email and HR record, and flags accounts that cannot be matched with confidence. Duplicate, dormant and shared accounts are classified so the client can decide which to keep, merge, disable or retire. Matching rules and each decision are written to a reconciliation log that the client can review. The step closes with a reconciliation report showing matched, unmatched and disputed identities and the decision recorded for each.
Identify orphaned and excess access
DeployOpen compares entitlements in target systems against the reconciled identity record to find accounts without an active owner, access that no longer matches a role, and access held across both legacy organizations. Findings are grouped by system and by risk so the client can prioritize removals and confirm exceptions with business owners. Where access is needed for continuity, the exception is documented with an owner and a review date. The step closes with an agreed remediation list and a record of every exception the client accepted.
Configure joiner, mover and leaver rules for the combined estate
DeployOpen configures midPoint or the client's chosen identity platform to apply joiner, mover and leaver rules to the combined population, using the agreed authoritative sources and the connectors required for each target system. Rules are tested against sample identities from both legacy organizations before any production change. The client approves the test results and the production cut-over plan. The step closes when the test log shows expected outcomes for each rule and the client signs off on the configuration as a baseline.
Prepare the first certification campaign
DeployOpen prepares the scope, reviewer assignments, entitlement extracts and decision recording for the first access certification campaign on the combined estate. Reviewers are routed to managers and application owners, and the client decides the campaign cadence and the escalation path for unanswered reviews. The campaign is dry-run on a limited population so the client can confirm that reports are complete and that decisions are recorded with reviewer identity and timestamp. The step closes when the client confirms the campaign population and the evidence format meet the requirements its auditors have stated.
Document, harden and hand over
DeployOpen documents the configuration, data flows, reconciliation decisions, exceptions and runbooks, and hardens the platform according to the agreed security baseline. Evidence packages are assembled so the client's internal audit or external auditor can trace a sample from request to decision to removal. The handover includes access to the documentation, a walkthrough with the client's operators and a list of open items. The step closes when the client accepts the handover in writing and the evidence package is stored in the client's own repository.
Support operations under a retainer
After handover, DeployOpen can provide ongoing support, upgrades and periodic review under a retainer agreed in writing. Support covers connector maintenance, platform upgrades, periodic certification support and changes to the joiner, mover and leaver rules as the combined organization changes. The client decides which items are handled under retainer and which require a new fixed-scope change. The step closes with a documented support schedule and a named contact on each side, which the client can confirm against its own change process.
