Open-source alternative to Microsoft Entra ID Governance: the short answer
If your Entra ID P1 or P2 estate needs lifecycle workflows, access reviews and entitlement management, midPoint is the main open-source option for that module. It is an identity governance and administration platform, not a single sign-on server, so it sits beside your sign-in layer rather than replacing it. Keycloak or authentik would still handle application login, while midPoint would handle joiner, mover and leaver processes and certification campaigns.
The licensing question drives much of the decision. Microsoft Entra ID Governance requires an active prerequisite subscription with the Entra ID P1 or P2 service plan, and it is also included in Microsoft Entra Suite and Microsoft 365 E7 according to Microsoft's licensing fundamentals. Microsoft also says it will not add new identity governance and administration features to the Entra ID P2 SKU, so capabilities such as Lifecycle Workflows, access reviews scoped to inactive users, machine-learning assisted reviews and auto assignment policies sit on the Governance side of the line. Confirm with your Microsoft account team which of these features your current agreement actually includes before you model costs.
This page covers the Governance features that matter most for replacement: lifecycle workflows, advanced access reviews and entitlement management. Check which of these your organization uses today, and which connected systems (Active Directory, Entra ID through the Graph API connector, SCIM targets or databases) would need to be wired into midPoint. Those connector paths, and whether midPoint covers each workflow your auditors expect, are the questions to settle first.
Which Entra ID Governance capabilities midPoint covers and where it does not
This table maps Entra ID Governance features that require the add-on to midPoint capabilities and ConnId connectors. Treat each midPoint entry as a question to confirm, because feature depth changes between releases. The main takeaway is that provisioning and connector coverage map well, while Microsoft's request portal and machine-learning review assistance need a decision before migration.
| Capability | Entra ID Governance | midPoint coverage |
|---|---|---|
| Joiner, mover and leaver lifecycle workflows | Lifecycle Workflows, licensed under Entra ID Governance | Lifecycle handling through midPoint policies and provisioning. Confirm trigger types and notifications in your release. |
| Access reviews scoped to inactive users | Requires Entra ID Governance, not Entra ID P2 | Certification campaigns are in scope. Confirm whether inactivity-based scoping exists in your planned release. |
| Machine-learning assisted access reviews | Requires Entra ID Governance | Not documented in the sources used here. Treat as a gap and plan manual or scripted review support. |
| Entitlement management auto assignment policies | Requires Entra ID Governance | Role and assignment rules in midPoint. Confirm the rule types match the auto assignment behavior you rely on. |
| Custom extensions in entitlement management | Requires Entra ID Governance | No direct equivalent. Any hook into external workflows usually means custom development. Confirm with Evolveum. |
| Access package request portal | Entra access package UI for requests and approvals | midPoint provides its own self-service interface, not Entra's access package portal. Users will see a different experience. |
| Connected application provisioning | Provisioning to SaaS apps through Entra connectors | ConnId connectors include SCIM2, LDAP, Active Directory, CSV and DatabaseTable. Check each target app's status in the catalog. |
| Microsoft Entra ID as a source or target | Native Entra ID tenant data and governance | Entra ID Graph API connector is documented. Confirm read and write scope, attributes and throttling in your tenant. |
Which open-source option fits which governance need
Entra ID Governance bundles joiner, mover and leaver workflows, access reviews and entitlement management into one licensed add-on. In open source, these jobs are split across a governance engine, the authoritative directory and the SSO layer, so each card below answers a different part of that split.
midPoint for joiner, mover and leaver
midPoint is the primary option for lifecycle automation. It reads authoritative HR or directory data, assigns roles and entitlements, and removes access when people leave or change departments. Because midPoint is a governance engine rather than a login server, it works alongside whatever handles sign-in. Check which target systems you need connectors for, since connector status ranges from supported to experimental. Also confirm your team can maintain the role model it depends on.
midPoint certification campaigns
Periodic access reviews map to midPoint's certification campaigns, where managers or application owners confirm or revoke entitlements. This covers much of what Entra ID Governance calls access reviews, but the trade-off is that you build the review scope, reviewer logic and reporting yourself. Test campaigns on a non-production copy with a realistic set of roles before you rely on the outcomes for audit evidence. Confirm which review features your chosen release provides.
FreeIPA as an authoritative source
FreeIPA combines directory, Kerberos, certificates and Linux identity in one platform, and it can establish trusts with Microsoft Active Directory. It fits organizations whose Linux and UNIX hosts need central identity and whose governance decisions start from that directory. Its trade-off is scope: it is a directory and identity platform, so joiner and leaver logic still needs a governance layer such as midPoint to act on it.
Samba AD as an authoritative source
Samba AD fits when the Windows-centric estate still runs Active Directory and the goal is to keep that directory as the source of truth while adding governance. Consider it when Windows domain services remain in scope. Confirm that its attribute model and provisioning hooks match what your midPoint connectors expect before you commit the design.
Keycloak or authentik for SSO
Keycloak and authentik handle sign-in, federation and token issuance for applications. They do not run access reviews or lifecycle workflows that resemble Entra ID Governance. Pair them with a governance platform so that access granted in midPoint takes effect at the application login. Keycloak is Apache 2.0 licensed and authentik's core is MIT licensed, so confirm each product's current licensing before you deploy.
Java and PostgreSQL platform decisions
midPoint recommends Java 25 for version 4.11 and later and Java 21 for 4.10 and older, and uses PostgreSQL as its native repository, ideally on a separate database server. Multi-node deployments need a sticky load balancer, a shared database and distributed task scheduling. Plan the JVM upgrade path, database operations and high availability with your platform team before choosing a release, because these choices drive most of the run cost.
How midPoint sits alongside Entra ID and your SSO layer
midPoint manages identities, roles and resources, and it provisions accounts to target systems through ConnId connectors. It does not sign users in. Evolveum states that midPoint is an identity management system, not an access management or SSO server, and that it does not implement the server side of OAuth2, OpenID Connect or SAML. Its own user interface can authenticate against an external SSO service. That means the governance layer and the sign-in layer are separate decisions, and the architecture should name which system is authoritative for each one before any connector is built.
If Microsoft 365 stays, Entra ID remains the sign-in source for those workloads, and midPoint should not try to replace it. The practical design question is which directory midPoint treats as the source of truth for joiners and leavers. Many teams keep the HR system or Active Directory as the authoritative feed and let midPoint write to Entra ID through the Microsoft Entra ID (Graph API) connector. Confirm with your Microsoft licensing contact which Entra features your tenant still needs, and confirm the connector's supported operations in the Evolveum connectors documentation before you rely on them.
Applications outside Microsoft 365 receive governed accounts in one of two ways. Some get accounts written directly through ConnId connectors such as LDAP, database tables or SCIM2. Others, including web applications that expect federated sign-in, read their identities from the SSO layer, which might be Keycloak, authentik or Entra ID. In that case midPoint manages the account and its entitlements, and the SSO provider handles the login and the token. A check to run during design is to map each application to one of these paths and record where a leaver's access is revoked, because a disabled account in the directory does not automatically end an active session in the SSO layer.
Moving joiner, mover and leaver workflows and review campaigns to midPoint
This sequence moves identity lifecycle processes and access certification out of Entra ID Governance and into midPoint, one controlled stage at a time. It ends with midPoint running joiner, mover and leaver processes and review campaigns in production, and with Entra ID Governance licensing no longer needed.
Inventory current lifecycle workflows and access packages
Your identity team lists every Lifecycle Workflow, access package, entitlement management policy and access review that Entra ID Governance runs today, along with its trigger, approvers and target applications. Export the user list from the Entra admin center, then export groups and access package assignments through the Microsoft Graph API or PowerShell, since the CSV download covers users, not every governance rule. Rules such as custom extensions, auto assignment policies and inactive-user review scopes must be written down by hand. The step is done when every rule has a row in a signed-off inventory that names its business owner.
Define the authoritative source of identity
Decide which system is the source of truth for employee records, typically an HR system or an on-premises directory, and document how joiner, mover and leaver events reach midPoint from it. Confirm with HR and the identity team which attributes drive access decisions, such as department, manager and employment status, and where each attribute is mastered. Agree how conflicting values are resolved before midPoint is allowed to change any account. The step is done when a written source-of-truth map exists and has been approved by the owners of each attribute.
Model roles, resources and policies in midPoint
Your platform engineers translate the inventory into midPoint objects: resources for each target system, roles for job-based access, and assignment rules that tie attributes from the authoritative source to those roles. Keep the model small at first and map each Entra ID access package to one role or resource so that the outcome can be checked against the original. Confirm the midPoint release you will run, since the releases page lists support end dates for each version. The step is done when a test population gets the same entitlements in the model that it has in Entra ID.
Build connectors and test provisioning in non-production
Configure the ConnId connectors that midPoint needs for your targets, such as LDAP, Active Directory, SCIM2 or the Microsoft Entra ID (Graph API) connector, and confirm each one against the connector documentation's support status. Stand up a non-production midPoint with its own PostgreSQL database, run synthetic joiner, mover and leaver scenarios, and check that accounts are created, changed and disabled as the model predicts. Record each test with its expected and actual result. The step is done when every scenario passes and the failures are either fixed or accepted by the owner.
Run certification campaigns in parallel
Configure midPoint certification campaigns for the same populations that Entra ID access reviews cover today, and run them alongside the existing reviews without acting on midPoint's results yet. Compare reviewer decisions from both systems and investigate every disagreement, since differences usually point to a missing attribute, a role mapping gap or a reviewer scope that was not carried over. Keep a dated record of these comparisons as evidence for your own assurance work. The step is done when the disagreements are explained and the reviewers who will use midPoint have completed a trial campaign.
Cut over production provisioning to midPoint
Move production joiner, mover and leaver processing to midPoint in a planned change window, starting with a small group of users and extending the scope once results match. Keep Entra ID Governance workflows disabled but not deleted during the first cycle so you can roll back. Monitor midPoint task results and the target systems for failed provisioning, and confirm that leavers lose access on the expected timeline in your own processes. The step is done when a full cycle of production joiners, movers and leavers has been processed without manual correction.
Retire Entra ID Governance and its licensing
Once production runs cleanly, delete or disable the Entra ID Governance workflows, access packages and reviews, and confirm the change with the owners named in your inventory. Ask Microsoft licensing or your reseller to confirm which subscriptions remove the Entra ID Governance add-on from your tenant, since Governance is also included in Microsoft Entra Suite and Microsoft 365 E7. Archive the final exports and your midPoint configuration in your own records. The step is done when the governance licence is removed or scheduled for removal, and the archived evidence is stored where your compliance team can retrieve it.
Deployment choices for midPoint: VM, Docker or multi-node
A single virtual machine is the simplest model for a first midPoint environment, such as a pilot covering one joiner, mover and leaver process or one certification campaign. midPoint runs on Linux in a virtual machine, and the platform team installs the Java runtime, the midPoint application and a PostgreSQL database. midPoint's system requirements recommend Java 25 for version 4.11 and later, with Java 21 supported, and Java 21 for 4.10 and older, with Java 17 supported. The requirements also recommend running PostgreSQL on a separate database server where possible, so even a pilot may need two machines.
- Java version: Match the JDK to the midPoint release you install, not to whatever runtime the operating system ships.
- Database placement: Keep PostgreSQL on its own server if the environment allows it, since the requirements recommend separation.
- Patching: Plan maintenance windows for the OS, Java and midPoint together, because a single node has no peer to take over during updates.
- Backups: Back up the PostgreSQL database and the midPoint configuration directory on a schedule you can test.
- Growth limits: Moving from one node to several later requires shared database and cache design, so note this in the pilot plan.
Before planning, confirm the current midPoint release and its support end date with Evolveum, because the version determines the Java runtime you must provision.
midPoint can also run from Docker images, which suits teams that already build and operate container hosts. The image still needs a reachable PostgreSQL database and the correct Java runtime for the chosen release, so containerization changes packaging and deployment steps rather than the platform's dependencies. Containers make it easier to pin a release, roll back to a prior image and keep the environment definition in version control. They do not remove the need to plan storage for configuration and to protect database credentials.
- Image pinning: Reference an exact midPoint version tag rather than a floating tag, so upgrades happen on purpose.
- Runtime match: Confirm the Java version inside the image matches the release recommendation for 4.11 and later or for 4.10 and older.
- Persistent configuration: Mount configuration and any custom files from persistent storage so a container replacement does not lose local changes.
- Database connectivity: Keep PostgreSQL outside the container lifecycle, with credentials supplied through your secrets tooling.
- Host operations: Define how the container host is patched, monitored and restored, since the container layer adds its own failure modes.
Before adopting this model, check the image tags and documentation on Evolveum's release and installation pages for the version you plan to run.
Multi-node deployments serve production identity workloads that need more capacity or continuity during node failure or maintenance. midPoint's system requirements describe the pattern: several midPoint nodes sit behind a sticky HTTP load balancer, all nodes share one central database, and cache changes are invalidated between nodes over HTTPS. Distributed task scheduling uses Quartz, so scheduled reconciliation and certification jobs are coordinated across the cluster rather than run blindly on each node. This model requires more design work than a single VM and should be planned with the database and network teams from the start.
- Sticky load balancing: Configure session affinity on the HTTP load balancer, as the requirements call for a sticky HTTP load balancer.
- Shared database: Use one central PostgreSQL database that all nodes reach, sized and backed up as a critical system.
- Cache invalidation: Allow node-to-node cache invalidation over HTTPS, and include it in firewall and certificate planning.
- Scheduling: Verify how Quartz clustering behaves for certification campaigns and synchronization tasks in your release.
- Upgrades: Plan rolling upgrades and check the release notes for any cluster-specific steps.
Before committing to this design, ask Evolveum to confirm the supported topology for your release and the multi-node guidance in the system requirements.
The release you choose determines both your Java runtime and how long Evolveum supports it, so version selection belongs in the deployment plan rather than after installation. midPoint 4.8 (Curie) is a long-term support release with support until 17 October 2028. midPoint 4.10 (Braille) is a feature release supported until 26 November 2027. midPoint 4.9 support ends on 18 October 2026, so it is not a sound base for a new deployment. midPoint 4.11 (Čapek) is a feature release planned for 21 October 2026. Feature releases such as 4.10 and 4.11 bring newer capabilities but require tracking of their support windows.
- Long-term support: 4.8 has the longest stated support window among the releases listed on the releases page.
- Feature release timing: 4.10 and 4.11 suit teams that need newer functions and can schedule upgrades within their support windows.
- Java alignment: Java 25 is recommended for 4.11 and later, while 4.10 and older use Java 21 with Java 17 supported.
- Planned dates: The 4.11 date is a plan on the releases page, so confirm it before scheduling a go-live.
- Support plan: Evolveum offers Product Support and Platform Subscriptions, so compare the support tier with the chosen release.
Before planning, confirm the version, its end-of-support date and the Java requirement on Evolveum's current release page.
What does replacing Entra ID Governance cost and require?
What is Microsoft Entra ID Governance licensed with?
Entra ID Governance is an add-on that requires an active prerequisite subscription with the Entra ID P1 or P2 service plan. It is also included in Microsoft Entra Suite and Microsoft 365 E7, so the cost depends on which bundle your organization already pays for. Check the Microsoft licensing fundamentals page against your current contract, because features such as Lifecycle Workflows, machine-learning assisted access reviews and auto assignment policies sit in Governance rather than P2. Microsoft has also said no new governance features will be added to the P2 SKU, so the gap is likely to widen over time.
Does midPoint have an enterprise edition I need to buy?
No. Evolveum states that midPoint has no enterprise edition and that every line of its code is published under open source licenses. The repository uses the EUPL-1.2 with Apache 2.0 as a secondary license. What you pay for is the infrastructure to run it, the people who implement and operate it, and optionally an Evolveum support subscription. Evolveum funds development through subscriptions, training and professional services, so its commercial offers are about support and roadmap influence rather than unlocking features.
What drives the cost of a self-hosted midPoint deployment?
Costs fall into five groups. Infrastructure covers application servers, which can run from Linux virtual machines or Docker images, and a load balancer if you run several nodes. The database is PostgreSQL, ideally on its own server. Connector work covers building or configuring ConnId connectors to Active Directory, Entra ID through Microsoft Graph, SCIM2 or your HR system. Process design covers joiner, mover and leaver rules and certification campaigns, which is usually the largest effort. Support subscription tiers and staff time complete the picture. Connector count, number of source systems and how much approval logic you need are the main levers.
What does the Evolveum support subscription cost and what does it cover?
Evolveum offers two kinds of subscription. Product Support covers resolution of product bugs with either an 8x5 next-business-day SLA or a 24x7 SLA. Platform Subscriptions add feature development and influence over the roadmap. The Evolveum support subscriptions page lists no prices, so request a written quote for the tier you need. Ask whether the subscription covers the database and Java runtime you run, how security patches are delivered, and whether it includes help with connector configuration. Support is optional, but if your team has no midPoint experience, a support tier is a common way to shorten the time to a stable release.
How long does a midPoint governance project usually take, and what affects it?
No fixed duration is published for midPoint projects, so treat any timeline as something to confirm in writing. The main effort drivers are the number of authoritative sources, the quality of attribute data in HR and directory systems, how many approval and certification flows the business needs, and whether you must keep Entra ID Governance running during a parallel run. Release planning also affects scope: midPoint 4.8 is a long-term support release supported until 17 October 2028, midPoint 4.10 is supported until 26 November 2027, and midPoint 4.11 is planned for 21 October 2026, so pick a version your support window covers.
Can an internal IT team run midPoint without outside help?
A team with strong directory, PostgreSQL and Java operations skills can run midPoint, but the first implementation is where most risk sits. Lifecycle rules, role design and certification campaigns need someone who understands both the business and the identity model, and connector troubleshooting needs familiarity with ConnId. Evolveum states that its developers work on midPoint full time, so the open-source community and vendor documentation are useful, yet they do not replace a delivery plan. Many organizations split the work: internal staff own the operations and business rules, while an implementation partner covers the initial build, hardening and handover.
What should I ask for in a written quote for midPoint implementation?
Ask the provider to list the fixed scope in writing: the source systems and connectors, the joiner, mover and leaver workflows, the certification campaigns, and the environments such as test, production and disaster recovery. Request the deliverables, including documentation, runbooks, backup and restore steps, and handover sessions. Confirm which Evolveum support tier is assumed, the Java and PostgreSQL versions, and how upgrades between midPoint releases are handled. Ask what is excluded, how change requests are priced, what acceptance criteria apply, and whether hardening and security testing are part of the scope or separate work.
Does DeployOpen handle midPoint implementation and what does it cover?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, which covers midPoint deployments of this kind. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support and upgrades are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. DeployOpen prepares controls and evidence for compliance assessments but does not issue audit reports or certifications.
The cost components of an open-source governance stack
The first thing to separate in any comparison is what is paid for and when. Entra ID Governance is a recurring subscription that sits on top of an Entra ID P1 or P2 prerequisite, and it continues to cost money every period until the organization retires it. The midPoint software itself carries no license fee, because Evolveum publishes every line of code under open source licenses. The recurring costs on the open-source side are everything around the software: servers or virtual machines for midPoint, a PostgreSQL database that midPoint uses as its native repository (ideally on its own database server), Java operations on the versions midPoint currently recommends, backups, patching and monitoring. Ask the vendor or your own platform team to show each of these as a separate line, with its owner and its renewal date.
The larger costs are usually one-time and labor-based, and they are where quotes differ most. Connector development covers the ConnId connectors that link midPoint to Active Directory, Microsoft Entra ID through Graph, HR sources and target applications, along with any custom connectors for systems that are not in the catalog. Process design covers joiner, mover and leaver rules, role and entitlement models, and the approval paths for certification campaigns. Testing covers non-production environments, migration of existing assignments and a parallel run against Entra ID Governance before cutover. Each of these scales with the number of source systems, target applications and workflows, so ask for effort estimates per item rather than one total.
Evolveum's support subscriptions are the main recurring vendor cost on the open-source side. Its Product Support tier covers bug resolution with an 8x5 next-business-day or 24x7 SLA, and its Platform Subscriptions add feature development and roadmap influence. The support subscriptions page lists no prices, so you must request figures directly from Evolveum, and you should also ask whether a given midPoint release line, such as the long-term support release, is covered. Internal staff time is the cost most often left out of comparisons. Plan for administrators who understand midPoint's object model, and ask any implementation partner to quote its own work separately from the subscription so the two can be compared fairly.
How DeployOpen scopes and delivers an identity governance replacement
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted midPoint inside your own infrastructure, including the joiner, mover and leaver processes and certification campaigns that Entra ID Governance currently handles. Engagements are fixed-scope, with scope and deliverables agreed in writing before work starts.
How we scope
- We inventory the Entra ID Governance workflows, access reviews and entitlement packages you actually use today.
- We agree in writing which source systems, connectors and approval paths midPoint must cover.
- We define which compliance evidence the governance processes must produce, and confirm it with your auditor.
How we build
- We deploy midPoint on Linux or Docker with PostgreSQL, sized to your confirmed Java and database requirements.
- We configure ConnId connectors for Active Directory, Entra ID via Graph API, LDAP or SCIM targets in scope.
- We test joiner, mover and leaver scenarios and certification campaigns against your agreed acceptance criteria.
How we hand over
- We document the configuration, workflows, connector settings, roles and the runbook your team needs to operate midPoint.
- We deliver the control evidence and test records agreed in the scope, so your own assessors can review them.
- We run knowledge transfer sessions with your identity and platform engineers before the engagement closes.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, sized to your written scope.
- We plan midPoint upgrades around the release and support dates published by the project, and confirm them before each change.
- We back up and restore the midPoint repository as agreed, and document how your team repeats those steps.
