See easyIGA
Home / easyIGA / Key features

Identity governance and administration

Make access decisions
people can understand.

easyIGA helps your team request, approve and review access to your organisation’s applications. It puts the business decision in a readable workflow, with the open source midPoint platform carrying out configured changes.

For managers who decide and identity specialists who make it work.

From a business need to a recorded outcome
  1. EmployeeRequest application accessChoose a business name from the catalogue.
  2. ApproverDecide with contextReview the request and configured policy results.
  3. midPointCarry out the changeApply the configured role and integration.
  4. easyIGAShow the recorded resultVerified, pending, failed or unknown.

Illustrative workflow, not a product screenshot.

The product in use

Connect the access decision to what happened next.

Identity governance and administration, or IGA, brings oversight to the way people receive and keep access. It connects a person's responsibilities to the permissions they need, the person who authorises them and the systems that apply them. For a business manager, that should mean a clear decision. For IT, it should mean a configured process with an outcome that can be checked.

easyIGA gives those people a shared way to work with access. An employee starts with a business name. A manager sees the request and the available context. Identity specialists retain the midPoint configuration underneath. The same request can then be followed beyond approval, so a positive decision is not mistaken for a completed change.

The practical starting point is one workflow you recognise. It could be finance application access, a change of department or a review of permissions that have accumulated over time. The sections below explain the work involved and the product boundaries to check during a demonstration.

Access requests

Ask for the access you need by its business name.

An employee should not need to know the name of an internal directory group to ask for an application. easyIGA provides a readable catalogue as the starting point for access requests. The catalogue connects the business description to the configured role, so the person requesting access can understand what they are asking for.

The organisation still decides which roles are requestable and who must approve them. Identity specialists maintain those rules in the underlying configuration. A useful catalogue therefore needs meaningful names and ownership, as well as a working connector. Renaming a technical permission is only useful if the description accurately explains its purpose.

Consider an illustrative request for access to a finance reporting application. The employee selects the relevant access, submits the request and follows its progress. They can see whether the process is waiting for a decision or whether the recorded result needs attention. This gives the requester somewhere to look before sending another message to IT.

During evaluation, use a real role from your organisation. Check that the description makes sense to its users and that the correct decision maker receives the request. Then follow the request through the target-system result. Explore access requests.

Approvals and policy checks

Give the person who approves enough context to decide.

Approval is a business responsibility. The person deciding needs to understand the requested access and why it is relevant. easyIGA brings the request together with the results of configured midPoint policies, keeping the decision close to the information that supports it.

Microsoft Teams is an approval channel. For a team that already works there, this places an access decision in a familiar setting. The exact workflow and evidence fields supported by your proposed release should be part of the demonstration. An approval channel is useful only when its decisions remain accountable and its supported scope is clear.

See a known conflict before access is granted.

Segregation of duties, often called separation of duties or SoD, addresses combinations of permissions that your organisation has decided should not sit with the same person. easyIGA evaluates and displays the result of midPoint's configured exclusion policies at decision time. The approver can see a conflict known to that policy before making the access decision.

For example, your policy might restrict a combination of supplier maintenance and payment approval. That is an illustrative policy choice, not a preconfigured rule promised for every customer. Your specialists define the relevant roles and exclusions. Available: configured policy conflicts shown at decision time. Planned: rule authoring and simulation inside easyIGA.

Test an ordinary request and a conflicting request with your own policy. The demonstration should show the difference in the decision flow. Read about approvals and SoD controls.

Follow the result

Approved does not mean done.

A manager can approve a request while the destination system is unavailable or the configuration still needs attention. easyIGA keeps the recorded outcome separate from the decision.

Verified

The recorded evidence confirms the outcome.

Pending

The operation has not yet reached a final outcome.

Failed

The operation did not complete successfully and needs attention.

Unknown

There is not enough confirmation to treat the work as complete.

These states give a requester and an operator a more useful answer than a single approved label. They also help a reviewer distinguish the decision from the evidence of execution. The quality of that confirmation depends on the connected system and the records available.

Joiners, movers and leavers

Make identity changes part of a governed process.

A new employee needs access for their role. A department change can require removal as well as new permissions. A departure needs an explicit decision about the access that should end. These are different events, even when they concern the same person.

midPoint connects authoritative identity data with configured policies and target systems. easyIGA adds readable requests, decisions and reviews to that process. When an employee changes teams, the organisation can consider the access needed for the new role alongside permissions that should end. Each source has a defined responsibility for the identity data it supplies.

Consider a colleague moving from Operations to Finance. They need access for their new responsibilities, but an old administrative role may no longer be appropriate. A governed process brings both changes into view. The responsible person can decide what stays and what ends, with the resulting changes handled through the configured integrations.

