SailPoint access certification alternative: open source

Can midPoint replace SailPoint access certifications?

If your team bought SailPoint mainly for access reviews, the question is whether midPoint can carry that workload after a renewal, a decision on IdentityIQ 9.0 or a data residency requirement. midPoint covers the core certification model: reusable campaign definitions with scope, stages, reviewer rules, remediation and reiteration, plus ad-hoc campaigns started from policy rules. Whether it fits your program depends on the campaign inventory and reviewer workflows you actually run today, so start by listing every campaign, its scope, its reviewers and what happens to revoked access. Apache Syncope is a sound open-source option for provisioning and self-service, but it does not replace certifications, so it should not be scored as a substitute for this function. Evaluate midPoint as the target for the review workload.

Map each existing campaign to a midPoint certification definition and note the stages it uses. midPoint lets unresolved cases pass through several stages to new reviewers, escalate or reassign work items with timed actions, and rerun a closed campaign for unresolved cases. Reviewers can accept, revoke, reduce or delegate a case, and remediation can be automated or report-only. Check each of these against your current SailPoint workflows, especially delegation rules and escalation timing, because differences here change what auditors see. Confirm the exact behavior of each action in the midPoint access certification documentation and test it in a non-production environment with your own data.

Plan the rebuild before the first audit cycle. Reviewer rules, remediation actions and campaign schedules must be recreated, and each application's account and entitlement data must flow through a ConnId connector that feeds the campaign scope. Run a parallel campaign on both systems for at least one cycle and compare decisions, reviewer assignments and evidence exports. Ask Evolveum or your implementation partner to confirm which connectors your target systems need, their support status and the Java and PostgreSQL versions required for your chosen midPoint release. Budget for the connector work and parallel-run effort, since these are the costs that most often change the result.

How SailPoint certification capabilities map to midPoint

This table compares the access certification capabilities teams typically use in SailPoint with the matching midPoint features and the rebuild work each one needs. Read the coverage column as a starting point: where a row is marked partial or unconfirmed, check the exact SailPoint behavior in your own tenant or IdentityIQ instance before you plan the migration. The main takeaway is that midPoint covers the campaign engine itself, while reviewer experience, evidence packaging and historical data need deliberate design.

Capability	midPoint coverage	Rebuild work and what to confirm
Campaign scoping	midPoint certification definitions set scope, such as which roles, resources or users a campaign covers.	Translate each SailPoint campaign filter into a midPoint scope. Confirm which object types your campaigns cover, such as entitlements, roles or accounts.
Reviewer assignment	Reviewer rules assign work items to managers, owners or other selected users.	Rebuild owner and manager mappings from your authoritative source. Confirm how reviewers without an assigned owner are handled.
Multi-stage review	Campaigns can pass unresolved cases through several stages to new reviewers.	Recreate each stage order and reviewer set. Test a two-stage campaign end to end before the first audit cycle.
Escalation and reassignment	Timed actions can escalate or reassign work items.	Define escalation timings and recipients in writing. Confirm whether your SailPoint reminder and escalation rules have equivalents you still need.
Remediation	Reviewers can accept, revoke, reduce or delegate cases, and remediation can be automated or report-only.	Decide which revocations are automated and which stay report-only. Build and test the provisioning path for each revoke action.
Reruns of unresolved cases	A closed campaign can be rerun for unresolved cases.	Document the rerun cadence and who approves it. Confirm how SailPoint carries open items across campaigns.
Policy-triggered campaigns	Ad-hoc campaigns can be started from policy rules.	Port each SailPoint trigger as a midPoint policy rule. Test the trigger conditions against sample data before go-live.
Reviewer interface and evidence exports	midPoint provides its own review interface; the exact layout and export formats must be checked against your needs.	Confirm with your SailPoint tenant or IdentityIQ instance which reviewer screens and evidence exports auditors use today, then design equivalent reports and retention.
Historical campaign records	Past decisions are not automatically moved from SailPoint into midPoint.	Export prior campaign results and store them as audit evidence. Agree with your assessor how the two systems will be read during the parallel run.

How IdentityIQ and Identity Security Cloud campaigns translate to midPoint definitions

