Replacing Microsoft Identity Manager on premises without Entra ID Governance
If your Microsoft Identity Manager (MIM) 2016 estate must stay on premises, in an air-gapped network or under EU control, the main open-source option is a self-hosted midPoint deployment in your own infrastructure, with Apache Syncope as a narrower fit for synchronization-heavy estates. Both run without a license fee, so the decision rests on which functions you actually need to replace. MIM's extended support ends in January 2029, which gives you a finite window to decide, not an immediate deadline. The deciding question is how much governance you need beyond synchronization. midPoint covers provisioning and deprovisioning, role-based access control, auditing, self-service access requests and password reset, simulations against production data, and role mining. Apache Syncope focuses on provisioning, ConnId connectors, an end-user UI and a REST API, and it is a simpler fit when you mainly move identities between directories and run self-service password reset. If your current MIM use includes approvals and certification campaigns, list those workflows now and test them against each candidate before you commit.
Start with an inventory of what MIM does today: management agents, rules extensions, Portal workflows and any attestation activity. Map each item to a midPoint capability (resources, object templates, roles, certification campaigns) or to a gap you will have to fill with custom code or a process change. Confirm the connectors you need with the vendor documentation, since midPoint's connector catalog ranges from supported to community and experimental status. Plan the hosting footprint with the system requirements for the midPoint version you select, including Java and PostgreSQL versions, and confirm the release's support end date before standardizing on it. Air-gapped delivery adds work that is easy to underestimate. Every container image, Java artifact, connector and dependency must be staged through an approved internal path, and each package crossing the boundary needs an integrity check that can be shown to an auditor. midPoint does not implement the server side of OAuth2, OpenID Connect or SAML, so authentication for administrators and end users must be designed against your existing SSO. Compliance controls for your sector are a question for your assessor, not a product feature: midPoint can support the evidence you need, but it does not satisfy a regulation on its own.
What an on-premises or air-gapped provisioning stack must do
A provisioning stack that stays on premises or inside an air-gapped network has to meet the same control expectations as any other system in its boundary. The cards below set out the requirements that shape a midPoint or Apache Syncope design, and what to check against your own regulatory scope before you commit.
Identity data stays inside the boundary
Every identity record, role assignment, audit entry and connector credential sits in the repository and task store of the platform. For a midPoint deployment that means the PostgreSQL database, the application nodes and the backups all run inside your boundary, with no outbound calls to a vendor cloud for licensing or telemetry. Confirm in writing which components phone home, including any update checks, and which logs leave the network. Document where the connector secrets are kept and who can read them.
Administrative access controlled inside the boundary
Administrators of the provisioning platform hold the keys to every connected directory, so their access is a boundary control in its own right. midPoint is an identity management system rather than an SSO server, so administrator sign-in must be wired to an authentication service you operate and approve. Decide which roles can change resource definitions, mappings and connector settings, and require a second review for those changes. Ask whether the platform's own UI can be restricted by role without relying on an external proxy.
Packages verified before crossing the boundary
An air-gapped stack receives its software through a transfer process, so every container image, Java artifact, connector library and operating system package needs a documented integrity and authenticity check before it is imported. NERC CIP-013-2 requires supply chain procurement processes to address verification of software integrity and authenticity for vendor software and patches, and the same discipline applies to open-source components you bring in. Record the source, the hash or signature check, and the approver for each transfer. Keep the mirror or private registry as the only path into the enclosure.
Vendor remote access through an intermediate system
If a vendor or integrator needs to reach the platform, NERC CIP-005-7 expects Interactive Remote Access to high and medium impact BES Cyber Systems to pass through an Intermediate System, use encryption and require multi-factor authentication. The standard also expects methods to detect and disable active vendor remote access sessions. Map this to your own deployment: a jump host, session recording and a documented kill procedure. Confirm with your compliance lead whether CIP-005-7 applies to your systems at all before you design to it.
Patching the platform without internet access
Patch cycles in an isolated network depend on a repeatable path for operating system updates, Java runtime releases, PostgreSQL minor versions and midPoint upgrades. Feature and long-term support releases of midPoint have different support end dates, so your patch plan should name the version you run and the date its support ends. Test each upgrade against a copy of production configuration before it crosses into the enclosure. Keep a rollback package for the database and the midPoint home directory, and record who signs off each change.
Frameworks to check for applicability
Three frameworks often come up in these projects, and each applies only under certain conditions. NIST SP 800-82 Rev. 3 is guidance for operational technology security, relevant when the provisioning stack serves industrial control environments. The CMMC program rule in 32 CFR Part 170 applies to defense contractors who handle controlled information, and FedRAMP scope under M-24-15 covers cloud services used by federal agencies. Ask your compliance team which of these, if any, reach your systems before you map controls to the platform.
Where midPoint does not replace MIM or the Entra ID stack
midPoint does not replace the sign-in layer that MIM depends on. 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. The MIM Portal and any Entra-integrated sign-in therefore need a separate identity provider in the target design. Before the move, list every application that authenticates users through the MIM Portal or relies on Entra ID for sign-in, and confirm which identity provider will serve each one. midPoint's own user interface can authenticate against an external SSO service, but that is a configuration to test, not a substitute for a sign-in product.
Connector coverage decides how far the migration can go. midPoint reaches target systems through ConnId connectors, and the documented set includes LDAP, Active Directory, CSV, DatabaseTable, ScriptedSQL, Microsoft Entra ID through Graph API, SCIM2 and SCIMv1. Further connectors in the integration catalog range from supported to community and experimental status. Each MIM management agent must be matched to a ConnId connector with a support level your organization accepts, and any agent with no match needs a custom connector or a different route. Check the status of each connector in the Evolveum connectors documentation and record the decision per system in the inventory.
Entra ID Governance features are not reproduced by midPoint. Organizations that use Entra ID Governance services, such as its access reviews and entitlement management, should not assume midPoint covers them one for one. midPoint provides certification campaigns, approvals and role-based access control, but its feature set differs from the cloud service. List the Entra ID governance capabilities your auditors or business owners rely on today, then confirm with Evolveum and in a proof of concept whether each one has a midPoint equivalent or needs a process change. Any gap that remains should be written into the risk register with an owner.
How to deploy midPoint inside an air-gapped network
This sequence takes midPoint from an offline artifact set to a tested, multi-node deployment inside a network with no internet route. Each step ends with a check you can record as evidence for your own controls.
Confirm the Java version and release line
Pick the midPoint release line before anything is downloaded, because the release line sets the Java runtime. midPoint recommends Java 25 for version 4.11 and later (Java 21 supported) and Java 21 for 4.10 and older (Java 17 supported). Support dates also matter: midPoint 4.9 support ends 18 October 2026, midPoint 4.8 (Curie) is a long-term support release supported until 17 October 2028, and midPoint 4.10 (Braille) is supported until 26 November 2027. Confirm the chosen line with Evolveum, and record the Java version and release in your change record. The check is a signed decision record that names the release, the JDK and the support end date you accepted.
Build the offline artifact set
Assemble everything the air-gapped network needs in one staging area, outside the isolated boundary. Choose between Docker images and a Linux virtual machine image, depending on how your platform team runs workloads. Include the midPoint distribution or images, the JDK, PostgreSQL packages, the operating system packages, and the ConnId connector archives you intend to use. Store checksums beside each file and keep the manifest under version control. The check is a manifest listing every artifact, its version and its SHA-256 checksum, reviewed by a second person before transfer.
Mirror container images to a private registry
If you run midPoint from Docker images or on Kubernetes, load the images into a private registry inside the isolated network. On Kubernetes, the kubeadm tooling can list and pull control plane images in advance, and the --image-repository flag points kubeadm init at a private registry, so the same pattern applies to every node. Scan the images with your approved scanner before they enter the registry, and tag them by digest. The check is that every node pulls from the internal registry and that a pull from an external address fails in your test network.
Install PostgreSQL on a separate database server
midPoint uses PostgreSQL as its native repository database, and the system requirements recommend running it on a separate database server rather than on the midPoint host. Install the PostgreSQL packages from your offline set, create the midPoint database and a dedicated role with only the rights midPoint needs, and enforce TLS between the application and the database. Back up the database on your own schedule and test a restore. The check is a successful connection from a midPoint node to the database, plus a documented restore test on a separate host.
Configure the load balancer and shared database for multi-node runs
For more than one midPoint node, place a sticky HTTP load balancer in front of the nodes so a user session stays on one node. All nodes share the central database. The system requirements also describe cache invalidation between nodes over HTTPS and Quartz for distributed task scheduling, so confirm that each node can reach its peers on those paths and that the scheduler runs on one cluster-wide basis. Keep the load balancer's health checks on the midPoint status endpoint your release documents. The check is a node failover test in which one node is stopped during a user session and the session recovers without data loss.
Import and test connectors against a non-production target
Import each ConnId connector you need, such as LDAP, Active Directory, CSV, DatabaseTable, SCIM2 or Microsoft Entra ID (Graph API), and check its status in the connector documentation. Treat connectors marked community or experimental as software you must test and maintain yourself. Point each connector at a non-production target that mirrors the production directory schema, and run create, update, disable and delete operations with a test account set. Record the result of each operation in your test log. The check is a signed test report per connector showing that every lifecycle operation completes and that unexpected changes do not reach production systems.
Run simulations against production data before switching
midPoint can simulate policy and provisioning changes against production data, which lets you see what would change without writing to the target systems. Run the simulations on a copy of production data inside the isolated network, review the projected changes with the owners of each system, and resolve every unexpected change before go-live. Keep the simulation output as evidence of the change review. The check is a signed review of the simulated changes, with each exception either fixed or accepted by its system owner in writing.
Schedule patch intake through a verification step
Every midPoint release, connector update, JDK patch and PostgreSQL patch enters the network through the same controlled path. Verify the checksum and signature of each file against the vendor publication, scan it, test it in a staging environment, and then promote it. This matters most for an isolated boundary, because the verification step is where you show that software was checked before it crossed the boundary. Map this process to the supply chain controls your regulator or framework requires, and confirm the requirements with your compliance lead. The check is a written patch intake procedure with a log entry for each artifact that crossed the boundary in the last cycle.
Which deployment shape fits each environment
In a fully air-gapped network, midPoint, its PostgreSQL repository, the Java runtime and every connector arrive by controlled media and nothing is fetched at install or update time. Operations change most here: container images, Maven artifacts and operating system packages are mirrored into an internal registry or repository, and each update is a new verified transfer rather than a routine pull. Kubernetes clusters can be built without internet access by pulling control plane images in advance and pointing kubeadm init at a private registry, which shows the pattern teams follow.
- Offline installation: Build a bill of materials for midPoint, Java 21 or 25 as your version requires, PostgreSQL and each ConnId connector, then stage them in the enclave.
- Private registry: Host container images and packages internally so nodes never reach public repositories.
- Manual verified transfer: Check hashes and signatures of every package on the outside before it crosses the boundary, and record the check.
- Local retention: Keep the install media, configuration, audit logs and database backups inside the enclave.
- Confirm with security and legal: Ask whether the boundary rules treat connector code and update bundles as vendor software that needs integrity verification.
Confirm with your security team how transfers are approved and how vendor software integrity is verified before any update is scheduled.
An EU-controlled deployment keeps identity data, the midPoint application and its administrators inside EU locations, whether in your own data center or a private cloud operated under your control. midPoint is licensed under EUPL-1.2 with Apache 2.0 as a secondary license, so no license terms depend on a non-EU provider. Control is mainly an operational question: who can reach the servers, who holds the encryption keys and where backups are kept. The software itself does not decide data residency.
- Data location: Keep the PostgreSQL repository, logs and task state in EU facilities, including replicas and backup copies.
- Administrator access: Limit midPoint administrator and database administrator roles to staff located in the EU and record who holds them.
- Keys and backups: Your organization holds the database encryption keys and backup encryption keys, not a vendor.
- Support access: If you buy an Evolveum subscription, agree in writing how remote access for support is granted, logged and time-limited.
- Confirm with legal: Ask counsel whether any hosting, support or telemetry arrangement moves personal data outside the EU.
Before relying on this model for a regulated process, ask legal and your data protection officer to review the data map and the support access arrangement, since that review is your own assessment.
In a hybrid model, midPoint runs on premises and reaches cloud targets through connectors. The documented Microsoft Entra ID connector uses the Microsoft Graph API, so provisioning decisions, the authoritative identity source and the audit trail stay in your environment while Entra ID receives the account changes. Connectivity, credential handling and outbound rules become the main operational concerns, because a cloud target outside your control is still a dependency for every change.
- Connector scope: Limit the Graph API permissions to the objects and operations midPoint needs, and document them.
- Credentials: Store the service principal secret or certificate in a local vault, rotate it on a schedule and keep rotation evidence.
- Outbound paths: Allow only the required endpoints through the firewall or proxy and log every connection.
- Failure handling: Define what happens when the cloud target is unreachable, including retry, queueing and manual review.
- Confirm with the security team: Ask whether the regulator or contract treats the cloud tenant as in scope, and how it is classified in your risk register.
A hybrid design does not by itself satisfy any regulator, so have your compliance and security leads map each control to this architecture before go live.
What auditors and regulators ask to see
Auditors and regulators assessing a self-hosted provisioning platform look for proof that identity data stays where the organization says it does and that every component is known, verified and recoverable. The cards below cover the artifacts that connect those claims. DeployOpen prepares these for assessment, but independent auditors and certification bodies issue any audit reports or certifications.
Architecture and data flow diagram
This diagram shows every system that holds or moves identity data: midPoint nodes, the PostgreSQL database server, connectors, directories, HR sources and any sync paths to cloud services. For an air-gapped or EU-controlled design, it must show the boundary explicitly and mark which flows cross it. Check that the diagram matches the running configuration, not the design from the start of the project, and that each data store lists its physical or virtual location.
Package and patch verification records
Every installer, container image, connector JAR and patch that crosses into the isolated network needs a record of where it came from, its checksum or signature, who approved it and when it was imported. This is the evidence behind NERC CIP-013-2 supply chain expectations for verifying software integrity and authenticity. Keep these records with the transfer logs for each import media, so the reviewer can trace any installed component back to an approved source.
Connector inventory with support status
List every ConnId connector in use, with its version, the target system it reaches, its support status in the Evolveum catalog and the owner responsible for patching it. Community and experimental connectors need a documented risk acceptance, because their maintenance may not match a supported connector. Auditors use this list to confirm that no connector runs unmanaged, and that custom Java connectors have source control, testing and a named maintainer.
Access and admin logs for midPoint and PostgreSQL
Collect administrator logins, role and resource changes, task executions and database connections from both midPoint and PostgreSQL, and forward them to a log store the platform team cannot silently edit. Reviewers ask who changed a provisioning rule, who ran a bulk operation and whether database superuser access was used. Confirm retention periods with your assessor, since the log retention setting is a policy decision rather than a product default you can assume.
Backup and restore test records
A backup is only evidence if a restore has been performed. Keep dated restore tests that rebuild a midPoint node and its PostgreSQL database in a separate environment, record the time taken, the data checked and the defects found. Include the encryption and off-site copy arrangements for the backups. Ask your assessor which recovery objectives they expect you to document, because those targets set how often the tests must run.
Vendor remote access session controls
When an outside support engineer or vendor reaches the system, the access must pass through a controlled intermediate point with encryption and multi-factor authentication, and sessions must be detectable and terminable. NERC CIP-005-7 sets this expectation for Interactive Remote Access to high and medium impact systems. Record each vendor session, its approver, its start and end times and the method used to disable it, and confirm with your assessor whether your environment falls under that standard.
What a self-hosted midPoint deployment costs and who pays for what
The midPoint software itself carries no license fee. midPoint is dual-licensed under EUPL-1.2 and Apache 2.0, and Evolveum states it has no enterprise edition, so the cost of a self-hosted deployment sits in the components around it. You pay for the Linux virtual machines or hosts that run midPoint, a PostgreSQL database on its own server (the project recommends a separate database server), and a sticky HTTP load balancer if you run more than one node. Java 21 is the recommended runtime for midPoint 4.10 and older, and Java 25 for 4.11 and later, so confirm the runtime licensing and patch cadence for your platform. Most of these costs are recurring infrastructure, and they rise with the number of nodes and the size of the identity store. Ask your infrastructure team to price them against your existing hypervisor or cloud contracts, not against a new purchase.
The largest one-time cost is implementation work. Someone must build ConnId connector configurations for each connected system, write object templates and mappings that replace MIM's metaverse attribute flows, and migrate the logic in MIM management agents and any custom rules extensions. Effort depends mainly on the number of connected systems and how much custom MIM code exists, so ask for a fixed-scope written plan that lists each connector, each rules extension and the test cases for each before work starts. Parallel running against Active Directory and the testing that goes with it also belong in the one-time column. Evolveum's Product Support and Platform Subscriptions are optional recurring costs, and the supplied material lists no prices for them, so request written quotes from Evolveum and from any implementation partner. Ask whether a subscription covers the 8x5 or 24x7 SLA you need, and whether it includes patches for the release line you choose, such as 4.8 (Curie), which is supported until 17 October 2028.
Ongoing operations are the cost most often underestimated. Every midPoint upgrade, PostgreSQL patch and Java update needs a test cycle against your connectors, and connectors for systems that change their APIs need maintenance on the same schedule. Plan for monitoring, backup and restore tests of the PostgreSQL repository, and a staff role that owns the midPoint configuration. Ask the implementer for a written statement of which tasks are one-time and which are recurring, what the handover documentation covers, and whether retainer support is included or billed separately. Then compare that recurring total with the MIM support cost you retire, including Windows Server, SQL Server and SharePoint licensing, so the business case rests on a complete figure.
Questions buyers ask before they hire help
Can midPoint run fully air-gapped?
Yes, midPoint can run in an air-gapped network, deployed from Docker images or on a Linux virtual machine, but the offline build and patch process has to be designed on purpose. Someone must pull the images, packages and connector artifacts through an approved transfer path, verify them, and move them across the boundary on a schedule. The midPoint system requirements list PostgreSQL as the native repository and recommend a separate database server, so plan those packages as well. Confirm the exact artifact list and update procedure with Evolveum and against your own environment before you commit to a design.
What does a self-hosted midPoint deployment cost?
midPoint has no license fee, because its code is published under the EUPL-1.2 and Apache 2.0 licenses. The recurring costs are infrastructure (Linux hosts, PostgreSQL, backup and monitoring), staff time to operate it, and an optional support subscription from Evolveum. Evolveum offers Product Support subscriptions with an 8x5 next-business-day or 24x7 SLA, and Platform Subscriptions that add feature development, but its support page lists no prices, so request a quote. The one-time costs are design, connector and rules work, testing and migration. Ask any implementation partner for a fixed quote tied to a written scope listing systems, rules and deliverables.
How long does a move from MIM to midPoint take?
The duration depends mainly on how many connected systems you have, how complex the attribute flows and rules are, and how many approval or certification workflows must be rebuilt. Parallel running against a test directory, and the change windows you can get for switching off MIM sync runs, also set the pace. No single duration applies to every estate, so the timeline should be part of the written scope, with milestones tied to each connected system. Ask for the inventory first, because the inventory determines the estimate.
Can our own team do the migration without outside help?
A capable team can learn midPoint, and Evolveum publishes documentation and training, so in-house work is possible for simple synchronization. Connector configuration, rules and object template design, and the cutover from MIM usually need staff with prior midPoint or ConnId experience, because mistakes in attribute mappings can change access for many users. Consider a hybrid model in which an experienced partner designs and reviews the critical parts while your team operates the platform. Whichever model you choose, agree on who owns each deliverable in writing.
Does midPoint replace Entra ID Governance access reviews?
midPoint provides certification campaigns and role-based access control, so it can cover access review requirements for on-premises systems, but whether it satisfies your specific review obligations must be confirmed against your own requirements. Check which systems are in scope for reviews, who must sign off, how evidence is retained, and whether reviews must cover cloud applications that midPoint connects to through its connectors. Your auditors should confirm the design. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports or certifications.
What do we need to provide for the engagement?
The most important inputs are a system inventory covering directories, applications, databases and their owners, access to test targets that mirror production, and documented change windows. You also need named approvers for role definitions, attribute mappings and cutover decisions, because those decisions cannot be delegated to the implementation team. Expect to provide service accounts with the least privilege each connector needs, plus a written list of existing MIM management agents and rules extensions. Missing inputs are the most common reason fixed-scope timelines move, so confirm them before scope is signed.
How does midPoint fit with our single sign-on?
midPoint is an identity management system, not an access management or SSO server, so it does not act as an identity provider for user sign-in. You need a separate identity provider, such as one already used for your applications, and midPoint's own user interface can authenticate against an external SSO service. midPoint does not implement the server side of OAuth2, OpenID Connect or SAML. Confirm the authentication design, including how MFA is enforced and how administrator sessions are protected, before deciding which identity provider to use.
How DeployOpen deploys midPoint under this constraint
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted midPoint inside your own infrastructure, whether that is an on-premises data center, a private cloud or an air-gapped network. The work starts with a written scope that defines which connected systems, identity sources and governance functions stay on premises.
How we scope
- We inventory the MIM management agents, synchronization rules and Portal workflows that the replacement must cover.
- We document which connected systems, including Active Directory and HR sources, must remain on premises or inside EU control.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any build work begins.
How we build
- We deploy midPoint on Linux in your environment with PostgreSQL on a separate database server, following Evolveum's system requirements.
- We build ConnId connector configurations for each target system and test provisioning and deprovisioning against non-production data first.
- For air-gapped sites, we plan how packages, images and connector artifacts are verified and carried across the isolated boundary.
How we hand over
- We run midPoint and MIM in parallel against Active Directory before switching off MIM synchronization per connected system.
- We document architecture, object templates, resource configurations, backup procedures and upgrade steps for your own operations team.
- We prepare the control and evidence records your compliance assessors may ask for, while independent auditors issue any audit conclusions.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing like the initial engagement.
- Upgrades are planned against midPoint's published support windows, so your team knows when each release leaves support.
- Confirm with Evolveum whether a Product Support subscription fits your operating hours before deciding who carries second-line support.