The source data matters. An incorrect manager or an absent end date cannot be fixed by a more attractive approval screen. Define who corrects those records and how exceptions reach the right operator. Your implementation and acceptance tests should cover delayed source updates and failed target changes alongside the ordinary successful path.

Access reviews

Review access with the evidence available.

Access reviews ask whether someone still needs a permission. easyIGA puts the person and the access under review alongside available history, so the reviewer has a basis for the decision. Last use, granted by and approved by are useful context when the connected systems and captured approval history provide them.

Those fields answer different questions. Usage can indicate activity; it does not prove that access is appropriate. A grantor identifies who recorded a grant; an approver identifies who authorised it. Treating the current account owner as either person would create a history that never existed.

easyIGA retains the requester, request time and captured approval stages in their recorded order. When a direct grant has no matching easyIGA request after the request records have been checked, it is marked as granted outside easyIGA. The record shows the creation account, channel and time available from midPoint. The creation account is not treated as a human requester. Missing historical approval steps and unrecorded grantors remain clearly identified; easyIGA does not reconstruct decisions that were never captured.

A useful review example contains ordinary access and an item with incomplete history. Ask the reviewer to explain their decision from the information shown. Then follow any removal decision through to the recorded outcome. This checks both the quality of the review and the work needed to act on it. Read about access reviews.

Evidence and ownership

Know which records support an access decision.

An access record is useful when someone can follow its meaning. The request, the decision and the result each describe a different part of the process. easyIGA presents the recorded outcome so the team can investigate a pending or failed change instead of counting it as completed work.

For audit preparation, establish which records your control owner needs and which systems supply them. Check the demonstrated export for the release being evaluated. Confirm that the exported fields preserve the distinction between an approval and a verified result. Retention and access to evidence also need agreed operating rules.

Resolve ownership without inventing it.

An account without a confirmed person or responsible owner deserves investigation. A service account may be necessary for an application even when it does not belong to an employee. Removing it solely because it has no employee match can interrupt a legitimate process.

The evaluation should separate employee correlation from responsibility for non-human identities. Review the evidence used to associate an account with a person, and agree who investigates an unresolved case. The orphaned-account and non-human identity page explains this area; confirm its current workflow and coverage in the proposed release. For the records themselves, see audit evidence.

Who easyIGA helps

Keep each person focused on their responsibility.

Employees and managers

Employees start with an understandable access request. Managers decide with the information available beside it. They can participate in governance without working in midPoint’s administration console.

IT and identity specialists

Specialists retain the configuration and integrations. They define how roles map to systems and investigate operations that need attention. The business workflow gives other participants a clearer way to provide decisions.

Security and control owners

Control owners can evaluate how configured conflicts appear, what a reviewer sees and which outcome records support the control. Evidence gaps become questions to resolve rather than assumptions hidden in a completed checklist.

Procurement and budget owners

Buyers can compare the commercial layer, implementation scope and operating effort. A demonstration tied to a real workflow helps them assess what they are paying for before estimating a business case.

Built on midPoint

Open source midPoint, with easyIGA for everyday decisions.

midPoint is an open source identity management and governance platform. It provides the foundation for identity synchronisation, policies and provisioning. Its public documentation gives technical teams a way to examine midPoint and understand its configuration.

easyIGA uses that foundation and adds its business-facing experience. This is useful when managers need to participate in access governance while identity specialists keep responsibility for the underlying systems. It does not mean that every midPoint administration function becomes an easyIGA screen, or that every feature in midPoint has an identical easyIGA workflow.

Why we built easyIGA on top of midPoint: read the background.

Responsibilities to compare during an evaluation
AreamidPoint foundationeasyIGA contribution
Identity data and target changesConfigured sources, roles and provisioning.A business workflow connected to the recorded result.
Access decisionsPolicy and approval mechanisms.Readable requests and decision context for participants.
Policy conflictsConfigured exclusion policies.The evaluated conflict shown at decision time.
Review evidenceSource records and midPoint history.Available context with evidence gaps kept explicit.

A connector can support different operations depending on the application version and configuration. We confirm the operations your team needs when designing the integration. The midPoint connector catalogue describes the available options. Our comparison with midPoint explains how those technical connections support the work people do in easyIGA.

Access controls and regulatory evidence

Support the access-governance work behind DORA, NIS2 and CER.

These frameworks have different purposes and scopes. IGA contributes to the management of identities and access within the controls an organisation implements. A product does not establish compliance by itself. The practical question is which decisions and records your control owner needs, and whether the configured workflow supplies them.

Regulation (EU) 2022/2554

