Keep access aligned
with essential work.

Keep responsibility visible across essential services

An electricity, gas or water organisation depends on people whose work spans offices, field locations and external service teams. Their application access should reflect the responsibility they have today. A contractor completing a maintenance assignment and an employee moving to another team both create an access decision that needs an accountable owner.

easyIGA gives employees and managers a readable way to request, approve and review application access. midPoint supplies the underlying identity governance platform and performs configured changes in connected systems. Business participants can take part in decisions while specialists maintain the identity model and integrations.

The useful starting point is a bounded service workflow. Choose an application with a clear owner, identify the people who use it and agree what confirms a successful access change. This turns a broad identity programme into a process the organisation can examine and test.

A field-team manager can explain the work a person is assigned to; an application owner can explain the access that work requires. easyIGA gives those people a common request and review process, connected to midPoint underneath. The illustrative scenarios below follow workforce changes and contractor assignments through that process. They focus on application permissions and the evidence around them, within the wider operating arrangements that keep an essential service running.

Begin with the applications around the operation

A utility can have maintenance planning, workforce scheduling and document systems alongside operational technology. An identity project needs to distinguish those application responsibilities before deciding what to connect. An account interface alone does not establish that automatic changes are appropriate for a particular operational system.

For a first phase, select an application whose role definitions and change process are understood. A maintenance planning role might be a suitable example if its owner can explain the difference between ordinary use and administration. The decision should follow the organisation's assessment, not a generic assumption about the industry.

Document what the integration needs to do. Reading accounts, changing a role and disabling access are different operations. Confirm how the target reports failure and what evidence it can provide for completion. An integration that exposes a user list is not proof that it can manage every entitlement.

easyIGA makes the supported business decision accessible through readable requests and reviews. midPoint handles the configured target changes underneath. The implementation team remains responsible for confirming the scope and testing it against the real application version.

Keep manual steps visible where they remain necessary. A named operator and a defined confirmation record can be part of a governed process. The important point is that the organisation knows which work is automated, which is manual and what evidence connects the decision to the actual target state.

Connect a field assignment to the access it requires

Consider an illustrative employee moving between regional maintenance teams. The new assignment can require access to different work orders or records. Some old permissions may remain for a handover, while others should end. A single account-active flag does not explain that transition.

Identify the authoritative source for the assignment. HR may own employment status, while another approved system holds the operational team. Agree how those facts are used and which owner resolves a disagreement. An identity model should not silently choose between contradictory records.

midPoint's configured lifecycle and provisioning mechanisms connect source changes to roles and target systems. easyIGA provides the business-facing request and review experience around the supported process. The quality of that experience depends on a role model that reflects the work.

In the pilot, show the permissions before and after the move. Check the access that should be removed as carefully as the access that should be added. If a temporary exception is justified, establish who owns it and how the organisation will revisit it.

Include a late source update in the test. The affected employee and the access owner need an agreed route for correction. A more readable screen helps people understand the task, but it cannot establish the correct operational assignment without reliable information and an accountable source owner.

Give external service teams a current sponsor

A supplier relationship can continue for years while individual workers and assignments change. Application access needs a more precise basis than the supplier's presence on an approved list. Each governed identity should be connected to the work being performed and an internal responsibility.

Start with an approved source for external-worker information. Establish the sponsor and the applications required for the assignment. The organisation should know who is authorised to approve access and who will decide whether it remains necessary when the work changes.

easyIGA's catalogue presents access through understandable business descriptions. The configured policy controls the decision path, and specialists map the approved role to target permissions. A clear description helps the sponsor make a decision without learning the technical name of every directory group.

Use an extension and a reassignment as evaluation cases. A contractor may remain with the same supplier while moving to another site or service. The correct permissions can change even though the underlying commercial relationship continues. Test that business distinction explicitly.

Also plan for an unavailable sponsor or an incorrect reporting record. The workflow should make the exception visible so the organisation can repair the underlying responsibility. It should not create a fictional approver or treat missing information as a reason to consider access authorised. A useful process makes uncertainty actionable.

Understand the boundary around operational technology

