Saviynt vs midPoint: which fits your identity governance
Saviynt fits when one platform must cover identity governance, privileged access, application access governance and non-human identities, and when a cloud-delivered service is an acceptable operating model. Self-hosted midPoint fits when identity governance and administration must run inside your own infrastructure, when you want no license fees for the platform itself, and when your team or a partner can operate it. Most renewals and cost reviews turn on two questions: whether privileged access and application access governance are in scope for the same program, and who will run the platform day to day.
midPoint covers provisioning and deprovisioning, role-based access control, auditing, self-service access requests, password reset and role mining. It does not cover privileged session control or the application access governance functions that Saviynt bundles, so those need separate tooling. Before you shortlist midPoint, list every privileged account class and every SaaS application that currently relies on Saviynt for access reviews, and map each one to a named owner. Any item without an owner is a scope gap, and the gap usually decides the architecture.
The operating model is the second decision. midPoint is open source with no enterprise edition, and Evolveum offers support subscriptions and professional services. Ask any candidate partner to state, in a written scope, who owns connector upkeep, midPoint upgrades, database operations and evidence for your assessors. Confirm which midPoint release line you will standardize on against the support dates in the midPoint releases documentation, since a long-term support release gives a longer runway than a feature release.
Which Saviynt alternative fits each scenario
This table matches common buyer situations to the option that fits best and the condition that makes it fit. Read each row against your own constraints, since the right answer depends on data residency, PAM needs, and how much in-house engineering you can staff.
| Scenario | Better fit | Why it fits and when it matters |
|---|---|---|
| Governance only, with identity data that must stay on-premises | Self-hosted midPoint | midPoint runs on Linux VMs or Docker in your own network, with PostgreSQL as its native repository. It matters when identity and entitlement data cannot leave your boundary and you do not need PAM in the same platform. |
| One platform for governance plus privileged access | Saviynt Identity Cloud, or midPoint plus a PAM tool | Saviynt combines governance, PAM and application access governance in one product. midPoint covers provisioning, certifications and role management, so you would pair it with a PAM product such as Teleport or JumpServer, and confirm how the two integrate. |
| Cloud-first SaaS with a small identity team | Saviynt Identity Cloud | Saviynt is delivered as a cloud service, so the vendor runs the platform. This fits when staff capacity for patching, upgrades and database operations is limited and cloud hosting is acceptable for your data. |
| Regulated environment with in-house engineering staff | Self-hosted midPoint with a support subscription | Your engineers can own connectors, workflows and upgrades, and the Evolveum support subscription adds vendor response for product bugs. This fits when you need to inspect and modify the code, and the team can track supported release lines such as 4.8 LTS. |
| Multi-system provisioning with many custom targets | Self-hosted midPoint | ConnId connectors are Java code behind a uniform interface, so custom targets can be built in-house. Confirm connector status for each target, since some catalog entries are community or experimental, and plan for development effort on each one. |
| Very large identity population | Self-hosted midPoint, after load testing | Evolveum states midPoint scales to deployments of up to 100 million identities. Your actual sizing depends on architecture, multi-node setup and task scheduling, so ask for a reference architecture and test against your own data volume. |
| Need for application access governance and non-human identity coverage | Saviynt Identity Cloud, or evaluate both carefully | Saviynt lists application access governance and non-human identity management within its platform. midPoint does not cover these as product functions, so confirm which gaps you would fill with other tooling before committing. |
How Saviynt and midPoint differ in governance scope
Saviynt delivers governance as one cloud platform, the Identity Cloud, that also covers privileged access management, application access governance and non-human identity management in the same product. midPoint is narrower by design: it is an identity governance and administration platform, and Evolveum states that it is an identity management system, not an access management or SSO server. It does not implement the server side of OAuth2, OpenID Connect or SAML. Before you commit, map every Saviynt module your team uses today to either midPoint or a named second tool, and record which ones have no owner after cutover.
midPoint is a self-hosted Java application that you run yourself. It can run on Linux in a virtual machine or from Docker images, and it uses PostgreSQL as its native repository database, ideally on a separate database server. Target and source systems are reached through ConnId connectors, so each system you integrate needs a connector that is supported, community or experimental, and some may need custom development. Confirm the connector status for each of your systems in the midPoint connectors documentation, and confirm the Java and PostgreSQL versions for your chosen release in the system requirements.
Two governance capabilities need checking against current midPoint documentation or a proof of concept, not against this page. The first is certification campaign depth: reviewer assignment, escalation, revocation handling and reporting for the reviews your auditors sample. The second is separation of duties rules and approval workflows, including how conflicting role combinations are detected and how approvals are routed. Ask a vendor or partner to demonstrate both using a copy of your own role catalog and one realistic review cycle before you decide.
Saviynt capabilities compared with midPoint
This table compares the capabilities that Saviynt describes for its Identity Cloud with what midPoint covers natively, and marks where midPoint needs other tools or a check against your requirements. Read the midPoint column for dependencies and the Saviynt column for items to confirm in writing. The main takeaway is that midPoint covers governance and provisioning, while privileged access and application access governance need separate tooling or confirmation.
| Capability | Saviynt Identity Cloud | Self-hosted midPoint |
|---|---|---|
| Provisioning, deprovisioning and lifecycle | Governs workforce, third-party and service accounts in one cloud platform. Confirm target system coverage in writing. | Covers provisioning, deprovisioning and identity lifecycle. Target coverage depends on connectors you deploy or build. |
| Role-based access control and role mining | Identity governance and administration within the converged platform. Confirm role model and mining features for your use case. | Covers role-based access control and role mining. Role design and data quality remain your team's work. |
| Self-service access requests and password reset | Confirm the request, approval and password reset workflows included in your subscription. | Covers self-service access requests and password reset. Approval workflows and branding need configuration and testing. |
| Auditing and certifications | Describes governance and audit functions in the Identity Cloud. Confirm certification campaign depth against your review cycle. | Covers auditing. Confirm certification campaign depth and evidence output against your review requirements before committing. |
| Connector coverage | Connector catalog is not detailed in the researched facts. Request the full list for your target systems. | Documented connectors include LDAP, Active Directory, CSV, database table, Microsoft Entra ID, SCIM2 and SCIMv1 through ConnId. Other connectors vary in support status and may need custom work. |
| Privileged access and application access governance | Includes privileged access management and application access governance in one platform. | Not a privileged access management product. Pair with tools such as Teleport or JumpServer, and confirm application access governance needs separately. |
| Non-human identity management | Includes non-human identity management and governs service accounts within the platform. | Manages accounts through provisioning. Dedicated non-human identity lifecycle and ownership rules need design and confirmation. |
| Single sign-on | Single sign-on is not described in the researched facts. Confirm access management features with Saviynt. | Identity management system only. It does not implement the server side of OAuth2, OpenID Connect or SAML, so pair it with a separate SSO provider. |
| Licensing and support model | Commercial subscription delivered as a cloud service. Pricing is not in the researched facts; request a written quote. | No license fees; dual-licensed under EUPL and Apache 2.0. Evolveum sells support subscriptions with 8x5 next-business-day or 24x7 SLA options, without listed prices. |
Which Saviynt functions need other tools beside midPoint
Saviynt's Identity Cloud combines identity governance with privileged access management in one platform. midPoint manages the lifecycle and entitlements behind privileged accounts, such as provisioning an administrative role, recording who holds it, and removing it when someone leaves. It does not record or broker privileged sessions, so it cannot control what an administrator does once logged in. Session control is a separate architectural layer.
- Session brokering: Keep administrator access to servers, databases and network devices behind a jump host or session broker, with midPoint managing the accounts and group memberships those sessions depend on.
- Session recording: Plan a tool that captures keystrokes or commands for audit, since midPoint's audit trail covers identity changes, not session content.
- Candidate options: Teleport and JumpServer appear in the privileged access category of this site. Validate each against your target systems, protocols and recording requirements.
- Checkout and approval workflows: Decide whether time-bound elevation is handled by the PAM tool, by midPoint access requests, or by both, and document the handoff.
- Vault and credential rotation: Confirm whether shared or root credentials move into a secrets manager, which then becomes another system to integrate.
Before you scope a replacement, confirm which privileged systems need session control and which only need account lifecycle governance.
Saviynt's application access governance covers how users receive and keep access to individual business applications, including the entitlements inside them. midPoint reaches applications through ConnId connectors, so the question is whether a connector exists for each target and how much of the application's permission model it can represent. Applications without a connector need a custom connector, a SCIM interface, or a file or database feed.
- Connector inventory: List every application with its protocol, such as LDAP, SCIM2, a database table, or a vendor API, and mark whether a documented connector covers it.
- Entitlement depth: Confirm whether the connector can read and write application roles or only account existence, because roles inside the app often drive audit findings.
- Custom connector work: Estimate the ConnId development and test effort for each gap, and ask the implementation partner to state it in the written scope.
- Role model: Map application entitlements to midPoint roles and decide where the source of truth lives for each.
- Recertification of app access: Verify that the reviews you need can be produced from midPoint data for each application.
Ask for a connector-by-connector coverage list before accepting any assumption that midPoint replaces application access governance in full.
Saviynt's platform also governs non-human identities, including service accounts and automated identities. midPoint has no dedicated concept for these, so you model them as accounts or as resources with their own owner, purpose and lifecycle attributes. The governance outcome depends on the modeling decisions made during design, not on a built-in feature.
- Ownership attribute: Require every service account to carry a named owner and a sponsor who can approve or revoke it, stored as a midPoint attribute.
- Account classification: Tag service accounts separately from human accounts so reviews and reports can filter them.
- Credential rotation: Confirm whether rotation is driven by midPoint, by the target system, or by a secrets manager. midPoint can change passwords through its connectors, but rotation schedules and secret storage are outside its core scope.
- Lifecycle on owner departure: Define what happens to a service account when its owner leaves, including reassignment, disablement and evidence retention.
- Discovery: Plan how orphaned or unknown accounts are found, through reconciliation against each target system.
Review your service account inventory with the security team before the design is final, because the ownership model is the part that most often lacks a clear answer.
Saviynt provides identity governance alongside authentication-facing capabilities for users and applications. midPoint is an identity management system, not an access management or single sign-on server. It does not implement the server side of OAuth2, OpenID Connect or SAML, so applications still need an identity provider to authenticate users and issue tokens. The architecture gains a separate component that midPoint feeds with identity data.
- Identity provider selection: Choose an IdP that supports the protocols your applications need, and confirm it can accept accounts and group data from midPoint.
- Data flow: Decide whether midPoint writes directly to the directory the IdP reads, or whether an upstream directory sits between them.
- Authentication policy: Keep multi-factor and session policy in the IdP, not midPoint, and document where each control lives.
- Self-service login: Note that midPoint's own user interface can authenticate against an external SSO service, which is different from serving SSO to other applications.
- Deprovisioning timing: Test how quickly a disabled account loses access in the IdP and in each downstream application.
Confirm the protocols and IdP products your application estate requires before you finalize the architecture.
Where the data sits and who controls the platform
Saviynt's Identity Cloud is delivered as a vendor-operated cloud platform, while midPoint is software you deploy and operate in your own environment. The cards below cover where identity data, audit evidence and keys end up, and which operating duties move to your team.
Vendor-operated cloud platform
Saviynt describes its Enterprise Identity Cloud as a cloud-native, converged platform that governs workforce, third-party, service and privileged accounts. The vendor operates the hosting, so your identity graph, entitlements and certification data sit in a tenant you do not run. Ask Saviynt which regions host your tenant, which sub-processors touch the data, and where backups are kept.
midPoint in your own infrastructure
midPoint can run on Linux in a virtual machine or from Docker images, so it can be placed in your cloud accounts, your data centers or an air-gapped network. Identity data, connector credentials and repository content stay where you put them. Confirm that your hosting choice matches data residency rules and that the PostgreSQL repository is located inside the same boundary.
No enterprise edition to gate features
Evolveum states that midPoint has no enterprise edition, and that every line of its code is published under open source licenses. Feature access does not depend on a vendor-controlled license tier. Your team can read, build and patch the software itself, though the Evolveum FAQ notes that development is funded through subscriptions, training and services.
Key management and audit evidence location
In a SaaS model, the vendor typically controls encryption keys, log retention and the location of certification evidence, so you need contractual and technical answers before audit. With midPoint, you decide where the audit records, the database encryption keys and the connector secrets are stored. Document who holds those keys and how audit trails are exported for assessors.
Patching, backups and database access
Running midPoint shifts operating duties to you: applying release updates, keeping the Java runtime and PostgreSQL supported, testing and taking backups, and restricting access to the database and admin console. Plan these as recurring tasks with named owners. Check the release calendar early, since midPoint 4.9 support ends on October 18, 2026 and midPoint 4.10 support ends on November 26, 2027.
Implementation partner inside your environment
A partner such as DeployOpen can plan, install, harden and document midPoint inside your own accounts or networks, so administrative access stays under your control. Agree in writing who holds administrator credentials, which environments the partner can reach and how access is revoked at the end of the engagement. Scope the handover of runbooks and evidence before work begins.
Saviynt cost versus midPoint cost by component
The main difference in cost is structural: Saviynt is a subscription you renew, while midPoint has no license fees and its recurring costs are the people, hosting and support you choose to buy. On the Saviynt side, ask the vendor to price each module you need separately (identity governance and administration, privileged access, application access governance and non-human identity management) because the Identity Cloud bundles these in one platform but quotes may still itemize them. Add the implementation services and the ongoing vendor management time your team spends on the relationship, and mark which of those lines recur at each renewal. On the midPoint side, the license line is zero, but the open-source project is not free to run. Evolveum sells Product Support subscriptions with an 8x5 next-business-day or 24x7 SLA, and Platform Subscriptions that add feature development and roadmap influence, and the Evolveum support subscriptions page lists no prices, so request them in writing.
Most of the cost sits in the items midPoint leaves to you. Hosting and database operation recur every year, and midPoint uses PostgreSQL as its native repository, ideally on a separate database server. Connector work is the largest variable: midPoint connects through ConnId, and where a target system has no documented connector, someone must build or maintain one. Implementation effort (role design, certification campaigns, separation of duties rules, and migrating entitlements and history) is largely one-time, while upgrades and staffing recur. The release line changes that calculation. midPoint 4.8 (Curie) is a long-term support release supported until 17 October 2028, midPoint 4.10 (Braille) is supported until 26 November 2027, and midPoint 4.9 support ends 18 October 2026, so an upgrade plan for 4.9 is a near-term cost.
When you request quotes, ask Saviynt for module-level pricing, the renewal uplift terms and the cost of extra connectors. Ask any midPoint implementation partner, including DeployOpen, for a fixed-scope written proposal that separates one-time delivery from annual support, names the target release line, and states whether connector development, hosting and PAM tooling are included. Ask Evolveum which support tier matches your uptime needs. Confirm the Java version and database sizing for your chosen release against the midPoint system requirements before you budget infrastructure.
What a move from Saviynt to midPoint involves
The sequence moves governance from Saviynt's converged cloud to a self-hosted midPoint deployment in a controlled order, so each access decision stays traceable and the audit trail carries over without a gap. Each step ends with an output the team can check before the next one starts.
Inventory identities, entitlements and applications
Export the current population of workforce, third-party, service and privileged accounts from the Saviynt tenant, along with entitlements, role definitions, approval rules and the connected applications behind each one. Confirm with Saviynt which export formats and API endpoints your contract and tenant configuration allow, since the available extract scope varies by setup. The step is done when the identity and entitlement counts reconcile against the source systems and every application has an owner who has confirmed it is in scope.
Export existing certification and access request history
Pull the completed certification campaigns, reviewer decisions, revocations and access request records from Saviynt, and decide with your compliance lead how much history must be retained as evidence and in what form. Ask your auditor which period and which fields they will sample, because this determines whether the history is archived as files, loaded into a separate store or both. The step is done when the archive is written to storage you control, a sample has been re-read by someone outside the project, and the retention owner has signed off.
Decide which PAM and application access functions stay
Separate the functions Saviynt performs that midPoint does not cover, such as privileged session control, vaulted credentials and application access governance for specific business systems, and assign each one to a named tool or retained service. Midpoint is an identity management system and does not replace an access management or SSO server, so confirm the SSO and MFA path your users will continue to use. The step is done when every Saviynt function on the inventory has a documented owner, a target tool and an agreed cutover date set by the business.
Build the midPoint deployment
Install midPoint on Linux in a virtual machine or from Docker images, using Java 25 for version 4.11 and later or Java 21 for 4.10, and PostgreSQL as the repository on a separate database server. For more than one node, place a sticky HTTP load balancer in front, share one central database, and verify that cache invalidation between nodes and Quartz task scheduling work across them. Confirm the chosen release's support window in the midPoint release documentation before you commit. The step is done when a test cluster survives a node restart without losing scheduled tasks or cached sessions.
Map and rebuild connectors through ConnId
For each target system on the inventory, identify the matching ConnId connector, such as LDAP, Active Directory, Microsoft Entra ID, SCIM2 or DatabaseTable, and mark any system without a supported connector as a build item. Connectors for systems outside the documented set may need custom development, and that effort should be scoped and quoted separately from the platform work. The step is done when every target has a connector with a status you have verified, a test account for read and write, and a recorded decision for each gap.
Run parallel reconciliation and simulations
Run midPoint in read and reconciliation mode alongside Saviynt for a period agreed with the application owners, comparing the entitlements each platform would grant or remove for the same identities. Use midPoint's simulation features on production-like data to test role changes before they touch live accounts, and review every difference with the business owner. The step is done when the unexplained difference list is empty or each remaining item has an approved disposition and a documented root cause.
Cut over certifications and access requests
Move open certification campaigns and self-service access requests to midPoint in a planned window, with reviewers trained on the new interface and pending items either completed in Saviynt or re-issued with their history attached. Check that separation of duties rules you depend on have been rebuilt in midPoint and tested against known conflicting entitlements. The step is done when no open campaign is orphaned, every new request routes to a midPoint approver, and the first full certification cycle in midPoint has completed with its evidence stored.
Retire the Saviynt tenant after evidence is retained
Before decommissioning, confirm with your compliance and legal owners that the exported history, configuration and logs meet the retention rules you have agreed, and that the exports can still be read in the future. Remove Saviynt connectors and credentials, revoke its service accounts and confirm the subscription end date in your contract. The step is done when the retention owner has accepted the archive in writing, the tenant is disabled and the access review of the old platform's service accounts is closed.
Questions buyers ask before switching from Saviynt
How much effort does moving governance from Saviynt to midPoint take?
The effort depends mainly on how many systems are connected, how many custom entitlements and attribute mappings exist, and how much certification history must be preserved. Each connected system needs a matching ConnId-based connector or a rebuilt mapping in midPoint, so a large estate with many target systems carries more work than a small one. Custom entitlement models and business-specific roles usually take the longest, because they must be translated into midPoint's role-based model and tested against production-like data. Certification history is a separate workstream: decide early whether historical decisions are exported as evidence, archived in a read-only store, or retained only in Saviynt for a defined period. Ask any implementation partner to break the estimate down by these drivers in a written scope.
Can an internal team run a midPoint migration without outside help?
A capable internal team can do it, but only if it already has identity engineering skills and is comfortable with Java and database operations. midPoint is written in Java, uses PostgreSQL as its native repository database, and its system requirements call for a separate database server and a specific Java version that depends on the release line. Multi-node deployments add a sticky HTTP load balancer, a shared database and Quartz-based task scheduling, which need someone who can operate them. Teams without these skills typically split the work: internal staff own the business rules, certification campaigns and sign-off, while an external specialist handles installation, connector work and hardening. Assess your own skills honestly before deciding, and document who will patch and back up the platform after go-live.
How long does a switch from Saviynt to midPoint take?
No reliable duration can be stated from general principles, because it depends on the scope, the number of connected systems, the volume of entitlements and how many governance processes must run in parallel during cutover. The most useful answer comes from a written scope that lists each connector, each role model, each certification campaign and each audit evidence requirement, with the milestones that must be met before Saviynt is switched off. DeployOpen agrees most engagements as fixed scope, with deliverables and timelines confirmed in writing before work starts. Ask any provider to show how the plan handles a parallel run, rollback and the period in which both platforms must produce evidence.
Does midPoint cover privileged access management?
No. midPoint is an identity governance and administration platform, covering provisioning, deprovisioning, lifecycle, role-based access control, auditing, access requests and role mining. Saviynt's Identity Cloud also bundles privileged access management, application access governance and non-human identity management, so those functions need separate tooling if you use them today. For privileged access, teams commonly evaluate self-hosted options such as Teleport or JumpServer alongside secrets managers. Evolveum also states that midPoint is not an access management or SSO server and does not implement the server side of OAuth2, OpenID Connect or SAML, so SSO needs its own identity provider. Map every Saviynt module you use to a replacement before the decision is made.
What does Evolveum support add, and what does it cost?
midPoint itself carries no license fees, so the commercial question is what support you want to buy. Evolveum offers Product Support subscriptions for resolving product bugs, with an 8x5 next-business-day or 24x7 SLA tier, and Platform Subscriptions that add feature development and roadmap influence. Its support page lists no prices, so request a quote for the tier that matches your uptime and response needs. Consider whether you need a subscription at all: an internal team with strong midPoint experience may rely on the community and its own staff, while regulated environments often want a contractual escalation path. Ask for the SLA definitions in writing, including response times for critical incidents, and compare them with the operating hours your business requires.
What should I confirm about certifications and separation of duties before committing to midPoint?
Confirm these points directly with Evolveum and in a proof of concept using your own roles and campaigns, rather than relying on general statements. First, verify that midPoint's certification campaigns cover the reviewer workflows, escalation, delegation and reporting that your auditors expect. Second, test how separation of duties rules are defined, applied to roles and enforced during requests, and what happens when a conflict is detected. Third, confirm how decisions, timestamps and reviewer identities are retained for evidence, and how long records remain available. Fourth, check the connector status for each target system in the integration catalog, since some connectors are community or experimental rather than supported. Document these results before any decommissioning decision.
Can DeployOpen prepare the evidence my auditors will ask for after the switch?
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, and it prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. In practice, the engagement would define which controls midPoint must support, document how the configuration and access reviews are performed, and assemble the evidence an auditor will request. Agree the evidence list and its format in the written scope so the audit team is not surprised after cutover.
How DeployOpen helps evaluate, implement or migrate midPoint
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted midPoint inside your own infrastructure, so the governance decision can rest on your connector list, your certification requirements and your audit evidence. We start with a written scope that separates what midPoint can cover from the PAM and application access governance functions that would need other tools.
How we scope
- Inventory your Saviynt modules, connected systems, certification campaigns and separation of duties rules before any design work starts.
- Map each function to midPoint's ConnId connectors, flagging any target system that needs a community or custom connector.
- Agree in writing which privileged access and application access governance functions stay with other tools, and who owns them.
How we build
- Deploy midPoint on Linux virtual machines or Docker images in your environment, with PostgreSQL on a separate database server.
- Build connectors, role models and approval flows against your sources, and test provisioning and deprovisioning in a non-production environment.
- Configure certification campaigns and separation of duties checks, then document the test results you will need for internal and external audit.
How we hand over
- Deliver architecture, configuration, runbooks and connector documentation so your team can operate midPoint without us.
- Walk your administrators and reviewers through access request, certification and reporting workflows before cutover.
- Provide a rollback plan and a written record of what was migrated, what was retired and what remains in other tools.
How we support
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
- Ongoing support, upgrades across midPoint release lines and continuous testing are available as a retainer.
- Ask your quote to name the midPoint support subscription you will hold with Evolveum, since that contract is separate from DeployOpen's work.