DORA

DORA addresses digital operational resilience in the financial sector. Article 9 includes policies limiting logical and physical access to what legitimate, approved functions require, with procedures for administering access rights. An IGA evaluation can examine the logical-access part through requests, responsible approvals and the records of changes.

For easyIGA, demonstrate a relevant role, the configured decision path and the resulting target change. Add a failed operation to the test, so your control owner can see what requires follow-up. Wider DORA obligations, including resilience testing and third-party risk, require additional measures. Explore the DORA context.

Directive (EU) 2022/2555

NIS2

NIS2 Article 21(2)(i) includes human resources security, access control policies and asset management within cybersecurity risk-management measures. Identity governance provides a place to connect access decisions to the organisation's roles and policies.

Use a department change or departure as an evaluation case. Check who owns the identity data, which permissions the policy changes and what confirms the result. Access reviews can examine permissions that remain. Your organisation must assess its applicability and the relevant national implementation; the software is one part of the control environment. Explore the NIS2 context.

Directive (EU) 2022/2557

CER

The Critical Entities Resilience Directive covers resilience beyond cybersecurity. Article 13 includes personnel security and procedures concerning access to premises, critical infrastructure and sensitive information. Its scope should not be reduced to a software checklist.

easyIGA's relevant contribution is the governance of access in the connected identity and application environment. For example, an organisation can assess how a contractor's changing responsibilities affect application access. This does not establish physical-access integration or deliver business continuity planning. Those controls and their evidence need separate assessment.

IGA licensing and cost

Understand what you are buying.

Review the pricing model →

When comparing IGA licensing, separate midPoint from the product and the work required to operate it. midPoint has no software licence fee. 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 is a commercial product built on midPoint. Infrastructure, integration and support still have a scope and a cost.

easyIGA is priced as an annual subscription per governed identity, including employees, contractors and service accounts. Deployment is included within the agreed scope. Your written offer sets out the price and capabilities covered. The pricing page explains what goes into a quote.

Ask how the supplier counts an identity and what happens when the population changes. Confirm the applications and environments in scope, as well as the supported operations. Clarify which migration work is included, who cleans the source data and how acceptance is measured. These questions prevent two differently scoped offers from appearing comparable because they share a per-user label.

For a cost comparison, include recurring software and support, infrastructure, one-off implementation and internal operating effort. Keep released staff capacity separate from cash savings. A reduction in handling time does not automatically reduce payroll. The savings calculator uses your inputs so you can examine assumptions without treating a hypothetical percentage as a measured easyIGA result.

Also compare the option of operating midPoint alone. Your team may already have the required skills and processes. The additional question for easyIGA is whether its business-facing workflows solve a problem worth paying for in your organisation. A scoped demonstration and a written offer provide a better basis for that decision than a generic product ranking.

A practical evaluation

Bring one access workflow you want to improve.

Start with the application, the people who need access and the person who approves it. Include a role description that a manager understands. Identify the authoritative source for the person and their reporting line. This gives the walkthrough a concrete business task instead of a tour of unrelated screens.

Next, choose a case that needs attention. It might be a policy conflict, a missing approver or a target that cannot confirm a change. Agree what a correct result should look like before the demonstration. The important observation is how the team recognises and handles the exception.

Deployment is self-hosted by default, on your infrastructure and in your jurisdiction. An EU-hosted deployment operated by our team is available on request for organisations without suitable infrastructure. Review responsibilities for operation and evidence retention alongside the deployment options and security information.

Our team has delivered 14+ midPoint deployments. This is the team's delivery experience, separate from easyIGA product adoption. Ask to see the current release and the workflows you intend to buy. Record the demonstrated scope, the gaps and the acceptance conditions, then use those facts to decide what comes next.

Request a 30-minute walkthrough

See the workflow with our team and discuss your organisation’s needs.

Before you decide

Questions buyers bring to the demo.

Does easyIGA replace midPoint?

No. midPoint remains the underlying identity governance platform. easyIGA provides its business-facing workflows above it. Your specialists still need to configure the sources, roles and target integrations that govern your environment.

Is easyIGA free because midPoint is open source?

No. midPoint has no software licence fee. 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 has a commercial subscription model. Compare the full agreed scope, including services and operation, and obtain current pricing for the identities and capabilities you need.

Can we use it for DORA, NIS2 or CER work?

Assess it for the identity and access controls relevant to your organisation. Requests, configured policy checks and available evidence can support that work. Applicability, broader controls and a conclusion about compliance remain separate organisational responsibilities.

Will every review show who granted and approved access?

The record shows the available request and approval history, or identifies an external grant. Missing historical information remains explicit.