A midPoint campaign is built from a reusable certification definition that sets the scope, the stages, the reviewer rules, the remediation and the reiteration behavior. Moving a SailPoint campaign means splitting what it does today into those parts, and the split is a design exercise, not a file conversion. Start by writing one current campaign on a single page: which identities or entitlements it covers (population and filters), who certifies each item (certifiers, owner and manager rules, fallback reviewers), what happens to a revoke decision (provisioning, ticketing or report only), and how often it recurs. Each of those answers maps to a different part of a midPoint definition, and several of them will need a decision rather than a copy.

Expect the reviewer rules and remediation logic to be re-expressed on the midPoint side. Owner and manager rules in IdentityIQ often rely on rules, workflows or custom attributes that have no direct equivalent, so the reviewer logic has to be written again as midPoint expressions and assignments and tested against sample populations. Revoke handling needs the same treatment: decide whether a revoke removes the entitlement automatically, raises a work item for an administrator, or only produces a report, and confirm that the chosen remediation path is supported for each target system through its ConnId connector. Ask Evolveum support or your integrator to confirm how a specific connector behaves on remediation before you commit to automation, and check your own environment with a pilot campaign. Keep the mapping in a document that auditors can read, including the decision for each campaign element.

Open-source options for certification workloads

Access certification is the part of identity governance that auditors look at most closely, so it decides the shortlist more than provisioning does. The three options below differ in how much certification machinery they bring, and in how much you will need to build yourself.

midPoint certification campaigns

midPoint runs reviews as campaigns built from a reusable certification definition that sets scope, stages, reviewer rules, remediation and reiteration. Reviewers can accept, revoke, reduce or delegate a case, and remediation can be automated or report-only. Confirm that your reviewer model fits stages and timed escalation before you commit, because staged reviews, reassignment and reruns of unresolved cases are the features that replace a typical IdentityIQ or Identity Security Cloud campaign.

Apache Syncope for provisioning only

Apache Syncope, licensed under Apache 2.0, covers provisioning and self-service with ConnId connectors, admin and end-user interfaces and its own SSO component. It does not provide SailPoint-style access certification or role mining, so teams that need periodic attestation will have to add a separate review process. This option suits organizations whose audit scope is mostly joiner, mover and leaver evidence. Check whether attestation is an audit requirement before choosing it.

Custom review workflow on midPoint data

For unusual reviewer models, such as reviews split by business unit, data owner sign-off outside the directory, or evidence bundles for a regulator, teams can build a custom review workflow that reads account, role and assignment data from midPoint and records decisions in their own system. This moves control design and testing onto your team. Ask who will own the code, how decisions are written back to midPoint, and how the workflow is tested before the first audit cycle.

Connector coverage for review data

A certification is only as complete as the account data it reviews. midPoint reads source systems through ConnId connectors, and documented connectors include LDAP, Active Directory, Microsoft Entra ID, SCIM2 and database tables. Connectors for less common applications may be community or experimental. Inventory every application in scope and confirm each one has a supported connector that returns entitlements, not just accounts, before you plan reviews around it.

Runtime and database operations

Certification campaigns run on the same platform as provisioning, so their availability depends on the Java runtime, the PostgreSQL repository and the scheduling of campaign tasks. midPoint recommends Java 25 for 4.11 and later and Java 21 for 4.10 and older, and multi-node deployments need a shared database and distributed task scheduling. Confirm which midPoint line you will run and who patches the runtime, because a campaign that stalls mid-cycle is an audit finding.

What changes for IdentityIQ and Identity Security Cloud customers

Customers running IdentityIQ with Compliance Manager usually have certification logic spread across several places: campaign definitions, certification rules, custom workflows, and reviewer assignments tied to the identity model. On-premises and hybrid deployments also tend to hold the most custom code, so the certification scope is often shaped by rules that are not visible in the campaign screens. Plan the move as a translation of intent, not a file copy, since midPoint certification definitions use their own scope, stages, reviewer rules and remediation settings.

Campaign definitions and scope: Inventory each certification type, its population filter, and its frequency. Map each one to a midPoint certification definition with an explicit scope.
Custom rules and workflows: Identify every rule that decides reviewers, escalations or remediation. Each one needs a midPoint equivalent in reviewer rules, timed actions or policy logic, or a documented decision to drop it.
Certifier hierarchies: Document manager-based and owner-based reviewer chains, including fallbacks for orphaned accounts and delegated approvers.
Remediation paths: Decide which revocations are automated against connectors and which stay report-only, and confirm the ConnId connectors for each target system.
Historical evidence: Export completed campaign results and decisions as records, since the audit trail for past cycles must remain available even after the platform changes.

