Self-hosted Omada alternative for data sovereignty

Can a self-hosted Omada alternative meet data sovereignty requirements?

For a regulated European organization, identity data is personal data: employee HR records, account attributes and access approvals. Under GDPR Chapter V, every transfer to a third country, including onward transfers, must meet a transfer condition, and remote access from outside the EEA counts as a transfer even when data is only displayed on a screen for support. Omada Identity Cloud on Azure and any Omada deployment that relies on third-country support or cloud storage outside the EEA therefore need a documented transfer and access assessment. Self-hosted midPoint running in an EU-controlled environment is the option that removes the third-country hosting question entirely, because the data, the administrators and the support path can all stay inside the organization's chosen jurisdiction. The trade-off is that the organization, or its EU provider, takes on the hosting, patching, backup and access control that Omada otherwise carries.

Omada's own routes need the same scrutiny. Identity Cloud Private runs in the customer's Azure tenant, and the announced containerized Omada Identity Sovereign is described as a way to run the platform on infrastructure the customer controls. Neither should be assumed to satisfy the constraint. Confirm in writing with Omada where the data is stored, which Omada staff or subprocessors can reach it, whether any support or telemetry path leaves the EEA, and whether any component is subject to third-country law with extraterritorial effect. The EDPB Recommendations 01/2020 explain why a technical measure may not be enough when a foreign authority can compel access to data in the clear. Also confirm whether the Data Privacy Framework applies to any US entity in the chain, since its adequacy finding is under appeal.

DeployOpen plans, implements, hardens and documents a self-hosted midPoint deployment in the client's own infrastructure, and prepares the controls and evidence that a privacy or compliance assessment will review. DeployOpen does not issue audit reports, attestations or certifications. Those come from the organization's data protection officer, legal counsel and an independent assessor. Before choosing a route, ask the data protection officer to write down the transfer analysis for each candidate, including the access paths for vendor support. For a self-hosted midPoint scope, define who holds the database, who can administer the connectors and where support tickets and logs are stored, since those decisions determine whether the sovereignty question is closed.

What data sovereignty requires for identity governance data

Identity governance data is personal data: names, accounts, roles, approvals and audit trails. The requirements below set where that data may sit, who may reach it remotely and which foreign orders can compel disclosure, and they apply to SaaS, private cloud and self-hosted options alike. Check each one against your own data flows before you compare products.

Transfers to third countries

Article 44 of the GDPR requires every transfer of personal data to a third country, including onward transfers, to meet the conditions in Chapter V. For identity governance, this covers HR feeds, account attributes and access review records that leave the EEA. Infringements of Articles 44 to 49 can be fined up to EUR 20 million or 4% of worldwide annual turnover, whichever is higher. Map every system that receives identity data and confirm where each one is hosted and administered.

Remote access counts as transfer

EDPB Guidelines 05/2021 state that remote access from a third country is a transfer, even when data is only displayed on a screen for support or administration. Vendor engineers who troubleshoot a SaaS identity platform from outside the EEA can therefore trigger transfer rules. Ask providers where support staff sit, which support tooling they use and whether they can view identity records remotely.

Storage outside the EEA

The same EDPB guidelines treat storage in a cloud outside the EEA as a transfer. Identity repositories, audit logs and backups all hold personal data, so a backup copy in another region can matter as much as the primary database. Confirm the region of every database replica, log sink and backup target, including those a vendor operates on your behalf.

Schrems II and the Data Privacy Framework

The Court of Justice invalidated the Privacy Shield in Case C-311/18 (Schrems II) while holding that standard contractual clauses remain valid. Commission Implementing Decision (EU) 2023/1795 accepts transfers to US organizations only when they appear on the Data Privacy Framework List. An appeal against the General Court's September 2025 judgment is pending as Case C-703/25 P, so treat that adequacy basis as open to challenge and record it in your transfer assessment.

Foreign authority access to data

EDPB Recommendations 01/2020 state that where a provider must access data in the clear and the destination's public authority powers exceed what is necessary and proportionate, no effective technical supplementary measure can be envisioned. US law also reaches providers' data regardless of location under 18 U.S.C. 2713 (the CLOUD Act). Assess this exposure for any provider that is under foreign jurisdiction, even when the data sits in the EU.

Limits on third-country disclosure orders

Article 48 of the GDPR allows a third-country court judgment or administrative decision requiring disclosure of personal data to be recognized or enforced only when it rests on an international agreement, such as a mutual legal assistance treaty, in force with the Union or a Member State. A foreign order served directly on a provider does not meet that test. Ask providers how they handle such requests and whether their contracts commit them to challenge or refer them to the controller.

