Clear access decisions.
Accountable defence teams.

Access should follow the responsibility a person has today

A defence organisation brings together military personnel, civilian employees and external specialists. The same person can move between assignments while retaining accounts created for an earlier responsibility. A contractor can finish one engagement and begin another with a different sponsor. Each change raises a practical question about the access that should remain.

easyIGA provides a business-facing way to request, approve and review application access. midPoint handles configured identity policies and changes in connected systems. This division lets the people responsible for access participate in decisions while identity specialists maintain the technical configuration.

For a defence team, the value should be assessed against a specific process. Start with a workforce application and a defined group of users. Establish who owns the identity information, who can authorise access and which record confirms a completed change. A clear handover helps the officer making the decision and the operator responsible for applying it work from the same understanding.

For an officer responsible for an administrative team, the question is practical: does this person need this application role for their current assignment? easyIGA brings that decision into a readable request and review process. The officer can concentrate on the purpose of the access, while the identity team maintains the connection to the application. The illustrative workflows below follow that handover through assignment changes, contractor access and the evidence needed when someone asks why a permission remained.

Make changes of assignment visible in the access process

A new assignment often changes the information someone needs. Simply adding the permissions associated with the new role can leave the previous access in place. An identity programme should therefore treat a move as a review of existing responsibilities, not only a request for additional accounts.

Begin with an authoritative personnel source and the attributes that the organisation is prepared to use in policy. An organisational unit, employment relationship or approved assignment can have different meanings. An implementation team must establish those meanings before using them to drive a target-system change. Sensitive personnel information also needs a defined purpose and access boundary.

midPoint provides identity lifecycle and provisioning mechanisms that specialists configure for the organisation. easyIGA brings the request and review work into a business-facing workflow. midPoint's technical flexibility does not remove the need for a clear rule about which permission follows which event.

In an evaluation, use a fictional person moving between two administrative teams. List the access required before and after the move. Demonstrate how the configured process handles each affected system, then inspect the recorded result. Include an application that does not return an immediate confirmation. The team should be able to tell whether the desired change was verified, remains pending or needs investigation.

Also decide what happens when the personnel source arrives late. The responsible officer or manager needs an escalation route for an urgent correction. The identity platform should sit within that operating procedure, with responsibilities established before a live dependency is introduced.

Give contractors an accountable business sponsor

A contractor's employer is not necessarily the person who can justify their access inside the organisation. Procurement may know the contract, while an application owner understands the work. An identity-governance design needs an accountable sponsor and a clear description of the access being requested.

A useful contractor evaluation begins with a limited assignment. Identify the applications involved, the purpose of access and the person responsible for its continued need. If validity dates are part of the configured process, confirm how they are recorded and what event drives the eventual change. Do not assume that a date in a procurement document automatically reaches every target system.

easyIGA's readable requests help participants work with business descriptions rather than technical group names. The configured policy still determines the decision path. Your specialists must map the approved request to the correct permissions and establish how a change is confirmed.

Test a sponsorship change as well as the end of an engagement. If the sponsor leaves or moves, access should not remain without an accountable decision maker simply because the contractor still has an active record. Agree who inherits the responsibility and which cases need a fresh review.

This is also a good place to examine exception handling. A missing manager or an incomplete source record should be visible as work to resolve. It should not become an invented approval or a silent success. A precise exception is easier to investigate than an apparently completed request whose business authority cannot be reconstructed.

Put clear decisions around social-engineering risk

Social engineering can exploit uncertainty about who is entitled to ask for access and who is authorised to approve it. A convincing message is harder to challenge when the organisation has no consistent request process or the approver cannot see what the requested permission allows.

Identity governance gives the organisation a structured place for that decision. In easyIGA, an access request is connected to the configured workflow and available policy results. The approver should assess the actual request rather than rely on a message saying that access is urgently required. Your procedures still determine how a person's identity and authority are verified.

