[Home](https://easyiga.com/) / Solutions / Telecommunications easyIGA for Telecommunications # Keep workforce access close to its owner. Give field teams, managers and supplier sponsors a readable access workflow. easyIGA brings the business decision together with midPoint policies and recorded application outcomes. [Request a product walkthrough](https://easyiga.com/demo) Field assignments, supplier access and legacy application integration. [Tall broadcast tower with antennas against clear sky] Illustrative photograph. [Anna Spoljar / Unsplash](https://unsplash.com/photos/tall-broadcast-tower-with-antennas-against-clear-sky-VTrcVHfZ4Zk). On this page [Give workforce access a clear operational owner](https://easyiga.com/industries/telecommunications#give-workforce-access-a-clear-operational-owner)[Start where a field assignment changes application access](https://easyiga.com/industries/telecommunications#start-where-a-field-assignment-changes-application-access)[Make supplier access accountable beyond the contract](https://easyiga.com/industries/telecommunications#make-supplier-access-accountable-beyond-the-contract)[Separate business support systems from network control](https://easyiga.com/industries/telecommunications#separate-business-support-systems-from-network-control)[Put relevant policy results beside the approval](https://easyiga.com/industries/telecommunications#put-relevant-policy-results-beside-the-approval)[Give service teams a truthful view of progress](https://easyiga.com/industries/telecommunications#give-service-teams-a-truthful-view-of-progress)[Review permissions when teams and services evolve](https://easyiga.com/industries/telecommunications#review-permissions-when-teams-and-services-evolve)[Keep technical accounts attached to their purpose](https://easyiga.com/industries/telecommunications#keep-technical-accounts-attached-to-their-purpose)[Use midPoint as the configured identity foundation](https://easyiga.com/industries/telecommunications#use-midpoint-as-the-configured-identity-foundation)[Make security and operating responsibilities reviewable](https://easyiga.com/industries/telecommunications#make-security-and-operating-responsibilities-reviewable)[Keep subscriber identity outside the workforce assumption](https://easyiga.com/industries/telecommunications#keep-subscriber-identity-outside-the-workforce-assumption)[Compare price with the work included](https://easyiga.com/industries/telecommunications#compare-price-with-the-work-included) ## Give workforce access a clear operational owner A telecommunications organisation brings together office staff, field engineers and external service teams. Their work can span business applications and specialist operational systems, each with a different owner. Identity governance connects a person's current responsibility to the access they need and the decision that authorises it. easyIGA gives employees and managers a business-facing way to request, approve and review application access. midPoint provides the underlying identity governance platform and carries out configured changes in connected systems. The division keeps technical configuration with specialists while making the business decision accessible to the people responsible for it. Begin with workforce identity rather than assuming that every subscriber identity belongs in the same programme. A customer authentication platform and an employee's access to an internal application serve different purposes. This page concerns the latter and the related responsibilities around external workers and technical accounts. When an engineer moves between regional teams, the service owner needs to understand which application permissions belong to the new assignment. The operator handling the change needs a reliable identity record and a way to confirm the result. easyIGA connects the business decision to that technical process. The illustrative examples below follow changes in field assignments, supplier responsibilities and application access so each team can see where its work begins and ends. ## Start where a field assignment changes application access Consider a fictional field engineer moving to a different regional team. They may need access to a work-order system for the new area while no longer needing permissions associated with the previous assignment. The organisation needs a reliable source for that change and a defined rule for the affected applications. An HR record can establish the employment relationship without carrying every operational assignment. A workforce scheduling system may hold another part of the picture. The implementation team needs to decide which source owns each fact and how disagreements are resolved before those facts drive permissions. midPoint's configured identity lifecycle and provisioning mechanisms provide the foundation for changes in connected systems. easyIGA adds the business-facing experience for requests and reviews around midPoint. A readable interface does not resolve an ambiguous source-of-truth decision; the organisation must make that decision explicitly. Use the regional move as a pilot case. Identify the old and new access, then demonstrate the configured change. Check permissions that should be removed as well as those added. If an exception permits access to both regions for a period, record its business purpose and the process that will revisit it. The field engineer should be able to understand the request without learning internal directory naming. The operator should be able to identify an incomplete target change. Those two views of the same process reveal whether the proposed solution supports the people who depend on it. A workflow to examine together - 01Field assignment changes - 02Service owner reviews access - 03midPoint updates connected systems - 04Operator checks the result Illustrative process. The configured sources, policies and target systems determine the result. ## Make supplier access accountable beyond the contract Network and service operations can involve external teams with changing assignments. A supplier contract establishes a commercial relationship, but application access needs a responsible internal sponsor and a clear purpose. The access process should preserve that distinction. Create an authoritative record for the person or governed identity. Establish the sponsor and the applications required for the work. A supplier name should not automatically grant the same permissions to every worker associated with that company. easyIGA's request catalogue provides a place to describe the access in business terms. The configured policy determines the approval route. Your specialists map the role to the target permissions and establish what evidence confirms the operation. For the evaluation, include a worker whose contract continues but whose assignment changes. This is a useful test because a simple supplier-active flag may be insufficient to explain the correct access. Ask the sponsor to decide which permissions remain justified and show how the supported workflow records that decision. Also test a sponsor leaving the organisation. The account can remain technically active while the business responsibility becomes unclear. Agree who receives the outstanding review work and how that change is maintained in the identity model. An account needs an accountable decision maker throughout its useful life, not only when it is first created. ## Separate business support systems from network control A telecommunications environment can contain customer-service applications, billing systems and network operations tools. They should not be treated as interchangeable targets merely because each contains accounts. The effect of a permission change can be very different across those systems. Start by identifying the operations the proposed integration will perform. Reading accounts, creating users and changing detailed permissions are separate capabilities. Confirm the interface and target version used for each. An integration that reads users is not evidence that it can safely manage every operational entitlement. For an initial easyIGA evaluation, choose a workflow with a clear application owner and an agreed change process. That could concern an internal work-order application or a defined administrative role. Keep the scope small enough that the owner can explain the intended permissions and review the result. Network control, privileged sessions and secrets management can require additional systems and procedures. This page does not claim that easyIGA replaces those controls or directly governs every network device. The identity architecture should show which responsibilities are handled by each component. Document the boundary in the acceptance record. If a manual operation remains, define the operator and the confirmation expected. If a target cannot return a result immediately, agree how the outstanding work is tracked. The value comes from a process whose meaning is clear, rather than a diagram that suggests universal automation. ## Put relevant policy results beside the approval A manager deciding on access needs to know what the role permits and whether it conflicts with existing responsibilities. Technical policy information is useful when it reaches the person at the moment of the decision in a form they can understand. easyIGA evaluates and displays the result of midPoint's configured exclusion policies at approval time. A conflict known to that configuration can therefore appear before the approver decides. The organisation remains responsible for defining the roles and the combinations it intends to restrict. An illustrative telecommunications policy could separate particular administrative responsibilities within a business process. The relevant rule must be defined by the application and control owners. It should not be inferred from a generic role name or presented as a ready-made policy that every operator requires. During the demonstration, compare an ordinary request with a conflicting one. Ask the approver to describe the issue from the information presented. Then ask the technical team to show the configuration that produced the result. This connects user comprehension to the actual mechanism. Rule authoring and simulation inside easyIGA are planned functionality. Keep them separate from the available policy-result display. Likewise, Microsoft Teams is an approval channel, but the supported workflow and evidence fields in the proposed release need to be demonstrated. The capability being purchased should match the workflow that the team actually tests. ## Give service teams a truthful view of progress An approval is not a confirmation that application access has changed. The destination can be unavailable, reject an operation or provide insufficient evidence of completion. The people waiting on the result need a state that reflects those possibilities. easyIGA distinguishes verified, pending, failed and unknown outcomes. That helps the requester understand why an approved request is still unresolved and gives operators a basis for investigating it. The available detail depends on the target and the configured integration. A telecommunications pilot should test an unavailable destination deliberately. Observe the request state before and after the target becomes reachable. Check which record confirms the eventual result and whether unresolved work remains visible. A recovery path should be demonstrated, not assumed from the existence of a retry mechanism. Define ownership for exceptions across organisational boundaries. A central identity team may see the failed operation while an application team owns the target. Agree how the relevant information reaches the person who can resolve it and who informs the business requester. For management reporting, distinguish the number of decisions made from the number of changes verified. This prevents an apparently complete approval queue from concealing unfinished technical work. The distinction is especially useful when several application teams share one business access process but provide different levels of target confirmation. ## Review permissions when teams and services evolve A new service or an organisational change can alter which permissions a person needs. Access reviews give the responsible manager or application owner a chance to reassess existing access against current work. The review scope should identify the decision being asked of each person. easyIGA presents the access under review with available context. Last use, granted by and approved by depend on connected-system records and captured approval history. These fields help only when their meaning and gaps remain clear. 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. Use an example where an engineer changed responsibility but retained an old permission. Ask the reviewer to explain whether it is still needed. Include a second record whose history is incomplete. The evaluation should show how uncertainty becomes a question to resolve rather than an automatic approval. After a decision to remove access, inspect the target result. A review campaign can record the right business decision and still leave work outstanding in an application. Agree who follows up and which record demonstrates completion. That makes the review part of a maintained access process rather than an isolated periodic exercise. ## Keep technical accounts attached to their purpose Telecommunications services can depend on application and integration accounts that do not represent employees. An account might support a reporting job or an interface between business systems. Its lifecycle should follow that purpose and its responsible team, not an accidental link to the employee who created it. Begin by documenting the dependency. Identify what the account does, which permissions it needs and who can authorise a change. The identity-governance record should help the organisation understand responsibility without exposing credentials or unnecessary sensitive information to business reviewers. A current employee match is not always the right answer to an ownership question. An account used by a service may need a team owner and a different review process. Confirm how the proposed easyIGA release represents the relevant case and what evidence is available from the target. Choose one technical account for the pilot. Ask what happens when its responsible team is reorganised or the application is retired. The test should distinguish changing ownership from disabling the account. The consequences of either action should be understood by the application owner. The [non-human identity and orphaned-account page](https://easyiga.com/product/orphaned-nhi) gives additional context. Treat it as a starting point for a scope discussion, not proof of universal discovery or automatic remediation. Every account type and target operation included in the evaluation needs its own evidence. ## Use midPoint as the configured identity foundation midPoint provides the underlying identity management and governance mechanisms. It is open source, with public documentation for technical teams. easyIGA adds its business-facing request, decision and review experience on top of that foundation. An organisation already operating midPoint can compare the additional experience using an existing application role. Ask the business participant to carry out the same task in the proposed workflow. Ask the specialist to explain which configuration remains unchanged and which integration work is required for the intended easyIGA release. For a new implementation, begin with the identity model rather than an application logo list. Decide which source is authoritative and how roles represent business responsibilities. Confirm the operations exposed by each target before committing to an automation scope. The [connector catalogue](https://docs.evolveum.com/connectors/connectors/) is useful for this research. A listed connector still needs validation against the target version and permission model. Integration fit is a concrete technical question, not a promise that every system can be connected without additional work. Evolveum's [telecommunications page](https://evolveum.com/midpoint-in-telco/) describes sector use cases for midPoint. An easyIGA demonstration can build on that foundation using an internal application and a regional assignment change. Ask the service owner to assess the access being requested and the identity team to inspect the target operation. Their observations help establish whether the proposed workflow fits the handover between central administration and regional operations. ## Make security and operating responsibilities reviewable A workforce identity programme supports the organisation's access-control procedures. It should fit alongside authentication, privileged-access controls and incident response, with the boundary between components clearly understood. No single approval interface establishes the security of the entire service environment. NIS2 includes access control policies among its cybersecurity risk-management requirements. The relevant scope and national implementation need assessment by the organisation. The [official directive](https://eur-lex.europa.eu/eli/dir/2022/2555/oj) is the source for that legal context, not a certification of easyIGA. For deployment, easyIGA is self-hosted by default. An operated EU-hosted option is available on request for organisations without suitable infrastructure. Review the responsibilities for operation and support in the proposed arrangement. A hosting location does not establish a service availability commitment or a complete data-processing agreement. Determine who monitors failed operations, who tests configuration changes and how recovery is demonstrated. A 24-hour business operation still needs explicit coverage and escalation terms; those terms should not be inferred from the industry's operating pattern. The [security information](https://easyiga.com/security) and [deployment page](https://easyiga.com/deployment) provide a starting point. The useful output of due diligence is an agreed responsibility model and the evidence required to accept the service. Keep product capability, organisational procedure and contractual commitment as distinct parts of that record. Compare responsibilities ## What the business decides. What specialists configure. easyIGA supports the business-facing workflow; midPoint remains the configured identity governance platform. Use the same application scope when comparing the options. Responsibilities in the proposed telecommunications workflow | Situation | Business decision with easyIGA | Specialist work with midPoint | Regional team move | Decide which old access should end. | Connect the approved source change to roles. | Supplier reassignment | Confirm the current business sponsor. | Update the governed identity relationship. | Operational application | Explain the requested responsibility. | Validate the exact integration scope. | Technical account | Identify the service and its owner. | Keep the account model distinct from employee access. [Explore easyIGA with midPoint and midPoint alone](https://easyiga.com/compare/midpoint). ## Keep subscriber identity outside the workforce assumption A telecommunications customer and a field engineer can both have digital identities, but their access relationships are different. Subscriber registration, billing and authentication have their own requirements. The workforce IGA scope on this page should not be expanded to those functions without a separate technical and business assessment. Make the distinction explicit in a request for a quote. Identify the employees and external workers whose internal application access is being governed. List technical accounts separately and explain their operational purpose. Do not use the total subscriber population as a substitute for a defined governed-identity scope. Where a workforce application exposes customer information, the application owner should define the relevant staff roles and approval authority. The governance process can then assess those internal permissions. It does not establish the customer's identity or replace the controls around customer authentication and service entitlements. ## Compare price with the work included 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 commercial, with a published annual subscription model per governed identity and deployment included in agreed scope. Confirm current prices and the exact capability set in a written offer. For a telecommunications organisation, identify the populations that will be governed. Employees, external workers and service accounts can create different requirements even when they participate in the same application environment. Make the counting definition and growth treatment explicit. List the application instances and required operations. A group-level connection to a directory can be different from detailed entitlement management in a specialist application. Migration, data cleanup and acceptance testing should be visible in the scope rather than assumed to fit inside a single connector line. Use measured handling work to assess the business case. Record current request volumes, active administration time and the effort needed to resolve exceptions. Compare the same process in a pilot. Released capacity is useful, but it is not automatically a cash saving or a guaranteed reduction in operational headcount. The [pricing page](https://easyiga.com/pricing) and [midPoint comparison](https://easyiga.com/compare/midpoint) support that discussion. Bring one workforce-access workflow to a [30-minute walkthrough](https://easyiga.com/demo), including an ordinary case and an exception. The demonstration can then establish what the proposed product changes for your users and what remains for the technical team to configure and operate. See the product in use ## Bring one access decision. See how the workflow handles it. Explore a team transfer or a contractor’s access to an operational support application. Our team will walk through the request, responsible approver and recorded application result. [Request a walkthrough](https://easyiga.com/demo)[Explore easyIGA features →](https://easyiga.com/product) ## Sources and further reading References checked 6 October 2026. Scenarios and process diagrams are illustrative. Public midPoint references are separate from easyIGA product evidence. - [Evolveum: midPoint in telecommunications](https://evolveum.com/midpoint-in-telco/) - [Evolveum: midPoint overview](https://docs.evolveum.com/book/02-midpoint-overview/) - [Evolveum: connector catalogue](https://docs.evolveum.com/connectors/connectors/) - [European Union: NIS2, Directive (EU) 2022/2555, 14 December 2022](https://eur-lex.europa.eu/eli/dir/2022/2555/oj) Photograph: [Anna Spoljar](https://unsplash.com/photos/tall-broadcast-tower-with-antennas-against-clear-sky-VTrcVHfZ4Zk), used under the [Unsplash Licence](https://unsplash.com/license). Rights checked 6 October 2026.