Effort rises with custom rules, unusual certifier hierarchies, and large application counts, because each application needs a connector and a scope definition. Confirm with your auditors which historical evidence they need and how long it must be retained.

Rebuilding certification campaigns before the first audit cycle

This sequence moves each access review from SailPoint into midPoint with evidence that an auditor can follow, from the inventory of campaigns through a parallel cycle and sign-off before the old reviews are retired.

Inventory every campaign and its audit purpose
The client's identity and compliance owners list each certification campaign in the current SailPoint estate, including its scope, reviewer population, schedule, remediation path and the control or regulation it supports. Map each campaign to the audit question it answers, such as privileged access reviews or quarterly application owner attestations. The step is done when every campaign has a named owner, a stated audit purpose and a decision on whether it moves, merges or retires. DeployOpen can structure this inventory into a written scope document if the client wants an outside review of the list.
Connect target applications through ConnId connectors
Engineers build or configure ConnId connectors in midPoint for each application that feeds a campaign, starting with the systems that carry the highest-risk entitlements. Each connector is tested for read operations first, so that accounts and entitlements are visible before any provisioning is enabled. The client's application owners confirm that the account types and entitlement attributes match what their reviewers see today. The step is done when every in-scope application returns the expected accounts and entitlements in a test run. DeployOpen plans and implements the connectors where it is contracted to do so, and the client confirms the system access and data definitions.
Load identities and entitlements into midPoint
Identity records, accounts and entitlements are imported from authoritative sources and the connected applications into a non-production midPoint environment. Engineers reconcile the counts and sample records against the SailPoint exports and the source systems, and note any identities that fail to correlate. Role assignments are checked so that the reviewer population and the entitlement scope match the inventory from the first step. The step is done when the reconciliation report shows the expected totals and every exception has an owner and a decision. The client supplies the authoritative data sources and approves the correlation rules.
Translate definitions and reviewer rules
Each campaign is rebuilt as a midPoint certification definition that sets its scope, stages, reviewer rules, remediation and reiteration behavior. Engineers translate SailPoint reviewer logic, such as manager or owner assignments and fallback reviewers, into midPoint reviewer expressions, then confirm which remediation actions are automated and which are report-only. The client's compliance lead signs off on each definition against the audit purpose recorded in the first step. The step is done when every definition is versioned, reviewed and linked to its audit purpose. DeployOpen plans and implements the translation where it is in scope, and the client's compliance owner approves each control mapping.
Test a campaign on a copy of production data
Engineers run each rebuilt campaign against a recent copy of production identity and entitlement data, with stage transitions, timed escalations and reassignments exercised in full. Test reviewers, who are drawn from the client's business owners, accept, revoke, reduce and delegate cases so that every decision type is covered. Results are compared with the decisions the SailPoint campaigns produced for the same population, and every difference is either fixed or documented as an accepted change. The step is done when test outcomes match the expected results and the discrepancy log is closed. DeployOpen can plan and run this test as part of a fixed-scope engagement, and the client supplies the reviewers and the approval of differences.
Run a parallel certification cycle
Both platforms run the same campaigns for one full review cycle, with SailPoint remaining the system of record for decisions and midPoint generating its own results. Reviewers are asked to make decisions in the system of record only, while the team compares the midPoint outcomes, remediation tasks and report output against the SailPoint results. Any gaps in reporting, reminders or evidence export are corrected before cutover. The step is done when the parallel results are reconciled and the client has accepted the differences in writing. The client runs the business side of the reviews, and DeployOpen tests the midPoint side and documents the comparison.
Sign off evidence with the auditor before cutover
The client assembles the evidence pack for each campaign, including definitions, reviewer assignments, decision records, remediation logs and the parallel-cycle reconciliation. The client shares the approach with its internal audit or external auditor early enough to agree on what evidence is acceptable, because only the auditor can judge whether the controls meet the applicable framework. DeployOpen prepares the technical evidence and the control documentation, but it does not issue audit opinions. The step is done when the auditor has confirmed in writing that the evidence is sufficient for the first audit cycle on midPoint, and SailPoint campaigns are retired on a date the client has approved.

Running midPoint certifications alongside SailPoint during the transition

Access certifications are the step most likely to be audited, so most teams keep SailPoint running until midPoint has produced evidence an auditor will accept. The cards below cover how to split scope between the two systems, keep identity data consistent, compare decisions, and decide when SailPoint campaigns can stop.