Identity governance can support accountability for application access, but operational technology introduces system-specific safety and availability considerations. The asset owner must decide which interfaces can participate in an identity process and under what change controls.

Draw the architecture around the approved scope. Show authoritative sources, the governance engine and the connected application targets. Mark systems that remain outside the integration. A clear boundary is more informative than a diagram suggesting that every device is automatically governed through one product.

For any sensitive target, establish the effect of an account change. Determine how it is tested and who authorises it. The implementation should follow the organisation's procedures for operational changes and recovery. This page does not claim direct support for every control system or device.

The easyIGA workflow can make the business decision readable. midPoint can perform the operations that are configured and supported by the integration. Neither fact proves that a proposed change is appropriate for the physical process behind a particular system. That conclusion requires the organisation's specialist assessment.

Include the boundary in the acceptance evidence. Record the targets, versions and operations tested, together with any manual procedure that remains. If the initial phase governs only supporting applications, state that plainly. A well-defined first phase provides a basis for later evaluation without implying that untested operational systems are already covered.

Keep incomplete access changes visible

A manager may approve a request while the target is unavailable during planned maintenance. A removal operation may fail because the target rejects the instruction. The organisation needs to see that distinction rather than assume the business decision completed the technical work.

easyIGA distinguishes verified, pending, failed and unknown outcomes. The states give business participants and operators a shared way to discuss the result. Verification depends on the target's records and the configured integration, so the evidence should be examined for each application in scope.

A useful utility pilot includes an unavailable destination. Observe the state while the target cannot be reached and the evidence produced after service returns. Do not describe a disconnected system as immediately updated simply because a central decision has been recorded.

Agree who handles outstanding operations. The identity team may diagnose the integration, while an application owner resolves a target-side issue. The requester should receive a meaningful account of progress, and the control owner should know which changes remain unconfirmed.

Reporting must preserve this meaning. An approval count and a verified-change count measure different stages. Keeping them separate helps the organisation identify work that still requires action. It also gives evidence reviewers a more accurate view of what happened than a single completed label applied to every approved request.

Review access against the work people still perform

A periodic review gives the responsible person an opportunity to reconsider permissions that were appropriate earlier. A worker may have changed region or finished a maintenance programme. Their current employment relationship alone does not establish the need for every old application role.

easyIGA presents access under review with available context. Last use, granted by and approved by depend on source-system records and the approval history captured by the product. Those fields should be interpreted separately, with any missing evidence kept explicit.

easyIGA records the requester and captured approval steps for requests made through the product. Access granted outside easyIGA is identified separately, using the creation details recorded by midPoint. Historical records may lack an approver or grantor; missing information is shown explicitly.

For a review example, include a continuing employee with an old site-specific role. Ask the business owner to explain whether that access is still needed. Include another record with incomplete history and agree the investigation route. Some permissions are used infrequently, so the absence of recent activity is information for a decision rather than an automatic removal rule.

When a reviewer decides that access should end, follow the target operation. The review owner needs a way to distinguish a recorded revocation decision from a confirmed change. This connects periodic oversight to the operating work needed to keep permissions aligned with current responsibilities.

Treat service-account ownership as an ongoing responsibility

An application interface can depend on an account created by someone who has since left the organisation. The account's purpose may remain valid even though its original creator is no longer available. A governance process should identify the responsible service owner and the permissions needed for that purpose.

Begin with one representative technical account. Document the application or process it supports and who can authorise changes. Avoid assuming that a matching employee record is always the correct ownership relationship. A service account can require a different lifecycle from a person's everyday access.

During an easyIGA evaluation, inspect the supported workflow for that account type. Check which attributes the source supplies and what remains an organisational decision. A list of discovered accounts does not by itself establish verified ownership or safe remediation.

Test a change in the owning team. The right action may be to update responsibility while keeping the service running, or to remove an account after its dependency has been retired. The application owner must understand the consequences and the evidence needed for the decision.

The orphaned-account and non-human identity page gives a starting point for the discussion. Credential storage, privileged sessions and machine authentication can require additional controls. Identity governance should make responsibility clear without implying that it replaces every technical security function around the account.

Place NIS2 and CER in the wider control environment