How Omada's SaaS, private and sovereign variants map to the constraint

Omada Identity Cloud is a SaaS identity governance platform on Microsoft Azure. Identity data, workflows and audit records sit in a service that Omada operates, so the controller's questions are where the data is stored, who can reach it and under which law the operator must disclose it. The hosting region matters, but contract terms and operating practice decide most of the exposure.

Storage location: Confirm in writing the Azure regions used for production, backups, logs and disaster recovery copies. Storage outside the EEA is a transfer under EDPB Guidelines 05/2021, so each region needs a documented basis.
Support access: Ask whether Omada staff outside the EEA can view data on screen during support. Under the same guidelines, remote access from a third country counts as a transfer even when data is only displayed.
Key custody: Ask who holds the encryption keys, whether customer-managed keys are supported and whether Omada can read data in the clear.
Sub-processors: Request the current list of sub-processors with their locations, plus advance notice and objection rights before any change.
Third-country law: Ask whether Omada or any parent company is subject to US law. Under 18 U.S.C. 2713, a US provider must preserve or disclose data in its possession, custody or control wherever that data is located.

Check these answers against the data processing agreement and your transfer assessment, because marketing material does not bind the provider.

Which open-source options keep identity data under your control

This table compares self-hosted midPoint, Apache Syncope, and the cloud or hybrid SailPoint and Saviynt products against a data sovereignty constraint. Read each row by asking where the identity data is processed and stored, who can administer it, and which capabilities you would need to build or buy separately. The main takeaway is that both open-source options can run entirely in infrastructure you control, but neither replaces an access management or SSO server, and governance depth differs.

Option	How it meets sovereignty	Trade-offs and gaps
Self-hosted midPoint	Runs on Linux in a VM or from Docker images in your own or EU-chosen infrastructure, with PostgreSQL as the repository database. Licensed under EUPL-1.2 with Apache 2.0 as secondary license, so no license fee or vendor-held data path exists.	Java 25 is recommended for 4.11 and later, Java 21 for 4.10 and older. You operate the stack, and connector maturity varies from supported to experimental. Not an access management or SSO server, so pair it with your own SSO.
Apache Syncope 4.1.3	Apache License 2.0 project for digital identity management that you deploy in your own infrastructure. The release date is September 11, 2026 per the Apache Syncope downloads page, so confirm the current build before adoption.	Strongest fit for provisioning and self-service. Governance features such as certification campaigns and role mining are narrower than midPoint, so confirm them against your review requirements. Not an access management or SSO server.
SailPoint IdentityIQ	Designed for hybrid and on-premises deployments, so it can be placed in your data center. SailPoint announced IdentityIQ 9.0 on October 6, 2026 as the modernization path for these customers.	Commercial license, so the sovereignty check covers vendor support access, telemetry and where any hybrid components process data. Confirm deployment location and remote support paths in writing.
SailPoint Identity Security Cloud	Cloud product, so identity data is stored and processed by SailPoint's hosting. Relevant only if the hosting region and access model meet your data transfer rules.	Check hosting location, sub-processors and third-country access for support. SailPoint positions Human Fabric as the evolution of this product for cloud customers.
Saviynt Enterprise Identity Cloud	Cloud-native platform that governs workforce, third-party, service and privileged accounts. Relevant only if the hosting region and access model meet your data transfer rules.	Cloud delivery means your identity data resides in the vendor's hosting. Confirm data residency options, support access locations and the scope of any contractual exit terms.

How to deploy midPoint in an EU-controlled environment

This sequence moves midPoint from a hosting decision to a supported production cluster in infrastructure the organization or an EU provider controls. Each step ends with a check that the data location, access path and release line are documented before the next step starts.