Governance is one component of the security architecture. Authentication, endpoint controls and incident response address other parts of the problem. NIST's Zero Trust architecture rejects implicit trust based only on location or ownership; it does not turn the presence of an IGA product into a complete Zero Trust implementation. The relevant source is NIST SP 800-207.

An appropriate evaluation includes a request whose stated urgency does not change the required approval authority. Check that the approver understands the business role and the policy result. Separately verify your authentication and escalation procedures. This gives the team a repeatable way to examine urgent requests while preserving the organisation’s required checks.

The practical outcome to look for is a decision that the responsible person can explain. Who requested this access, what was approved and what happened afterwards should be answerable from the records that are actually available.

Check incompatible responsibilities before granting access

Some permissions create an unacceptable combination when held together. The organisation must define that conflict in terms of its own work. A maintenance role and an authorisation role may need separation in one process, while another process has different compensating controls.

easyIGA displays the evaluated result of midPoint's configured exclusion policies at approval time. A conflict known to that configuration can therefore be presented before the decision. This gives the approver relevant information at the point where it matters.

The distinction between configuration and use is important. Your identity specialists maintain the relevant roles and policy definitions. Rule authoring and simulation inside easyIGA are planned capabilities, not current functionality claimed on this page. A midPoint feature must not be assumed to have an equivalent easyIGA screen.

Build a demonstration around an agreed illustrative conflict. Show an ordinary request first, then a request that conflicts with an existing role. Ask the responsible reviewer to explain the difference using the information presented. Record the behaviour in the proposed release rather than relying on a slide about future functionality.

Policies also need ownership after deployment. Assign responsibility for changes when organisational duties evolve. An old rule can be as misleading as an absent one if its meaning is no longer understood. Include policy review and testing in the operating model, particularly before changing a role used by many people.

Follow an approval through to a recorded outcome

An approved request expresses a decision. The target-system operation can still fail, remain in progress or lack enough evidence for confirmation. Treating those situations as completed work would hide an operational task from the people who need to resolve it.

easyIGA distinguishes verified, pending, failed and unknown outcomes. That vocabulary connects the request to its recorded state without assuming that a manager's approval proves the destination changed. The confirmation available depends on the target and the configured integration.

Use an evaluation case with a reachable application and another case with an unavailable destination. Check what the requester sees, what the operator investigates and which record later establishes completion. A system that is disconnected cannot be assumed to accept an immediate revocation. The operating procedure must account for the period before a change is applied and confirmed.

Agree who monitors outstanding operations and which situations require escalation. An identity programme needs a practical handover between the person making the business decision and the specialist handling the technical exception. Showing a status is useful only when the organisation understands who acts on it.

For reporting, keep the distinction visible. An approval-completion count and a verified-change count describe different things. The evaluation should show the underlying records so a control owner can understand what each measure includes. Do not use a green summary as a substitute for checking the unresolved items behind it.

Review access when the original reason may have changed

Periodic access reviews give a responsible person an opportunity to assess whether permissions still match the person's work. A review triggered by an assignment change can ask a different question from a broad annual campaign. Define the purpose before deciding which records the reviewer needs.

easyIGA presents the access under review with available context. Last use, granted by and approved by are relevant fields when the connected sources and captured approval history supply them. These fields have different meanings and should remain distinct.

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.

A defence evaluation should include a record with complete history and one with missing evidence. Ask what the reviewer can reasonably conclude in each case. A lack of recorded activity may justify investigation, but it does not automatically prove that a permission is unnecessary. Some roles exist for infrequent, authorised duties.

After a removal decision, follow the operation to its outcome. The control is incomplete if the organisation records a decision to revoke but never checks whether the connected application reflects it. Agree how the review owner receives unresolved cases and how evidence is retained for the required period.

Keep sensitive deployment boundaries explicit

A defence environment can contain systems with different classifications, connectivity and operating rules. A product discussion should establish the intended boundary before discussing integration convenience. An application used for ordinary administration may require a different evaluation from a restricted operational environment.