NIS2 includes access control policies within cybersecurity risk management. CER addresses wider critical-entity resilience, including personnel and access procedures. Their application must be assessed against the organisation's circumstances and relevant national rules. The official NIS2 and CER texts are the starting points.

For the product evaluation, translate the relevant requirement into an observable access-control question. Who authorises a role? What source supports the person's relationship? Which record shows the decision and the result? The product should be assessed against that defined task.

Keep the wider resilience programme visible. Application identity governance does not establish physical-site protection, continuity arrangements or emergency readiness. It can contribute records and decision processes within the configured scope, but those are only part of the organisation's responsibilities.

Agree the evidence needed before the pilot. A control owner may need to examine a sample that includes the request, the available approval history and the target result. Check the demonstrated export and its fields in the proposed release. Retention and access to the evidence also need operating rules.

This approach makes the regulatory discussion concrete without promising certification. The question becomes whether the configured workflow supplies a useful part of the organisation's evidence, and what remains to be provided by other systems and procedures. That is a decision the control owner can examine and document.

Build on midPoint without hiding the specialist work

midPoint is an open source identity management and governance platform. Its configuration supplies the foundation for identity data, roles and target-system changes. easyIGA adds the business-facing experience for requests and reviews around midPoint.

An organisation already using midPoint can evaluate the additional layer with an existing application role. Ask a manager to carry out the supported task and ask the identity team to explain what remains in midPoint configuration. The comparison should use the same scope and the same exception case.

For a new programme, establish the role model and authoritative sources first. The connector catalogue helps identify potential integration options, but target compatibility must be confirmed for the actual versions and operations. A familiar application name is not a complete integration specification.

The specialist work includes maintaining mappings and testing policy changes. A business-friendly interface does not eliminate those responsibilities. Instead, it gives the other participants a way to provide decisions without administering the underlying platform.

Evolveum's utilities page describes sector use cases for midPoint. For easyIGA, use a supporting application that your field-team manager and identity specialists both recognise. Demonstrate the business decision and then inspect its recorded outcome together. A shared example helps the team agree which part of the process has become easier to understand and which technical work remains necessary for the intended operating model.

Agree the operating model and the commercial scope

Self-hosting is the default easyIGA deployment model. An EU-hosted deployment operated by our team is available on request for organisations without suitable infrastructure. The appropriate choice depends on the utility's actual operating and data requirements.

Define who owns the service after implementation. Monitoring, updates and recovery need named responsibilities. If the organisation requires particular support coverage or recovery objectives, obtain those terms explicitly. A product description should not be interpreted as an agreed service-level commitment.

midPoint has no software licence fee, while easyIGA is commercial. 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. The published model uses an annual subscription per governed identity with deployment included in agreed scope. Confirm the current pricing and feature set for the actual employee, contractor and service-account populations.

A useful offer identifies the application instances and operations included. It also explains migration work, data cleanup and acceptance criteria. Sites with different systems or operating arrangements may require different integration work even when they use similar role names.

Use the pricing page and deployment information to prepare a comparison based on real scope. Include internal operating effort and transition cost. Measure any improvement in a pilot rather than applying an invented universal saving to the whole organisation.

Choose a first workflow that can prove its result

Select one supporting application with an accountable owner. Define the access role and the source of the identity information. Use synthetic identities for the initial discussion so the team can examine the process without exposing live personnel or operational data.

Include an ordinary request and a change in responsibility. Add an unavailable target and a record with incomplete history. These cases test the business decision, the technical operation and the treatment of uncertainty. Each should have a defined expected result.

Ask the business participants whether they can explain the access from the description. Ask the operators whether they can identify and resolve an exception. Record the exact release and configuration demonstrated, including any capability that remains planned or outside scope.

A successful first phase should produce a repeatable decision about expansion. The organisation should know which applications and operations have been verified and which need a separate assessment. Do not infer universal compatibility from one working connector or a service guarantee from one successful test.

Request a 30-minute walkthrough with our team. Bring a workforce-access question from your utility and use it to examine how easyIGA's business workflow and the midPoint foundation fit the responsibilities your team already has.