Split scope by application

Keep SailPoint campaigns for every application that is still connected only there, and move an application to midPoint only when its accounts and entitlements are read by a ConnId connector you have tested. Record the split in a written register so each application has exactly one system of record for its certifications at any given time. Ambiguous ownership is the most common source of duplicate or missed reviews during a parallel run.

Pilot with a bounded population

Run a midPoint campaign for one business unit or one application group, with reviewers who already know the SailPoint process. Use a definition that mirrors the SailPoint campaign scope, stages and reviewer rules as closely as the data allows, so that differences in outcome point to the platforms rather than to changed rules. Confirm with your auditors which population they will accept as the pilot before the first cycle starts.

Keep identity data consistent

Both systems must see the same users, accounts and entitlements, or a reviewer will certify a stale view. Decide which system reads each source during the overlap, schedule the reconciliation runs, and compare account counts per application between SailPoint and midPoint at a fixed interval. Any gap in account correlation, such as a user with two identifiers, should be resolved before its campaign runs.

Compare decisions across both systems

For each campaign item reviewed in both systems, record the reviewer, the decision (accept, revoke, reduce or delegate), and the remediation outcome. Differences should be investigated and classified as data, rule or reviewer causes. Keep this comparison as evidence, since it shows the auditor how the new platform behaves against the system it replaces.

Confirm licensing overlap in writing

Ask SailPoint in writing how the subscription, module and any IdentityIQ maintenance terms apply while you still use it, and whether a reduction can be scheduled to match each application you move. Ask Evolveum which support subscription level you need during the overlap, since midPoint itself carries no license fee. Both answers determine how long the parallel period can cost in practice.

Retire SailPoint campaigns on evidence

Switch off a SailPoint campaign for an application only after the midPoint results for that application have been reviewed and the audit or compliance owner has accepted them in writing. Keep the SailPoint campaign history and exports for the retention period your policies require, and record the decision date and the accepted evidence. Retiring early because the new system looks ready is the step most likely to create an audit finding.

What evidence the first audit cycle will ask for

An assessor testing access reviews will usually ask for the campaign definition, the scope it covered, the list of reviewers and how they were assigned, each reviewer's decision with a timestamp, the remediation record showing that revoked access was actually removed, and a register of exceptions with their approvers and expiry. In midPoint, the definition is a reusable object that sets scope, stages, reviewer rules, remediation and reiteration, so you can export it and show the same logic applied in every cycle. Campaign runs, case outcomes and the audit trail of who changed what are the records that show the review happened as designed. Decide early whether remediation is automated or report-only, because each mode leaves a different trail, and make sure the remediation log can be tied back to the specific case that triggered it.

Map each artifact to a midPoint source before the first cycle, and test the export path yourself. Confirm which objects, campaign outputs and audit records your team can retrieve from the running system, how long they are retained, and whether they can be exported in a form the assessor accepts. Check that the reviewer assignments reflect your current organizational data at the time of each campaign, since a stale manager relationship will show up as an incorrect decision in the evidence. Keep the definition versions in source control so that a change between cycles is visible. Where a control depends on a manual step, such as a reviewer escalating a case outside the system, write down who does it and record that step separately.

DeployOpen plans, implements, hardens and documents the midPoint deployment and can prepare the systems, controls and evidence for assessment, but it does not issue audit reports, attestations or certifications. The auditor decides whether the evidence is sufficient for the control objective and the framework in scope, so the list above is a starting point, not a finished deliverable. Before the first cycle, agree the evidence list in writing with your auditor, including the format, the sampling approach and the period it must cover. Ask them to review a dry run of one campaign so that gaps surface while the cycle is still a rehearsal. Your internal audit or compliance lead should own that conversation, with the platform team supplying the exports.

Questions buyers ask about replacing SailPoint certifications

What does it cost to replace SailPoint certifications with midPoint?

The software license is zero, so the cost sits in the components around it: infrastructure, connector work, rebuilding certification definitions, testing, operations staff and, if you choose one, an Evolveum subscription. The Evolveum support subscriptions page describes Product Support and Platform Subscriptions but lists no prices, so ask Evolveum for current figures. Ask us for a fixed-scope quote built from your campaign inventory, the number of target systems and the reviewer population. One-time work (rebuilding campaigns, connectors and reports) differs from recurring costs (hosting, patching, support and staff time for each review cycle).

