Can midPoint access certification replace One Identity Manager attestation?
If your attestation program in One Identity Manager is coming up for renewal, facing a licensing change, or constrained by a data residency decision, the direct answer is that midPoint access certification covers the same core job: recurring reviews of who holds which access, reviewer assignments, remediation of revoked access, and repeat campaigns for items that stay unresolved. Whether it fits your program depends on three things you can map before committing: the attestation policies you run today, the approvers behind each one, and the evidence formats your auditors already accept. midPoint is open source and carries no license fees, so the cost question shifts to infrastructure, staff time and any support you choose to buy.
Start by inventorying each One Identity attestation policy and writing down its scope, reviewer logic and remediation action. In midPoint, each of these becomes part of a reusable certification definition that sets scope, stages, reviewer rules, remediation and reiteration. Pay close attention to escalation and reassignment rules, because midPoint can pass unresolved cases through several stages to new reviewers and run timed escalations, and you need to confirm that your current approval chains translate one to one. Also confirm whether each remediation must be automated or report-only, since midPoint supports both. Treat this mapping as the first deliverable of any pilot, and have your internal audit team review sample campaign output before you retire the old attestations.
Evolveum states that midPoint has no enterprise edition, and that it funds development through subscriptions, training and professional services. Its Product Support subscriptions cover resolving product bugs with an 8x5 next-business-day or 24x7 service level, and Platform Subscriptions add feature development and roadmap influence. Evolveum's support subscriptions page lists no prices, so request a written quote that states the service level, the included releases and the named contacts. Ask your assessor early which evidence formats they accept from a campaign, because the audit trail you keep in midPoint must satisfy them as well as your own governance team.
Mapping attestation capabilities to midPoint certification
This table maps the attestation functions an organization typically relies on in One Identity Manager to their midPoint access certification equivalents. Read the middle column for what midPoint documents, and the last column for what to verify in a pilot before committing to a cutover.
| Attestation function | midPoint access certification | What to confirm in a pilot |
|---|---|---|
| Attestation policies and scope | Reusable certification definitions set the scope of objects reviewed, such as roles, resources or assignments | Map each existing attestation policy to a definition and confirm the scope filters reproduce the same population |
| Approvers and reviewer rules | Reviewer rules assign work items to people or groups, and cases can be accepted, revoked, reduced or delegated | Test that approver logic from One Identity, including manager or owner lookups, yields identical reviewers |
| Scheduled and ad-hoc reviews | Campaigns run from a definition on a schedule, and ad-hoc campaigns can be started from policy rules | Confirm recurrence settings and whether policy-triggered reviews cover your current ad-hoc use cases |
| Multi-stage review and escalation | Campaigns pass unresolved cases through stages to new reviewers, with timed escalation and reassignment of work items | Verify stage timing and escalation paths match your sign-off rules and deadlines |
| Remediation of revoked access | Remediation can be automated to remove the assignment or set to report-only for manual follow-up | Check that automated removal reaches target systems through the connector and that failures are reported back to the campaign |
| Reiteration of open cases | A closed campaign can be rerun for unresolved cases | Confirm that rerun behavior matches how your team currently chases outstanding attestations |
| Reports and review evidence | Campaign results and case history are stored in midPoint, and reports can be produced from the repository | Export sample reports and compare them with the formats your auditors currently accept. Exact report layouts are not covered in the reviewed documentation and need confirmation |
| Features outside the documented scope | Not described in the access certification documentation reviewed for this page | Ask Evolveum or your partner to confirm any One Identity attestation features you rely on that are not listed here, such as specialized approval workflows or custom attestation UI |
Which open-source options fit attestation work
Attestation work splits into two questions: can the platform run structured reviews with evidence, and can it also provision the access being reviewed. The cards below cover the main open-source paths and the trade-off each one carries, so you can match the option to how your reviews run today.
midPoint access certification
This is the primary fit for attestation. midPoint runs reviews as campaigns built from a reusable definition that sets scope, stages, reviewer rules and remediation. Reviewers can accept, revoke, reduce or delegate each case, and remediation can be automated or report-only. Check that your current attestation policies map cleanly to scope and reviewer rules before you commit, since the mapping drives most of the migration effort.
Multi-stage review and escalation
Teams whose attestation runs through several approval levels should look at midPoint's staged campaigns. Unresolved cases can pass to new reviewers, work items can be escalated or reassigned with timed actions, and a closed campaign can be rerun for unresolved cases only. Confirm that your escalation timing rules and reassignment logic can be expressed in these stages before you plan cutover.
Policy-triggered ad-hoc reviews
midPoint can start ad-hoc campaigns from policy rules, which suits reviews that must fire on a specific event, such as a sensitive role assignment, rather than on a fixed calendar. This replaces some scheduled attestation runs. Test the trigger conditions against realistic assignments in a non-production environment to confirm the evidence they produce matches what auditors expect.
Apache Syncope for provisioning-led identity
Apache Syncope is an Apache Software Foundation project for managing digital identities under the Apache License 2.0. It fits teams whose main need is provisioning, delegated administration and connectors, with attestation handled elsewhere or with lighter requirements. Its certification depth is lower than midPoint's, so if your auditors expect structured campaigns with reviewer evidence, plan for additional tooling or custom work.
Separate review tool for evidence
Some organizations keep attestation evidence in a dedicated review or GRC tool while the identity platform handles provisioning. This split can work when the review tool can ingest reviewer decisions and remediation records from the identity platform. The cost is an extra integration to maintain and a second place where evidence must be reconciled. Ask your auditor to confirm which system of record they will sample from.
Evidence and remediation trail
Whichever engine you choose, auditors will ask for the same things: who reviewed what, when, what they decided, and whether revoked access was actually removed. midPoint records campaign decisions and can apply remediation automatically or report it only. Confirm with your auditor which exports, retention periods and sign-off records they accept before you design the reporting layer.
Running midPoint certification alongside the rest of the suite
In a coexistence model, One Identity Manager stays the system of record for joiners, movers and leavers, and midPoint runs certification campaigns against an exported picture of entitlements. midPoint does not need to own provisioning to run a campaign. It needs an accurate, current set of accounts and assignments per target system, which it can read through ConnId connectors (for example LDAP, Active Directory or a database table) or from a scheduled CSV extract that you control. Plan the feed as a product in its own right, with a named owner, a schedule and a reconciliation check against the source.
- Feed scope: Decide which target systems and entitlement types the campaigns cover, and keep that list identical to what the auditors saw last cycle.
- Snapshot timing: Freeze the extract before the campaign starts so reviewers judge the same data the campaign was built on.
- Reconciliation: Compare record counts and sample entitlements between One Identity Manager and midPoint before each launch.
- Identity keys: Map a stable identifier, such as the employee ID, so reviewers see the same person across systems.
- Ownership: Record which system owns each entitlement type so every grant has one home.
Before you commit, confirm with your One Identity and Evolveum contacts how their current attestation exports and whether your target systems have a supported ConnId connector.
Full replacement moves lifecycle, requests and certification into midPoint, so one platform holds the access model and the review history. This path removes the export feed but adds migration work: connectors for every target system must be built or confirmed on ConnId, roles and policies must be rebuilt, and in-flight attestations must be closed or carried over. midPoint's documented connectors include LDAP, Active Directory, CSV, DatabaseTable, ScriptedSQL, Microsoft Entra ID through Graph API and SCIM2, and the integration catalog lists further connectors with varying status, so check each target against that catalog.
- Connector gap list: Mark each target system as supported, community, experimental or missing, and plan custom work for the last two groups.
- Cutover window: Choose a date after which new campaigns run only in midPoint, and close One Identity attestations before that date.
- Historical evidence: Export the final One Identity attestation results and retain them under your records policy, since midPoint will not hold them.
- Parallel run: Run a campaign in both tools against the same snapshot and compare decisions before switching.
- Support decision: Decide whether to rely on community support or buy an Evolveum Product Support subscription, which offers 8x5 next-business-day or 24x7 response options.
Confirm the connector status of each target system in the Evolveum connectors documentation before you estimate any effort.
The main operational risk in coexistence is that two systems act on the same access. One system may revoke an entitlement that the other has already removed, or a reviewer may revoke in midPoint while One Identity Manager re-grants it from a request. The fix is an explicit rule about which system is allowed to change which entitlement, enforced in the workflow, not just in documentation. Treat the certification output as a list of decisions for one owner to execute.
- Single executor: Let one system perform each revocation type. For example, midPoint records the decision and a controlled job or ticket removes the access in One Identity Manager.
- Decision freeze: Block provisioning changes for a campaign's scope while revocations are pending.
- Idempotent checks: Before applying a revoke, confirm the entitlement still exists, so a second run does not fail or duplicate work.
- Conflict log: Record every case where the two systems disagree and resolve it before the next campaign.
- Monitoring: Alert on entitlements that return within a set period after revocation.
Test this path in a non-production environment with a small scope before you rely on it for an audit cycle.
Certification decisions are only useful if they change access and leave a record. midPoint's access certification lets reviewers accept, revoke, reduce or delegate a case, and remediation can be automated or report-only. Choose the mode per campaign. Report-only is a safe first step because it produces findings without changing any system. Automated remediation is appropriate once the feed and the executor are proven, and it should be limited to revocations that the policy explicitly approves.
- Remediation mode: Start with report-only, then move specific campaign types to automated remediation after review.
- Reduce and delegate: Define whether a reduce action removes a role or a single entitlement, since downstream systems treat these differently.
- Reiteration: Use rerun of a closed campaign for unresolved cases so open items are not lost between cycles.
- Escalation: Configure timed actions that reassign or escalate work items, so decisions do not stall.
- Evidence export: Store the campaign definition, reviewer identities, decisions, timestamps and remediation outcomes together.
Ask your auditors which evidence format they accept and whether they require the decision trail from each system.
How attestation policies and approvers map to certification definitions
Each One Identity Manager attestation policy becomes one midPoint access certification definition, and the migration works best when you treat that mapping as a documented inventory rather than a copy of screens. For every policy, record which objects it attests (the scope), how many review stages it has, who reviews at each stage, and what happens to revoked access. In midPoint, those answers live in the definition: its scope selects the users, roles or resources under review, its stages and reviewer rules decide who sees each case, and its remediation setting determines whether a revoke is applied automatically or only reported. Confirm with your security team whether any existing policy relies on a second-level approval that must be reproduced as a separate stage. Reusable definitions also let you retire duplicated policies, which is often where the largest cleanup effort sits.
Approver lists in One Identity Manager map to reviewer rules in midPoint, and delegation needs its own decision. Reviewers can accept, revoke, reduce or delegate a case, so the old approver list should be checked for people who currently act only as substitutes. Timed actions replace reminder e-mails: you define when a work item escalates or is reassigned if it stays open, which gives auditors a visible rule instead of informal follow-up. Two capabilities need explicit planning. Ad-hoc campaigns can be started from policy rules, which is the nearest equivalent to attestation triggered by an event, so list every trigger your policies use today. Closed campaigns can be rerun for unresolved cases, which lets you close a cycle on schedule and still chase stragglers. Ask your auditors which rerun and escalation records they will accept as evidence before you cut over.
Migrating attestation runs to midPoint in phases
This sequence moves attestation from One Identity Manager to midPoint access certification in controlled stages, so each review decision can be compared with the current process before enforcement changes. The output is a tested set of certification definitions, a pilot with recorded differences, and a signed-off evidence format that auditors have agreed to accept.
Inventory attestation policies and approvers
The client's identity governance owner and policy owners list every attestation policy in One Identity Manager, including its scope (target systems, roles, resources), its reviewers, its frequency and the action taken on revoked access. DeployOpen maps each policy to a candidate midPoint certification scope and flags policies that depend on logic midPoint does not copy directly, such as custom approval chains or risk scoring. The step is done when every policy has an owner, a named approver list and a mapping status, and the client has confirmed the list is complete.
Export review history and evidence records
The team exports prior attestation results, reviewer decisions, timestamps and remediation records from One Identity Manager into an archive kept under the client's control. This archive is the baseline that auditors and internal audit will compare against midPoint output. The step is done when a sample of past campaigns can be reconstructed from the export, and the client has confirmed which retention period applies to each record type.
Rebuild target connectors on ConnId
Each target system that feeds an attestation scope is connected to midPoint through a ConnId connector. DeployOpen checks whether a documented connector (such as LDAP, Active Directory, Microsoft Entra ID, SCIM2 or DatabaseTable) covers the system, and where none exists, scopes a custom Java connector with the client's application owners. Reconciliation runs confirm that accounts and entitlements in midPoint match the source systems. The step is done when reconciliation reports for each in-scope system show no unexplained differences, because certification is only as reliable as the account data it reviews.
Define certification campaigns and reviewer rules
DeployOpen builds reusable certification definitions in midPoint that set scope, stages, reviewer rules, remediation and reiteration for each mapped policy. Stages that reproduce the current approval chain are configured with the same reviewers, and escalation and reassignment timers follow the client's documented rules. The client's policy owners review the definitions line by line. The step is done when each definition has been reviewed and signed off by its policy owner and the approver lists match the inventory from the first step.
Run a pilot campaign in report-only mode
A pilot campaign runs against one or two low-risk scopes with remediation set to report-only, so midPoint records what it would revoke without changing any account. Reviewers complete the pilot through the normal process, and the client's reviewers are also asked to make decisions in One Identity Manager for the same scope. The step is done when the pilot has closed and every case has a recorded decision in both systems.
Compare decisions with the existing process
The team compares each midPoint decision (accept, revoke, reduce or delegate) with the decision recorded in One Identity Manager for the same access item. Differences are classified as definition gaps, data gaps in connector reconciliation, or reviewer behavior, and each class is fixed and retested before the next pilot. The output is a written comparison report that the client's compliance lead and internal audit can read. The step is done when the differences are either resolved or accepted in writing by the policy owner.
Agree the evidence format with auditors
Before enforcement changes, the client's compliance lead and its external auditor confirm what evidence they need from a campaign, such as the campaign definition, reviewer identities, decision timestamps, justifications and remediation logs, and in which format they accept it. DeployOpen can prepare exports and documentation for that format, but it does not issue audit reports or attestations, and the auditor's written acceptance is the client's control point. The step is done when the agreed evidence format is documented and the auditor has confirmed it in writing.
Switch enforcement and retire the old runs
The client's governance owner approves the cutover by scope, starting with the scopes that passed the pilot. Remediation is switched from report-only to automated or manual enforcement for those scopes, and One Identity Manager attestation for them is closed with its final results archived. Rollback steps and a record of who may trigger them are documented before the switch. The step is done when enforcement is active for each approved scope, the old runs are closed and archived, and the first live campaign has produced evidence in the agreed format.
Remediating revoked access and keeping evidence auditors accept
A revoked decision in midPoint only changes access when someone decides it should. Each case that a reviewer revokes can either trigger automated remediation, which removes the assignment and lets provisioning take the account out of the target system, or be left as report-only so that an administrator removes the access by hand. Before the first campaign runs, decide which remediation mode applies to each campaign definition, and confirm with your administrators how long a revoked assignment may remain in place before the target system reflects the change. Test this on a non-production target, because the outcome depends on the connector used for that system and on how the target handles disabled versus deleted accounts.
Auditors judge the record of the decision as much as the decision itself. For every case, keep the reviewer identity, the decision, the time it was made, the justification, and the remediation outcome, and make sure the campaign's history survives re-runs and escalations. midPoint stores this certification data inside the platform, so confirm with your internal audit or external auditor which fields, retention period and export format they expect, such as a report extract, a database export or a signed archive. Agree that format before the first campaign closes, not after the audit request arrives.
DeployOpen prepares the controls, configuration, runbooks and evidence collection for your review process, and can test that the evidence can be produced in the agreed format. DeployOpen does not issue audit reports, attestations or certifications. Your independent auditor or certification body makes any assessment outcome, and your own governance owners remain accountable for the access decisions themselves.
What does replacing attestation with midPoint cost and require?
What cost components drive the effort of replacing attestation with midPoint?
The main components are the licenses you stop paying, the infrastructure for midPoint, the migration work, testing, and an optional Evolveum subscription. midPoint is published under the EUPL-1.2 with Apache 2.0 as a secondary license and has no license fees, so the One Identity subscription and its supporting Windows and SQL Server infrastructure are the costs you avoid. You still pay for Java hosts, a PostgreSQL database server (midPoint recommends a separate database server), backups, and the staff who run them. Migration cost depends mostly on how many attestation policies, approvers and connectors you rebuild. Ask your vendor and your DeployOpen scope for each component as a separate line item.
How long does an attestation replacement take with midPoint?
The duration depends on the number of attestation policies, the number of approver chains, and how many target systems already have a ConnId connector. Each policy maps to a certification definition with its own scope, stages and reviewer rules, so a large policy catalog takes longer to translate and test than a small one. Connectors that are documented and supported, such as LDAP, Active Directory, Microsoft Entra ID or SCIM2, shorten the work, while custom or experimental connectors add build and test time. No duration is fixed by the product, so ask for a timeline based on a written inventory of your policies and systems.
What does the internal team have to supply for the migration?
The internal team must supply the knowledge that the attestation process itself depends on. That means a current inventory of attestation policies, who approves each one, the escalation rules when reviewers do not respond, and the remediation expected for revoked access. You also need administrators who can confirm which target systems are authoritative, service account access for connectors, and a sign-off owner for review evidence. Without these inputs, the new certification definitions will reproduce gaps rather than close them, so treat the inventory as a prerequisite rather than a side task.
Can our own engineers replace attestation with midPoint without a partner?
Yes, a capable internal team can run the migration, because midPoint is open source with public documentation and no enterprise edition gating features. The work needs Java operations skills, PostgreSQL administration, and familiarity with midPoint's access certification model. Teams without prior midPoint experience usually spend more time on the first campaigns and on connector troubleshooting. An external partner can be engaged for a fixed scope covering design, implementation, testing and documentation, or for ongoing support. Decide based on the skills you already have and the deadline your audit cycle sets.
What does the Evolveum support subscription add, and is it required?
It is not required to run midPoint. Evolveum offers Product Support subscriptions for resolving product bugs, with an 8x5 next-business-day or 24x7 SLA, and Platform Subscriptions that add feature development and roadmap influence. Evolveum's page lists no prices, so request a quote for the tier you need. Choose support when your organization needs a contractual bug-resolution path during the attestation cutover or for a regulated production service. Confirm the SLA terms directly with Evolveum before you rely on them in a risk assessment.
How do the midPoint release dates affect attestation migration planning?
Release dates determine which version you build on and how long it stays supported. midPoint 4.8 (Curie) is a long-term support release supported until October 17, 2028, which suits a stable production baseline. midPoint 4.10 (Braille) is a feature release supported until November 26, 2027, and midPoint 4.9 support ends October 18, 2026. midPoint 4.11 (Čapek) is planned as a feature release for October 21, 2026. Pick the version your certification design depends on, recognize that 4.11 and later recommend Java 25, and plan an upgrade window before a feature release leaves support. Confirm current dates on the midPoint releases page before you commit.
What operational work continues after the attestation campaigns go live?
Once campaigns run, the recurring work is operational. You will patch the Java runtime and midPoint, back up the PostgreSQL repository, monitor scheduled certification tasks, and review connector health. Multi-node deployments add a sticky HTTP load balancer, a shared central database and cache invalidation between nodes, so each node needs the same care. Budget for periodic review of reviewer rules, because organizational changes cause orphaned approvers. Ask any partner for a documented operations runbook and a retainer scope that covers upgrades and testing.
What to confirm before committing to midPoint for attestation
Before you commit, confirm in a pilot that midPoint produces the attestation evidence your auditors and reviewers already accept. The access certification documentation describes campaigns, stages, reviewer rules and remediation, but it does not tell you whether the report layout, field names and sign-off record match what your current One Identity Manager attestation exports contain. Take a sample of recent attestation reports, list every column and approval field your auditors rely on, and ask Evolveum or run a test campaign to show which of them midPoint can export, in which format, and whether reviewer decisions carry timestamps and reviewer identities in the same way.
Next, check connector coverage against your actual target systems rather than the general connector list. The documented connectors include LDAP, Active Directory, CSV, DatabaseTable, ScriptedSQL, Microsoft Entra ID and SCIM2, but many of your systems may fall in the further catalog, where status ranges from supported to community and experimental. For each target that is in scope for attestation, confirm the connector's status, the attributes and entitlements it reads back for review, and whether it can revoke access in the target system when a reviewer removes it. For SAP and Active Directory in particular, ask Evolveum and your own SAP and directory teams to confirm which entitlement types the connector exposes to a certification campaign, since the review is only as complete as the data the connector reads.
Finally, confirm audit log retention and how it is set against your evidence policy. Ask how long midPoint keeps certification history, campaign definitions, reviewer decisions and the audit records of revocations, where those records are stored in your PostgreSQL repository, and how you export them before any cleanup job runs. Plan a test that closes a campaign, reruns it for unresolved cases and then retrieves the full history, so you know the evidence survives the operations your team will actually perform. Support tiers, including the 8x5 and 24x7 options described on Evolveum's support page, matter here as well: agree in writing who answers when a certification run fails during an audit window.
How DeployOpen scopes and delivers attestation replacement
DeployOpen plans, implements and hardens self-hosted midPoint inside your own infrastructure, including the access certification campaigns that replace One Identity Manager attestation. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory every attestation policy, approver group and review cycle currently running in One Identity Manager.
- Map each approver rule to a midPoint certification definition, scope and reviewer rule, and record the gaps.
- Agree in writing which evidence reports auditors expect, and which assessment you will hand to your external auditor.
How we build
- Configure certification definitions, stages, escalation timers and remediation modes in a non-production midPoint environment.
- Test revoke, reduce and delegate outcomes against sample accounts, and confirm automated remediation matches your approved policy.
- Document configuration, connector settings and review procedures so each campaign can be repeated and explained to auditors.
How we hand over
- Deliver runbooks for launching, monitoring and closing campaigns, including how unresolved cases are rerun.
- Transfer configuration to your team through walkthroughs and a written record of every decision and deviation.
- Provide evidence packages that show campaign outcomes, reviewer decisions and remediation logs for your auditors to assess.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Plan upgrades against midPoint release dates, such as the support windows for the 4.8 and 4.10 releases, before each campaign cycle.
- Agree in the written scope who maintains connectors and certification definitions, and what changes require a new review.