easyIGA is self-hosted by default. An EU-hosted deployment operated by our team is available on request for organisations without suitable infrastructure. These deployment descriptions are not military accreditation, a classification approval or a promise of compatibility with an isolated network.

If an isolated or specially restricted deployment is required, assess the exact easyIGA release and all dependencies. Authentication, update distribution, logging, backup and remote-support arrangements need explicit review. The fact that midPoint can be configured for particular environments does not by itself verify the complete easyIGA deployment in those environments.

Use your own security authority's process to decide which data can enter the system. Determine whether an attribute is needed for an access decision and who is permitted to see it. The business interface should reveal enough to support the decision without assuming that every personnel detail belongs in every approval.

Operational stability also needs evidence from the proposed configuration. Agree recovery tests, monitoring responsibilities and change procedures. Set the required throughput, availability and recovery objectives for the intended deployment. Test the proposed configuration against those requirements and record the responsibilities in the operating agreement.

Understand what remains with midPoint specialists

midPoint is the open source foundation for identity data, policies and changes in connected systems. Its documentation and configuration model give technical teams a way to inspect how midPoint works. The midPoint overview explains that foundation.

easyIGA adds the business-facing experience around requests, decisions and review evidence. Managers can participate without using midPoint’s administration console. This is a practical division of responsibilities, not a claim that specialist work disappears.

Your implementation team still needs to connect authoritative sources, define the role model and validate target operations. A connector's presence in a catalogue does not prove support for every permission in a specific application version. Select the operations you need and test them against representative accounts.

Compare midPoint alone with midPoint plus easyIGA using the same workflow. Let a business participant carry out the relevant task in the proposed setup. Then ask the technical team to explain the configuration and the exception path. This makes the value of the additional product layer concrete without implying that the underlying platform lacks governance capabilities.

Evolveum describes midPoint's defence use cases on its industry page. These are references for the underlying midPoint platform. For your easyIGA evaluation, use the application roles, user tasks and deployment requirements that your own team needs to validate.

Plan cost around a defined scope

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. Implementing and operating an identity service still involves work. easyIGA is a commercial product with a published annual subscription model per governed identity and deployment included within an agreed scope. Obtain the current written terms for the proposed capability set.

A defence evaluation should define its populations carefully. Employees, contractors and service accounts can have different lifecycles, even when they are included in the commercial count. State which environments and systems are part of the initial scope and which require later work.

Include the operating requirements in the comparison. An isolated environment may create different update and support procedures from an ordinary connected installation. Do not assume those procedures are included in a generic software price. Confirm who is responsible for the infrastructure and for the evidence needed at acceptance.

Build the cost comparison around the work your team currently performs. Record the current effort involved in preparing a request, finding its approver and resolving a failed change. A pilot can then measure the equivalent process after configuration. Released staff time is capacity, not automatically a reduction in cash expenditure.

The pricing page and midPoint comparison give a starting point for this discussion. The useful commercial question is whether the demonstrated workflow and agreed delivery scope justify the total cost for your organisation.

Bring a reviewable defence workflow to the walkthrough

Choose a non-sensitive administrative example for the first discussion. Identify the access being requested, the role of the approver and the target-system outcome you want to inspect. Use synthetic identities until your organisation has approved any exchange of real information.

Include a change of assignment and a contractor case in the proposed test set. Add a known policy conflict and an operation that cannot be immediately confirmed. These examples expose the decisions and handovers that an ordinary successful request can conceal.

Agree acceptance in observable terms. The requester understands the access description. The authorised reviewer receives the right decision. The configured policy result is visible. The recorded outcome distinguishes completion from work still requiring attention. Evidence gaps are explicit.

Also record what the evaluation has not demonstrated. A workforce application test does not establish compatibility with every operational system. A readable screen does not establish every user's training needs. A successful operation does not establish a service availability commitment. These are separate questions with separate evidence.

Request a 30-minute product walkthrough to examine the current release with our team. The aim is to leave with a clear view of the workflow, the technical responsibilities and the next piece of evidence needed for your own decision.