Confirm hosting provider, jurisdiction and access paths
The client's legal or privacy lead, with DeployOpen as implementer, records where the servers, backups, support tooling and administrator sessions will sit, and which legal entities control each layer. The team lists every remote access path, including vendor support sessions, monitoring agents and any shared administration consoles, and marks any path that could show personal data to staff outside the EEA. The output is a signed data flow and access inventory that the client's data protection officer reviews. Ask the provider in writing whether it is subject to third-country law with extraterritorial effect, because the EDPB guidance treats a request from such an authority as a potential transfer even when the processor is in the EU.
Choose the runtime and Java version
The client's platform team chooses between a Linux virtual machine and Docker images, based on existing operations standards. midPoint recommends Java 25 for version 4.11 and later, with Java 21 supported, and Java 21 for 4.10 and older, with Java 17 supported. DeployOpen records the chosen JDK and base image in the build standard and confirms that the JVM and OS are on vendor-supported lines. The check is a reproducible build of an empty midPoint node in a staging environment that starts and serves its login page.
Place PostgreSQL on a separate database server
midPoint uses PostgreSQL as its native repository, and the system requirements advise running it on a separate database server rather than on the application node. The database team sets up the server in the approved jurisdiction, applies the client's encryption and key custody standard, and grants midPoint a dedicated account with the privileges needed for schema upgrades. Key decisions for the client are who holds the encryption keys, who approves database administrator access and where backups are stored. The check is a successful connection from the midPoint node over the approved network path and a tested restore of a backup into a separate environment.
Configure multi-node operation and shared services
For high availability, DeployOpen configures at least two midPoint nodes behind a sticky HTTP load balancer that keeps each session on one node. All nodes share the central database, and they invalidate caches between each other over HTTPS. Quartz handles distributed task scheduling so that each job runs once across the cluster. The client's security team reviews TLS certificates, the internal certificate authority and firewall rules between nodes. The check is a failover test in which one node is stopped during a provisioning task and the task completes on another node without duplicate changes.
Build and test connectors against target systems
Engineers build or configure connectors for each source and target system using the ConnId framework, starting with the documented connectors such as LDAP, Active Directory, CSV, Microsoft Entra ID through Graph API, and SCIM2 where the target supports it. Connectors not in the supported list are classified as community or experimental and receive extra review. Each connector is tested against a non-production copy of the target, with reconciliation reports compared to the current source of truth. The output is a signed test record per connector, plus a list of accounts that must be handled manually at cutover.
Set the supported release line and upgrade plan
The client selects a release line that matches its support needs. midPoint 4.8 (Curie) is a long-term support release supported until October 17, 2028, and midPoint 4.10 (Braille) is a feature release supported until November 26, 2027. midPoint 4.9 support ends October 18, 2026, so deployments on that line should move before then. The team documents the upgrade process, the test environment that mirrors production, the rollback plan for the database and the owner who approves each upgrade. The client decides whether to buy an Evolveum support subscription for bug resolution or to rely on internal and partner expertise. The check is an approved runbook and a dated calendar of release reviews.
Approve access, hand over and run the first cutover wave
Before production use, the client signs off on the access model: who can administer midPoint, who can approve privileged changes, how emergency access is granted and logged, and how logs leave the environment. DeployOpen delivers configuration documentation, runbooks and an evidence pack that the client's auditors or certification body can review; the evidence supports an assessment but does not replace one. The first provisioning wave is limited to a defined set of accounts and target systems, and the operations team monitors reconciliation after each run. The output is a signed go-live record and an operations handover that names the people responsible for each control.

What changes for data controllers and processors choosing an EU provider

Engaging an EU provider does not by itself make a transfer. Under Example 12 of the EDPB Guidelines 05/2021, using an EU processor that is subject to third-country law with extraterritorial effect is not itself a transfer. The exposure sits in the request: if that processor complies with a third-country authority request, the disclosure would be a transfer. Before signing, the controller should ask the provider in writing whether it has received such requests, what its policy is for challenging them, and whether it can operate the platform so that no personnel outside the EEA can view data. Note that the CLOUD Act provision at 18 U.S.C. 2713 reaches data in a provider's possession, custody or control wherever it is stored, so the location of the servers alone does not settle the question. For a self-hosted midPoint deployment, the controller also decides who holds administrative access to the database, the Java runtime and the backups, and that access list is part of the assessment.

The Data Act gives procurement teams concrete leverage. Article 32 of Regulation (EU) 2023/2854 requires providers of data processing services to take technical, organisational and legal measures to prevent third-country governmental access to non-personal data held in the Union where that access would conflict with Union or national law. Articles 25, 29 and 50 give customers the right to switch to another provider or to on-premises ICT infrastructure, with a maximum two-month notice period and a 30-day transition, and they ban switching charges from 12 January 2027. Ask any SaaS or private-cloud vendor, including Omada, to show how these duties are reflected in the contract, the exit plan and the data export format. Confirm the notice periods and charges in the signed terms rather than relying on the regulation's summary.

DeployOpen prepares systems, configuration and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies assess the controls, and data protection authorities decide whether a transfer or processing arrangement complies with the GDPR. Plan the evidence pack, including data flow maps, access reviews, key management records and the provider's transfer assessment, with those reviewers in mind, and confirm the scope of any assessment with your DPO and external auditor before the first engagement starts. Any work on the platform is agreed in a written, fixed scope.