How long does it take to rebuild access reviews in midPoint?

Duration depends on how many campaigns you run, how many systems they cover, how much reviewer logic is custom, and how many stages and escalations you need to reproduce. Campaigns in midPoint are built from reusable definitions covering scope, stages, reviewer rules, remediation and reiteration, so a simple quarterly application review is quicker to rebuild than a multi-stage campaign with delegation and automated revocation. Your schedule should be set in a written scope before work starts, and it should leave time for at least one full review cycle in parallel with your current tool.

What must our team provide before the rebuild starts?

Before work begins, your team should provide a complete campaign inventory with each campaign's scope, recurrence, reviewers, remediation rules and evidence outputs. You also need named owners for each application and entitlement, a current reviewer list with delegation rules, and a sample of production-like account and entitlement data for testing. Without that, reviewer assignments and remediation paths cannot be validated. Confirm with your current SailPoint administrators which campaigns are actually used, because many older campaigns are inactive but still listed.

Can our own team build midPoint certifications without a partner?

Yes, if your team has Java, PostgreSQL and identity administration skills and enough capacity. midPoint runs on Linux in a virtual machine or from Docker images, and it uses PostgreSQL as its native repository database. Evolveum publishes the source under open source licenses and sells support, consulting and training, so you can staff the work internally, use Evolveum services or engage an implementation partner. The main risk for an internal team is underestimating the review logic and testing, so plan for a parallel run before retiring the old campaigns.

Will midPoint certification campaigns satisfy our audit?

midPoint provides the campaign mechanics that auditors look for, including reviewer decisions, multi-stage review, escalation, reassignment and automated or report-only remediation, but no tool satisfies an audit by itself. Your auditor decides whether the evidence, scope and control design are sufficient. Confirm with your auditor which review records, timestamps and decision trails they will sample, and test an export of those records before the first cycle. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or attestations.

How do midPoint escalations and reruns compare with SailPoint workflows?

midPoint campaigns can pass unresolved cases through several stages to new reviewers, escalate or reassign work items with timed actions, rerun a closed campaign for unresolved cases, and start ad-hoc campaigns from policy rules, as described in the midPoint access certification documentation. Engineers should map each SailPoint escalation rule to a timed action and check that delegation and revocation behave identically under test. Any custom SailPoint rule logic will need to be rewritten, not copied, so list those rules during the inventory.

Which midPoint release should we target for certifications?

For a long-term deployment, midPoint 4.8 (Curie) is a long-term support release supported until October 17, 2028, according to the midPoint releases page. midPoint 4.10 (Braille) is the latest feature release, supported until November 26, 2027. midPoint 4.9 support ends October 18, 2026, and 4.11 is planned for October 21, 2026. Java requirements differ by version, so check the midPoint system requirements before choosing a Java runtime and database host.

How DeployOpen scopes and delivers a certification replacement

DeployOpen plans and implements the move from SailPoint access certification campaigns to self-hosted midPoint certification definitions inside your own infrastructure. Work starts with a written scope that maps your current campaigns, reviewers and remediation rules to what midPoint can run, and the gaps you need to confirm.

How we scope

Inventory every certification campaign, its scope, reviewer groups, stages and remediation actions in your current SailPoint environment.
Map each campaign to a midPoint certification definition, noting reviewer rules and reiteration behavior you need to rebuild.
Agree the written scope, deliverables and timeline with you before work starts, since most engagements are fixed-scope.

How we build

Configure midPoint certification definitions, stages, timed escalation and reassignment rules in a non-production environment first.
Test automated and report-only remediation against connected target systems, including the ConnId connectors used for account data.
Document each campaign's configuration and the evidence it produces so your compliance team can review it with the auditors.

How we hand over

Deliver runbooks for launching, monitoring and closing campaigns, plus the configuration exported as versioned files.
Walk your identity, security and compliance staff through reviewer tasks, unresolved-case reruns and ad-hoc campaigns from policy rules.
Confirm with your auditors which control evidence they expect from the first campaign cycle on midPoint before cutover.

How we support

Ongoing support, upgrades and testing are available as a retainer, which can cover midPoint release changes after handover.
Keep a parallel run plan so SailPoint and midPoint campaigns can be compared through one audit cycle, if your scope includes it.
Ask Evolveum directly about its Product Support and Platform Subscription options, since those are separate from DeployOpen services.

Open-source alternative to SailPoint access certifications