For employees
Ask for access.
Follow its progress.
Choose from a readable catalogue and see where your request stands. You have a place to check before chasing IT for an update.
A clear next step.Home / easyIGA / Compare with midPoint
easyIGA + midPoint
Access decisions.
Made easier for your team.
Request access, understand what you are approving and see whether the change actually happened.
easyIGA puts everyday identity governance into plain language. Your team gets a focused workspace, with midPoint doing the technical work underneath.
What your team gains
Less chasing.
More information when it matters.
Built for employees, managers and reviewers, with specialist controls kept in midPoint.
Ask for access.
For managers
Know what you
are approving.
See the request's purpose and conflicts reported by the configured policies before deciding. Understand the access, instead of approving a technical name.
Context beside the decision.For access reviewers
Review access
with the facts beside it.
See the person, their access and the available history together. Missing evidence stays visible, so you know what needs a closer look.
Evidence you can question.For everyone following up
See whether access
actually changed.
An approval starts the next step. easyIGA shows whether the outcome is verified, pending, failed or unknown, so unfinished work stays visible.
An honest answer about the result.These workflows use your configured access model and connected systems. Historical evidence depends on what has been recorded.
The difference at a glance
midPoint runs the governance.
easyIGA makes it easier to work with.
midPoint already offers self-service, approvals and access reviews. easyIGA adds a dedicated experience for the people making everyday decisions.
| Your task | midPoint provides | easyIGA adds |
|---|---|---|
| Request access | Self-service and request processing. | A readable catalogue and clear request progress. |
| Make a decision | Approval rules and policy checks. | Business context and reported conflicts beside the decision. |
| Review existing access | Certification campaigns and follow-up actions. | A focused review workspace with available history and visible evidence gaps. |
| Follow the result | Operations and results across connected systems. | Understandable outcome states that distinguish approval from completion. |
| Run the system | Open source midPoint, connectors and administration tools. | A business workspace while specialists retain the native controls. |
No software licence fee for the midPoint core.
easyIGA is a commercial layer. Implementation, integrations and support are scoped for your organisation. See pricing and costs →
Access requests
Find the access you need.
Know what happens next.
The catalogue and request status turn a technical process into a task an employee can follow.
Start with the work you need to do.
An employee usually knows the work they need to do. They may need to approve invoices or use a project application. They should be able to recognise the right access without learning how an identity specialist has named the underlying role.
easyIGA presents requestable access through a readable catalogue. Your organisation supplies the business meaning and decides which access people can request. The user works with that explanation, while the configured identity model continues to determine what the request means underneath.
That is the practical difference a business workspace should make. The employee can concentrate on their task. The specialist can keep the precise role definitions, mappings and policies needed to operate the system.
Keep the request visible after it is sent.
Once a request is submitted, the next question is usually simple: what is happening with it? easyIGA gives the requester a way to follow progress. A visible status provides a useful answer before someone sends another email or opens a support ticket.
Think of John Smith moving into Finance and requesting access to approve invoices. This is an illustrative example, not a customer story. John can follow that request rather than assuming that pressing Submit has already given him access to the application.
midPoint already includes native self-service. easyIGA adds a separate, focused experience for this everyday work. The value is in how clearly a person can choose access and understand its progress, with technical administration still available to the specialists.
Approvals
Give managers enough context
to make a real decision.
The request, its purpose and reported policy conflicts belong beside the approval decision.
Explain the access before asking for approval.
A manager needs to understand what the employee is asking for and why it matters to their work. A role identifier on its own rarely tells that story. easyIGA brings request context into the decision view so the approver can judge the request in business terms.
In the Finance example, Sarah Wilson is the manager considering John's request. The useful discussion is about his responsibility to approve invoices and the access that would support it. Sarah should be able to relate the requested permission to that responsibility.
The configured approval process determines who has authority to decide. easyIGA presents the business task within that process. Your organisation keeps responsibility for the approval policy and for deciding which permissions need an owner or an additional reviewer.
Bring known conflicts into the decision.
Some combinations of access should not belong to the same person. A finance policy might separate creating a supplier from authorising a payment. This is often called separation of duties, or SoD. The actual rule must reflect your organisation's processes.
easyIGA displays conflicts reported by midPoint's configured policies at the moment of decision. The manager can see a known conflict while assessing the request. That makes the control part of the working conversation, where it can influence what happens next.
This is a current distinction worth seeing in the walkthrough. The rule already exists in midPoint, and easyIGA makes its result understandable to the approver. Creating and simulating new rules inside easyIGA belongs to the planned capabilities described later on this page.
Access reviews
See what someone has.
Decide what they still need.
Reviewing access should help someone make a judgement, not simply finish a list.
Review the person and the permission together.
Access can outlast the reason it was granted. Someone changes teams, a temporary assignment ends or an application takes on a different purpose. A review gives the responsible person a chance to decide whether existing access still makes sense.
easyIGA puts the person, the access under review and the available history into a focused reviewer workspace. The reviewer can connect the permission to the person's work instead of treating each line as another checkbox to clear.
midPoint provides the underlying certification capability, including campaigns and follow-up mechanisms. easyIGA adds the business-facing review experience. The point is to help the person responsible understand the item well enough to make and record a considered decision.
Keep gaps in the evidence visible.
Older access does not always have a complete story. A permission may have been granted before the current request process existed. Another change may have happened outside easyIGA. A connected application may not provide a useful last-use signal.
Those are different situations, and the interface should not replace them with a confident explanation. easyIGA shows the available evidence and makes missing information visible. A reviewer can distinguish an established fact from something that needs more investigation.
A complete-looking screen is less useful than a trustworthy one. If the original approver is not recorded, that gap should remain a gap. The person reviewing the access can then ask the right owner for context and keep that uncertainty in mind when deciding.
Make the recorded decision useful afterwards.
The review matters beyond the moment someone chooses to keep or revoke access. The next person may need to understand what was decided and whether the follow-up succeeded. Connecting the decision with the available record gives the organisation something more useful than a completion count.
The depth of history depends on the release, configuration and source records. During a walkthrough, include an older permission as well as a recent request. That shows how easyIGA handles the evidence your team is likely to have, including its gaps.
A clear result
Approved is a decision.
Verified is a result.
This is one of easyIGA's strongest principles: an unknown outcome never becomes a reassuring success message.
Follow the change beyond the approval.
A manager can approve a request while the destination application is unavailable. The decision is valid, but the employee still cannot do the work. Treating those events as the same thing would leave the employee with a success message and no usable access.
easyIGA keeps the decision separate from the recorded outcome. The team can see whether the operation has completed, needs attention or cannot yet be confirmed. That distinction is especially useful when someone is waiting to start work or when sensitive access should be removed.
Four states that say what is actually known.
Verified means the recorded evidence confirms the access outcome. Pending means completion or confirmation is still awaited. These states distinguish a result the system can support from work that remains in progress.
Failed identifies an operation that reported a failure. Unknown means the available information does not establish the outcome. Missing information is not counted as success, and it is not automatically treated as the same thing as a reported failure.
For John's Finance request, the distinction answers a practical question: should he try the application now, wait for the change, or ask for help? For the support team, it keeps the unresolved part of the process visible instead of burying it behind the approval.
Apply the same care when removing access.
A decision to revoke access also needs a recorded result. If the target cannot be observed, the record should not imply that the permission has definitely disappeared. The person responsible for follow-up needs to know what has been established and what remains unresolved.
Confirmation depends on the connected system and the evidence the integration makes available. easyIGA makes that boundary understandable. Your implementation defines how each target is checked and which team follows up on unsuccessful or unconfirmed changes.
Simple on the surface
Your people focus on the decision.
Your specialists keep control.
We built easyIGA around a simple idea: the person responsible for access should understand the tool they use to manage it.
Standard midPoint remains underneath. Its administration interface stays available for configuration and technical investigation.
Explore deployment →Your team's workspaceeasyIGA
Readable requests and decisions.
Available evidence in context.
Identity governance with midPointmidPoint
Configured policies and access changes.
Connections to your applications.
Connected applications
Give your team one working view
across the systems you connect.
One business experience can sit above different applications without pretending their integrations are identical.
Manage application connections through midPoint.
easyIGA uses midPoint's connector foundation to work with connected applications. That keeps the technical integration where it belongs while giving employees and managers a shared place for access requests and reviews. The business user does not need to operate the connector.
An integration still needs to match the application. Reading accounts, changing group membership and removing access are different operations. Your deployment scope identifies which of them are supported, which permission types are included and how their results can be observed.
The midPoint connector catalogue is the starting point for that work. A listed connector is a route to assess, rather than a promise that every version and permission model works unchanged. We scope the connection around the access your organisation actually needs to govern.
Keep specialist control available.
Identity specialists continue to use midPoint's administration environment for configuration and technical investigation. They can work on the underlying policies and resource settings while business users stay focused on their decisions in easyIGA.
This division avoids asking everyone to use the same level of technical detail. It also preserves a direct route to midPoint for the people responsible for maintaining it. The easyIGA workspace and specialist tools serve different jobs over the same governance foundation.
Deployment and ownership
Keep your infrastructure.
Get help with the implementation.
Self-hosted by default.
easyIGA is self-hosted by default, on your infrastructure and in your jurisdiction. That gives your organisation a direct role in how the environment is operated. Hosting, backup and monitoring responsibilities should sit with the teams named in your deployment scope.
For organisations without suitable infrastructure, an EU-hosted deployment operated by our team is available on request. The service responsibilities and terms are agreed for that deployment. The option gives you another way to run the product without implying that every organisation needs the same operating arrangement.
An open foundation with a commercial workspace.
Standard midPoint remains available, alongside your configuration, if you stop using easyIGA. The commercial workspace is a separate part of the arrangement. Data export and handover should be covered in the deployment agreement so the practical responsibilities are clear.
The appeal of an open foundation is more than the absence of a core software licence fee. Your specialists can work with midPoint and its public documentation. You retain a recognisable platform underneath the business experience rather than depending on a hidden replacement.
Work with a team that knows midPoint.
Our team brings midPoint delivery experience to the product and its implementation. That experience helps connect the business task to the access model, policies and applications that make it work. It is provider experience, distinct from evidence about easyIGA customer deployments.
Our consulting and implementation services cover the surrounding work, including midPoint setup and integrations. We agree the scope around your environment. Your team gets a clear division between using easyIGA, configuring midPoint and operating the deployment.
Why we built easyIGA on top of midPoint: read the background.
Costs and fit
Pay for a clearer way to work.
Compare the full operating cost.
The comparison is between ways of running identity governance, with the same applications and responsibilities in scope.
Understand which part you are buying.
midPoint has no software licence fee for its open source core. Some midPoint capabilities, such as simulations, high availability clustering or a database other than PostgreSQL, need an Evolveum subscription, which we arrange and include in your quote. easyIGA adds a commercial business workspace. Implementation, integration work and ongoing operation also belong in the budget, whichever interface your organisation chooses to use.
The reason to consider easyIGA is the work it makes clearer for your people. Employees can follow requests. Managers see decision context. Reviewers work with available evidence. Specialists retain technical control. Those are concrete tasks to compare against your current process.
Use your own numbers for the business case.
A useful cost comparison includes the time your organisation spends supporting these tasks. Record how often people ask for status updates, how much help reviewers need and which routine questions reach identity specialists. That gives you a practical baseline for the walkthrough and any later evaluation.
Our pricing page and calculator provide a way to structure the discussion. Use your own volumes, observed handling time and agreed cost assumptions. Any saving should follow from what changes in your environment, rather than a universal percentage applied to every customer.
Choose the approach that fits your users.
If your existing midPoint interface already works well for the people making decisions, that is a valid starting point. easyIGA is most useful to evaluate where the business task needs a clearer explanation, easier progress tracking or a more focused review experience.
Bring that task to the walkthrough. An employee and an application owner may notice different things, and both perspectives matter. The strongest case for an additional workspace is one your own people can explain after using it.
The complete experience we are building
Understand the decision.
See the effect before you act.
Our goal is everyday access governance that business users can run with confidence. The direction below extends the request, approval and review workflows described above.
Define and test access-conflict rules.
Create separation-of-duties rules in easyIGA and examine their effect before applying them. Today, easyIGA shows conflicts reported by policies already configured in midPoint.
Ask a question in everyday language.
The goal is to ask about access in everyday language and understand the evidence behind the answer. AI assistance must show its reasoning, with people responsible for approving access changes.
What the completed experience should feel like.
A manager should be able to understand an access question, see the relevant evidence and make the decision they are responsible for. An employee should know what they can request and what is happening afterwards. Specialists should have the depth they need without exposing that complexity in every business task.
That is the direction described in our Manifesto and product story. Simple by default, with detail available when it helps. The information remains grounded in the identity system. The experience is organised around the person doing the work and the next decision they need to make.
Extend the workflow without losing accountability.
The planned rule-design experience would let a team examine a separation-of-duties rule before applying it. It extends the existing presentation of configured conflicts into work on the rules themselves. Those are separate capabilities, which is why the planned step has its own status.
Plain-language assistance follows the same principle. A useful answer should explain the access and the evidence supporting it. A recommendation should give its reason. The person remains responsible for an access-changing decision, with the configured authority and midPoint controls still in place.
Know what you can adopt today.
The target experience describes what we are building towards. Current requests, approval context, reviews and outcome states can be discussed against a specific release. Planned rule authoring and the wider assistance direction need to be assessed separately from that current scope.
This separation helps you make a practical choice. You can judge the workflows available for your project while understanding where the product is heading. When a planned capability is essential to your adoption, bring that requirement into the conversation before agreeing the implementation.
Planned capabilities have no release date committed here. See current and planned scope →
See easyIGA in use
Bring one access question.
We will show you how the work flows.
Walk through a request or review with our team and see the current capabilities in context.
Request a walkthroughSources and product notes
Based on the easyIGA Manifesto, product story and documented scope, checked 7 October 2026. Written by the easyIGA team. Planned capabilities are labelled above; the page does not claim that the full product direction is already delivered.
midPoint references: native user interface, approvals and access certification. Functionality depends on the release and configuration.
The photograph is illustrative, used under the Unsplash Licence. It does not show our office or a customer environment.