What auditors and regulators ask to see

Auditors and supervisory authorities test whether identity data stays where the organization says it does, who can reach it, and how the organization can leave. The cards below cover the evidence sets that usually connect those questions to a self-hosted midPoint deployment. DeployOpen prepares this evidence, but auditors and regulators judge it.

Identity data flow map

A current diagram showing where identity data is stored, processed, backed up and accessed, from HR sources through midPoint, its PostgreSQL repository and each ConnId connector to target systems. Include every location a copy can reach, such as backups, logs and support tooling. Check that each node sits in infrastructure the organization or its EU provider controls, and that the map is dated and reviewed when connectors change.

Transfer impact assessment

A written assessment for each third country that could reach identity data, including remote access from outside the EEA and any cloud storage outside it. Under the EDPB guidance, displaying data on a screen for support is itself a transfer, so support paths belong in scope. Record the legal basis for each transfer and the supplementary measures chosen, and state where no effective technical measure exists.

Remote access origin log

Records showing which administrators, vendors and support staff connected to midPoint, from which country and over which path. Keep identity provider logs, VPN or bastion records and midPoint audit entries together so the origin of each session can be traced. Confirm that vendor support sessions, including Evolveum subscription support, are logged and that the organization can show when they were allowed.

Key and access custody records

Documentation of who holds the encryption keys, database credentials, connector service accounts and midPoint administrator accounts, and where those secrets are stored. Show the key ownership model, rotation history and the break-glass procedure. Regulators look for evidence that no third party, including the software vendor, can read identity data without the organization's knowledge.

Supplier and processor contracts

Signed agreements with every processor and subprocessor that touches identity data, including hosting providers, managed database operators, implementation partners and any Evolveum support subscription. Confirm that each contract names processing locations, transfer mechanisms such as the standard contractual clauses, and the notification duties if a third-country authority requests data. Check the Article 48 position where a foreign court order could be involved.

DPF status check

A dated record of whether each US-based supplier appears on the Data Privacy Framework List, and of the status of the pending appeal in Case C-703/25 P. Because adequacy under Implementing Decision (EU) 2023/1795 covers only organizations on that list, the record should show the fallback transfer tool for any supplier that falls off it. Re-check this record on a fixed schedule, not only at contract signing.

Exit and switching plan

A tested plan for moving identity data, configuration and connectors to another platform or to another deployment. Under the Data Act, customers have rights to switch providers or move to on-premises infrastructure, with a maximum two-month notice period and a 30-day transition. Document export formats, connector rebuild effort and the cutover steps, and rehearse the plan at least once.

midPoint upgrade and patch records

A change log of midPoint versions, Java runtime updates, PostgreSQL patches and connector upgrades, with the date each was applied and tested. Track each release against its support window, since midPoint 4.9 support ends on October 18, 2026, and plan moves to a supported line before then. Auditors expect evidence that vulnerabilities are patched within the organization's own policy timelines.

Questions buyers ask before choosing a self-hosted Omada alternative

What drives the cost of self-hosting midPoint instead of paying for Omada?

The cost is set by four components: infrastructure, the team that runs it, an optional Evolveum subscription, and the implementation scope. midPoint itself carries no license fee, because it is dual-licensed under EUPL and Apache 2.0. Infrastructure and staff are the recurring costs, while the connector build, HR source integration and migration are largely one-time. Ask any quote to split these lines, state which environments (test, production, disaster recovery) are included, and name who pays for each connector. Evolveum's support subscriptions come in Product Support, with an 8x5 next-business-day or 24x7 SLA, and Platform Subscriptions; the Evolveum page lists no prices, so confirm current pricing directly with Evolveum.

What should a fixed-scope quote for a midPoint implementation include?

A fixed-scope quote should list deliverables, not just hours. Ask for the number of source and target systems and which ConnId connectors each one needs, whether the HR source is in scope, how many roles and access request workflows are covered, and whether the migration from Omada and parallel running are included. The quote should also state the hosting model (your Azure tenant, your data center or an EU provider), the backup and upgrade responsibilities, and the documentation handed over. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms in the client's own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts.

How long does a midPoint migration take, and what changes the timeline?

The duration depends mainly on the connector count, the HR source and the number of approval and review processes to port. Each target system adds a connector build and testing cycle. A single authoritative HR feed is usually simpler than several overlapping sources, and access reviews and request workflows add design work. No duration is given in the sources for this migration, so ask any vendor or partner for a timeline tied to a written list of systems and processes. Also ask how long parallel running lasts, since that period is often the most expensive part of the cutover.

Can our team run midPoint without an implementation partner?

Yes, it is possible if you have engineers comfortable with Java, PostgreSQL and identity concepts. midPoint is written in Java and recommends Java 25 for version 4.11 and later (Java 21 supported) and Java 21 for 4.10 and older (Java 17 supported). It uses PostgreSQL as its native repository database, ideally on a separate database server, and can run on Linux in a virtual machine or from Docker images. Evolveum offers support and training, and its FAQ describes midPoint developers working on it full-time. Confirm that your team can own upgrades between releases such as 4.8, the long-term support line supported until October 17, 2028, and 4.10, supported until November 26, 2027.

What skills and staff time does a self-hosted midPoint need from our side?

Plan for identity architects who can model roles and assignments, integration engineers who maintain connectors, database and Linux operators, and a security owner who signs off on access policies. For multi-node deployments, the system requirements call for a sticky HTTP load balancer, a shared central database, cache invalidation between nodes over HTTPS and Quartz for distributed task scheduling, so someone must run that stack. Your business owners also need time for access review campaigns and approval design. Ask the vendor to name which roles it expects you to fill and which it will cover in a retainer.

Could Omada's private variant, Identity Cloud Private, meet our data sovereignty needs?

It may, but only if the questions below are answered in writing. Identity Cloud Private runs in your own Azure tenant, while the containerized Omada Identity Sovereign is announced but its availability and terms should be confirmed with Omada. Under EDPB Guidelines 05/2021, remote access from a third country, even only displaying data for support, counts as a transfer, and so does storage in a cloud outside the EEA. Ask Omada whether its support staff access your data, from where, and under which law. Also ask who controls keys and logs, and whether a third-country authority request could reach your data. These are questions for your legal and compliance teams and the vendor, not a conclusion this page can give.

Can midPoint manage identities in Azure-hosted systems such as Entra ID?

Yes, the documented connectors include Microsoft Entra ID through the Graph API, along with LDAP, Active Directory, SCIM2 and SCIMv1. midPoint talks to Entra ID the same way it talks to other targets, through ConnId connectors that are Java code speaking the target's protocol. Confirm the connector version against your Entra ID features, including licensing needs, consent and service principal setup, and test provisioning on a non-production tenant before cutover. For any Azure-hosted application without a supported connector, check the integration catalog, where status ranges from supported to community and experimental, and plan for building or testing a connector yourself.

Does midPoint replace our single sign-on provider?

No. Evolveum states that midPoint is an identity management system, not an access management or SSO server, and it does not implement the server side of OAuth2, OpenID Connect or SAML. Its own user interface can authenticate against external SSO services. If Omada is currently your only identity tool in that role, you will need a separate identity provider such as an existing Entra ID or self-hosted SSO product. Confirm this split in the architecture review before the budget is approved, because it changes the scope and the team that runs the stack.

How DeployOpen deploys midPoint under a sovereignty constraint

DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted midPoint inside the client's own infrastructure or inside an EU provider's infrastructure that the client selects and controls. The sovereignty question is answered by where the workload, the central repository and the backups physically run and who holds administrative access to them, so the first deliverable is a written placement decision: the hosting location, the operator, the named administrators and the list of systems that will hold personal data. Work is agreed as a fixed-scope engagement with scope, deliverables and timelines confirmed in writing before any work starts. Ongoing support, upgrades and continuous testing can follow as an optional retainer.

The implementation covers the parts that determine residency in practice: a PostgreSQL repository on a separate database server in the chosen region, midPoint nodes on Linux or Docker, a sticky HTTP load balancer and the connectors that reach HR sources and target systems. Clients should confirm which midPoint release they will standardize on, since midPoint 4.8 (Curie) is the long-term support line and the Java version depends on the release, and DeployOpen will document that choice together with backup, restore and upgrade procedures. Confirm also which connectors are supported, as opposed to community or experimental, for each target system before scoping.

DeployOpen prepares systems, controls and evidence for compliance assessments, including configuration baselines, access and administration records, backup and restore test results and data flow diagrams that show where personal data is stored and accessed. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments, so the client should ask the assessor early which evidence format it expects and ask DeployOpen to scope the evidence pack against that request. The cost of this work is the engineering effort in the written scope, and any recurring cost is the retainer, the client's hosting and the staff who operate the platform.