[Home](https://easyiga.com/) / [Blog](https://easyiga.com/blog) / What is IGA The essential guide / Identity governance # What is IGA? Access that makes sense. Identity governance and administration, explained in depth. Understand the decisions, the technology and the operating model behind access your organisation can justify. [By the easyIGA team](https://easyiga.com/blog/what-is-iga#iga-author-name)Published 24 August 2026Updated 12 October 202618 min read The answer in a minute IGA helps an organisation establish who has access, decide whether they should, apply changes and prove the result. It connects identity data, business ownership and technical controls throughout the access lifecycle. Use this guide to understand the category, identify gaps and plan a practical first implementation. [Colleagues discussing work around a computer in an office] Illustrative photograph by [Vitaly Gariev / Unsplash](https://unsplash.com/photos/team-collaborating-around-a-computer-in-an-office-UikYLDQj9_I). [Unsplash License](https://unsplash.com/license). Illustrative people, not our staff or a customer deployment. In this guide - [01 · What IGA means](https://easyiga.com/blog/what-is-iga#definition) - [02 · The governance cycle](https://easyiga.com/blog/what-is-iga#governance-cycle) - [03 · IGA, IAM & PAM](https://easyiga.com/blog/what-is-iga#iga-iam-pam) - [04 · Core capabilities](https://easyiga.com/blog/what-is-iga#building-blocks) - [05 · Joiners, movers & leavers](https://easyiga.com/blog/what-is-iga#lifecycle) - [06 · Integration & architecture](https://easyiga.com/blog/what-is-iga#architecture) - [07 · Roles & policy](https://easyiga.com/blog/what-is-iga#roles) - [08 · Access reviews](https://easyiga.com/blog/what-is-iga#reviews) - [09 · Ownership](https://easyiga.com/blog/what-is-iga#ownership) - [10 · Non-human identities](https://easyiga.com/blog/what-is-iga#nonhuman) - [11 · Compliance & evidence](https://easyiga.com/blog/what-is-iga#compliance) - [12 · Implementation plan](https://easyiga.com/blog/what-is-iga#implementation) - [13 · Choosing a solution](https://easyiga.com/blog/what-is-iga#selection) - [14 · Readiness checklist](https://easyiga.com/blog/what-is-iga#readiness) - [15 · Common questions](https://easyiga.com/blog/what-is-iga#questions) - [16 · Where easyIGA fits](https://easyiga.com/blog/what-is-iga#easyiga) - [Sources & author](https://easyiga.com/blog/what-is-iga#sources) 01 / The foundation ## What is identity governance and administration? Identity governance and administration (IGA) is the combination of policies, accountable decisions and operational processes used to manage who has access to an organisation’s systems and data, why they have it, and when that access must change or end. Governance establishes the rules and responsibility. Administration carries out the account and permission changes. Together, they connect business decisions with the access that actually exists. An identity may represent an employee, contractor, partner or a non-human actor such as an application or service account. Access may mean opening a customer record, approving a payment, administering a server or reading a shared folder. IGA brings those identities and permissions into a process that can be understood, operated and checked. The essential questions are practical: who owns this account, what can it do, what business need justifies it, who authorised it, and does that justification still hold? A useful answer includes evidence from the target system. A request marked “approved” does not establish that access was created correctly or removed later. [Microsoft’s identity governance overview](https://learn.microsoft.com/en-us/entra/id-governance/identity-governance-overview) describes identity lifecycle, access lifecycle and privileged access as connected areas. Product boundaries vary between vendors. The operating model in this guide is a vendor-neutral way to assess the complete process, including the work people must own. A useful starting point Choose one important application and one person who recently changed jobs. Can you explain every permission they still hold, identify the accountable owner and show whether obsolete access was removed? The gaps in that answer are a concrete starting scope for IGA. 02 / How it works ## From business need to verified access Identity governance is a continuing cycle. An employment change, a project assignment or a request creates a reason to evaluate access. The organisation makes a decision, applies it, verifies the result and revisits the decision when circumstances change. - 01 ### Establish need Identify the person or service, the resource, the purpose and the required period. - 02 ### Decide Apply policy, resolve conflicts and obtain approval from an accountable owner where required. - 03 ### Apply Create, update or remove accounts and permissions in the relevant systems. - 04 ### Verify Compare the target system with the intended result and resolve failed actions. - 05 ### Reassess Review continued need, act on changes and retain the decision history. An original conceptual diagram of the governance cycle. Each step needs an owner and an observable result; this is not a product screenshot. Not every access grant needs a separate manager click. A documented policy can assign low-risk baseline access automatically when reliable identity attributes meet approved conditions. Sensitive, exceptional or conflicting access may require explicit approval. The design decision is to put meaningful control where the risk warrants it, while making routine access predictable. For each step, define what happens when the normal path fails. Missing managers, ambiguous identity matches, unavailable applications and rejected changes should create visible, owned exceptions. A process that exposes an incomplete action is more useful than a dashboard that treats a sent request as a completed result. 03 / Know the boundaries ## IGA vs IAM, SSO, MFA and PAM These capabilities work together, and vendors may package several in one platform. The clearest comparison is the question each capability answers. Having one capability does not establish that the others are covered. Which identity capability solves which problem? | Capability | Primary question | Practical example | Boundary to check | IAM | How do we manage identities and access overall? | The organisation’s identity architecture, authentication and authorisation services. | IAM is the broad discipline; a specific IAM product may cover only part of it. | IGA | Should this identity have this access, and can we prove the decision was implemented? | Approve a project role, expire it and retain the review and removal evidence. | Requires trustworthy identity data, resource ownership and integration coverage. | SSO / identity provider | How can an identity sign in across applications? | Use a central sign-in session to reach several connected applications. | Sign-in integration alone does not justify every permission within an application. | MFA | What additional authentication factors must be presented? | Require another factor during authentication. | Stronger authentication does not remove an unnecessary business permission. | PAM | How do we control privileged access and privileged credentials or sessions? | Broker administrator access, restrict its duration and record supported activity. | Coverage differs; check the integration with approval, review and termination processes. | Provisioning | How does an account or permission change reach a system? | Create an account or remove group membership through a connector. | Successful execution is one part of governance; the underlying decision also matters. Consider a former finance administrator who now works in procurement. MFA can authenticate them correctly, and SSO can sign them in smoothly. Neither fact explains why they still have payroll administration. IGA should connect the role change with a decision about the old entitlement; the application or access-control system must enforce the resulting change. This is an illustrative control example, not a reported customer incident. IGA also supports a zero-trust architecture by improving the quality of identity, entitlement and policy information. It is not the whole architecture. [NIST SP 800-207](https://csrc.nist.gov/pubs/sp/800/207/final) describes a broader resource-focused model in which network location or ownership alone does not establish trust. Runtime access decisions, device posture and enforcement remain important alongside governance. 04 / The operating essentials ## The capabilities a useful IGA programme needs Start with outcomes and then map them to software. The following capabilities form a practical assessment framework. They are not a claim that every product implements every feature, or that every organisation needs the same implementation depth. ### Identity inventory and correlation Bring accounts from important systems into view and link them to a known person or an accountable non-human owner. Use stable identifiers and explicit matching rules. An email address can change, and two people can share a name. Ambiguous matches require investigation rather than automatic ownership assignment. ### Access catalogue and requests Describe access in language the requester understands. Include the resource, permission level, owner, eligibility and expected duration. “Finance reporting, read only” is more useful to a manager than an unexplained directory group code. Keep the technical mapping underneath the business description so that fulfilment remains precise. ### Policy and approval Decide which access can be assigned by rule, which needs approval and which combinations are prohibited. Give approvers relevant context: purpose, duration, sensitivity and existing access. Define delegates, escalation and what happens when the approver is also the requester. ### Provisioning and reconciliation Provisioning changes accounts and permissions. Reconciliation checks the observed target state against the state the organisation expects. Both matter when administrators can also make changes directly in applications. Evolveum’s [midPoint synchronisation documentation](https://docs.evolveum.com/midpoint/reference/support-4.10/synchronization/) describes mechanisms for detecting and processing resource-side changes; the exact configuration and response must fit each integration. ### Access reviews and evidence Ask accountable reviewers whether access remains appropriate, give them enough context to decide, and complete the changes their decisions require. Store a coherent history that links identity, request, approval, policy, fulfilment, exception and review. Reports should explain both successful actions and outstanding work. 05 / Access follows change ## Joiners, movers and leavers The identity lifecycle begins with a reliable source of organisational facts. HR commonly supplies employee status, start date, manager and department. Contractor records may come from procurement or a sponsor. Decide which source owns each fact and how conflicting updates are resolved before you automate decisions based on it. ### Joiner Prepare appropriate baseline access for the start date. Confirm identity matching, eligibility and the target accounts. Request additional access through the normal policy path. ### Mover Re-evaluate existing rights when responsibilities change. Remove obsolete access as well as granting new access. Give temporary overlap an owner and an expiry. ### Leaver Apply the authorised termination event to all relevant systems. Verify removal, handle residual sessions and transfer ownership of business resources. Moving roles deserves its own design. If every transfer only adds permissions, access accumulates even when each individual grant was reasonable at the time. Define which rights belong to the old job, which belong to an ongoing project and which require a fresh decision. An effective-dated transfer can then trigger the appropriate changes without assuming that all old access is invalid. Offboarding needs target-specific verification. [Microsoft’s access-revocation guidance](https://learn.microsoft.com/en-us/entra/identity/users/users-revoke-access) explains that an application can control a session it issued independently of the identity provider. Disabling a central account therefore does not, on its own, prove that every existing session has ended. Local accounts, API credentials, devices and physical access may require separate actions. Set completion objectives by risk and system class, and measure the elapsed time from the authoritative event to verified completion. Do not invent a universal deadline for every departure. For the detailed operating sequence, use our [employee offboarding guide](https://easyiga.com/blog/employee-offboarding-access). 06 / Under the surface ## How IGA connects to your application estate A typical architecture has four parts: authoritative identity sources, a governance service, integration mechanisms and the systems that enforce access. The governance service brings together identity records, policies and decisions. Connectors or controlled manual tasks carry those decisions to directories, SaaS applications, databases and infrastructure. Document the integration depth for each system. Reading accounts is different from creating them; changing group membership is different from managing fine-grained business roles; disabling an account is different from revoking a session. A catalogue of connector names cannot replace an operation-by-operation test. [SCIM, specified in RFC 7644](https://www.rfc-editor.org/info/rfc7644/), provides an HTTP-based protocol for managing identity resources across domains. It can help standardise integration, but supported resource types and operations still need verification in the actual service. A connector’s existence does not mean the organisation’s full approval, entitlement and revocation requirements are supported. For a system without a suitable API, a governed manual task can be a reasonable interim control. Name the operator, describe the exact action, set a due date and require target evidence. Report that system as manually governed rather than automatically covered. Prioritise automation where volume, sensitivity or delays justify the effort. Test the failure path before go-live Use a representative test identity. Make one target unavailable, submit a valid change and confirm that the process records a failure, assigns an owner, retries safely and verifies the eventual result. The acceptance criterion is a correct final state with understandable evidence. Protect the IGA platform itself. Its connectors may hold administrative permissions. Limit service-account privileges, protect secrets, restrict administrative roles, record changes and test recovery. A governance platform needs the same ownership and review discipline it introduces elsewhere. 07 / Better access decisions ## Roles, attributes, least privilege and separation of duties An entitlement is a specific access right, such as membership in a group or the ability to approve invoices. A role groups related access into something the organisation can assign and maintain. Attribute-based rules use facts such as department, location or employment status to determine eligibility or access. These approaches can be combined. Keep the model understandable. A small, well-owned baseline with explicit exceptions is often a better starting recommendation than a large role hierarchy that nobody can explain. Each role needs a purpose, an owner, a permission inventory and a review process. Attribute rules need reliable source data and tests for changes, missing values and exceptions. Evolveum’s [roles and policies documentation](https://docs.evolveum.com/midpoint/reference/support-4.10/roles-policies/) distinguishes roles that grant access or responsibilities from policies governing how access is granted, reviewed or approved. That distinction is useful when designing ownership: a business role and the conditions attached to it are related decisions, not interchangeable objects. Least privilege means limiting access to what the work requires. Apply it to permission level, resource scope and duration. Read-only access may be sufficient where edit access was previously copied from a colleague. A temporary project may justify an expiry date rather than permanent membership. Separation of duties (SoD) addresses combinations of responsibilities that should not be exercised without suitable control. For example, an organisation may prohibit one person from both creating a supplier and releasing that supplier’s payment. This is an illustrative rule: the actual conflict depends on the process, permissions and risk assessment. Where an exception is necessary, record its justification, approver, compensating control and end date. 08 / Keep access appropriate ## Make access reviews produce real decisions An access review asks whether an identity should keep a permission. The reviewer needs more than a username and a checkbox. Provide the business meaning, source of the grant, owner, sensitivity, justification, dates and relevant usage evidence where available. Missing usage data must remain visibly missing; it must not become a fabricated “last used” value. [Microsoft’s access-review overview](https://learn.microsoft.com/en-us/entra/id-governance/access-reviews-overview) describes recurring evaluation of memberships and application or role access. The general operating lesson is to define both the decision process and what happens afterwards. A revoke decision is incomplete until the corresponding removal has been fulfilled and checked. Choose review scope and frequency according to applicable obligations, sensitivity and change. Separate high-risk administrative access from a low-risk general collaboration group when they need different decisions. Define what happens when a reviewer does not respond, and avoid treating silence as an unexplained approval. Measure unresolved decisions, overdue removals and permissions that reappear after revocation. These reveal whether the process changes access in practice. A campaign with every row reviewed can still leave material risk if failed removals remain open. See how [access reviews in easyIGA](https://easyiga.com/product/access-reviews) bring the person, permission and available evidence together. 09 / People behind the policy ## Who should own identity governance? IGA is shared work with explicit responsibility. IT operates integrations, but it cannot determine every business need. A manager understands a person’s duties; an application owner understands the rights inside a system; security defines control requirements; HR or the contract sponsor supplies lifecycle facts. A starting responsibility map to adapt to your organisation | Owner | Decision or responsibility | Evidence to retain | HR / contract sponsor | Authoritative status, manager and effective dates. | Approved source event and corrections. | Business manager | Confirm duties and need for access. | Justification and approval or rejection. | Application owner | Explain entitlements, approve sensitive access and own integration gaps. | Catalogue definitions and exception decisions. | Security / risk | Define control policy, conflict rules and risk-based priorities. | Policy versions and risk acceptance. | Identity / IT operations | Run workflows, connectors, reconciliation and recovery. | Execution results and resolved failures. | Audit / compliance | Assess design and operation against relevant requirements. | Samples, findings and remediation tracking. For every operational queue, assign a real owner and a delegate. “The business” is not an escalation destination. Define who can approve an exception and who can challenge it. Review the governance administrators’ own privileges through a process that avoids unchecked self-approval. 10 / Beyond employees ## Contractors, service accounts and non-human identities External workers need a sponsor, a purpose and an expected end date. If their sponsor leaves, the access relationship still needs an owner. Include extensions, supplier staff changes and project closure in the lifecycle instead of waiting for a periodic cleanup to discover them. For service accounts, applications and automated agents, record the business owner and technical owner, the workload’s purpose, systems reached, permission scope and retirement conditions. A person leaving should trigger reassignment or review of the non-human identities they own, rather than silently leaving those identities unattended. Credentials and identities are related but different objects. A token or key authorises access for an identity or workload; removing a person’s membership in a password vault does not invalidate a secret they previously retrieved. Connect identity decisions with credential rotation and revocation where necessary. Evaluate non-human coverage explicitly during product selection. Ask whether the system can discover these identities, represent ownership, review permissions and initiate supported changes. Do not assume a workforce governance feature automatically manages every cloud workload or AI agent. Document the boundary and connect specialist tools where required. 11 / Evidence and obligations ## How IGA supports compliance without promising it IGA can help an organisation implement and demonstrate access-related controls. A platform is not a certificate of compliance. Applicability, the adequacy of controls and legal interpretation depend on the organisation and the relevant rules. - NIS2: Article 21(2)(i) includes human-resources security, access-control policies and asset management among the cybersecurity risk-management measures. National implementation and scope must be checked. See the [directive](https://eur-lex.europa.eu/eli/dir/2022/2555/oj) and our [detailed NIS2 guide](https://easyiga.com/blog/what-nis2-actually-requires). - GDPR: Articles 5(2), 24 and 32 address accountability, controller responsibilities and appropriate security measures. Access governance can support those duties; GDPR does not prescribe one named IGA product. Consult the [regulation](https://eur-lex.europa.eu/eli/reg/2016/679/oj) for the full context. - Control frameworks: [NIST SP 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) includes account management, separation of duties and least privilege in its access-control family. Which controls an organisation adopts, and how it implements them, require a defined scope and assessment. For financial-sector requirements, continue with our [DORA and access-control guide](https://easyiga.com/blog/dora-and-access-control). Keep legal requirements separate from recommended implementation patterns and product features. A useful evidence package links the authoritative identity event, access decision, applicable policy, target action, verification and any exception. Retain records under an appropriate schedule with access restrictions. Evidence needs enough context to explain the control without collecting unnecessary personal information. 12 / A practical starting plan ## How to implement IGA in manageable stages The following sequence is a recommended planning approach, not a guaranteed delivery timetable. Scope, integration quality and organisational ownership determine the effort. Give each stage an acceptance criterion so that progress means a demonstrated result. - ### Define one outcome Choose a material problem: unverified offboarding, slow access approvals or a review that cannot produce evidence. Name the accountable sponsor, affected population and target systems. Record the current failure modes before selecting tooling. - ### Establish trustworthy identity data Identify authoritative fields, stable identifiers and exception owners. Test name changes, transfers, rehires, multiple contracts and missing managers. Correct the data needed for the first use case rather than postponing all work until every record is perfect. - ### Map access and responsibility Inventory accounts and permissions in the chosen systems. Assign application owners, describe sensitive entitlements and identify direct administrative paths. Record which operations can be automated and which need controlled manual work. - ### Build and test the complete path Configure a small set of policies, requests, approvals and target actions. Test successful changes, rejection, expiry, unavailable systems and wrong identity matches. Verify the target state and the evidence a reviewer receives. - ### Pilot with real operators Have managers, reviewers and support staff complete representative tasks. Observe confusing catalogue names and approval context. Fix those issues, document recovery and define the handover into normal operations. - ### Expand using measured gaps Add systems and populations according to risk and demonstrated value. Review recurring exceptions, overdue removals and manual effort. Keep ownership, catalogue quality and control testing in the operating budget. The first production scope should be small enough to understand and important enough to matter. It should still exercise the full control path. A connector-only pilot proves connectivity; it does not prove that business approvals, failure handling and evidence work together. 13 / Evaluate with evidence ## How to choose an IGA solution Bring representative scenarios from your estate to the evaluation. Ask the supplier to distinguish generally available features, preview capabilities, configuration work and planned development. A feature label is less informative than an observed result in a supported configuration. Questions to use in a demonstration or proof of concept | Area | Ask to see | Acceptable evidence | Integration | Your required account, entitlement and removal operations. | Supported versions, tested operations and documented gaps. | Business usability | A manager completing an unfamiliar request and review. | Understandable access descriptions and sufficient decision context. | Policy | A conflicting request, temporary exception and expired grant. | Recorded policy outcome, accountable decision and completed follow-up. | Failure handling | An unavailable target and safe recovery. | Visible failure, owned escalation and reconciled final state. | Evidence | Reconstruction of one access decision end to end. | Linked records rather than unrelated screenshots. | Operations | Backup, restore, upgrades and configuration ownership. | Runbooks, responsibilities and a tested recovery approach. | Exit and control | Export of identity data, decisions and configuration. | Documented formats, contractual rights and migration assumptions. Evaluate cost over the operating life of the solution. Include licensing, infrastructure, integration, data remediation, business-role design, training, support, upgrades and the team that owns exceptions. Open-source software can reduce some licensing constraints while still requiring implementation and operational investment. Build a business case from your measurements. Estimate repetitive request volume and handling effort, then separately assess risk and evidence gaps. Avoid turning an unverified reduction in breach probability into a precise savings figure. A credible proposal makes its assumptions visible and gives the buyer a way to test them. 14 / Your next working session ## An IGA readiness checklist Use these questions with HR, IT, security and application owners. Record an owner and next action for every unanswered item. The checklist is a conversation starter, not a maturity score or compliance assessment. - We know which source owns employee and contractor status. - We can link important system accounts to an identity or accountable owner. - Application owners can explain sensitive permissions in business language. - Joiner, mover and leaver events have defined effective times and responsibilities. - We distinguish approved, attempted, completed and verified access changes. - Temporary access and exceptions have expiry dates and follow-up owners. - Reviewers receive enough context to make meaningful decisions. - Revocation decisions are tracked through actual removal. - Non-human identities and shared credentials are included in scope. - We can reproduce the evidence for one complete access lifecycle. If several answers are unclear, resist starting with a very large role model. Select one important population and application, establish ownership and prove the lifecycle. That produces a useful baseline for deciding where software, process changes or better source data will have the greatest effect. 15 / Questions buyers ask ## Frequently asked questions about IGA Do we need IGA if we already use Microsoft Entra ID? Assess your actual configuration and coverage. Microsoft offers identity governance capabilities, but having a directory or SSO does not establish that those capabilities are licensed, configured or connected to all relevant systems. Start with the missing outcomes and compare options against those gaps. Is IGA only for large enterprises? No. The need depends on access complexity, sensitivity, staff changes and evidence requirements. A smaller organisation with many critical applications can face significant governance work. A simple estate may be served by existing tools and disciplined manual processes. Choose a proportionate approach. Can we implement IGA without a perfect role model? Yes. A focused implementation can begin with identity correlation, a small set of well-owned access items and lifecycle controls. Improve role design from observed use and business ownership. Avoid automatically copying historical permissions into a model that gives them new legitimacy. Does IGA replace our HR system or application permissions? No. HR or another authoritative source provides lifecycle facts. Applications continue to enforce their own supported permissions. IGA connects those facts, policies and decisions with the administration and review of access. How long does implementation take? There is no reliable universal duration. Ask for a scoped estimate based on systems, operations, identity-data quality, policy complexity and available owners. Require milestones tied to verified outcomes, with assumptions and dependencies stated in writing. Can AI make access decisions for us? AI assistance may help explain access, highlight anomalies or propose review priorities. Treat recommendations according to their evidence and limitations. Access changes still need a defined authority, policy and audit record. Evaluate the actual product behaviour rather than assuming that an AI label provides governance. 16 / Where easyIGA fits ## A business-facing layer over midPoint easyIGA is positioned as a business-facing governance layer over the open source midPoint platform. Its [product overview](https://easyiga.com/product) organises the experience around Request, Approve, Provision, Review and Prove: helping business users work with access while midPoint handles the underlying identity operations. The [evidence overview](https://easyiga.com/product#evidence-receipt) explains how easyIGA records requests and captured approval stages, identifies grants made elsewhere and marks missing historical information. Decision-time policy-conflict checks are available; rule authoring and simulation inside easyIGA are planned. A pilot connects these capabilities to your own applications, including the handling of failed changes and incomplete records. Our team has delivered 14+ midPoint implementations. That experience informs how we design easyIGA around everyday access tasks. Start with one difficult access scenario from your organisation and follow its decision, outcome and evidence in a live walkthrough. ### Start with the access you cannot explain today. Show us the application, lifecycle event or review that creates the most manual work. We can discuss scope, integration readiness and a practical first outcome. [Discuss your IGA requirements](https://easyiga.com/contact)[Explore the product](https://easyiga.com/product) Reference desk ## Sources and editorial record Product scope and editorial wording updated on 12 October 2026. Original source-check dates are retained below. Primary sources checked on 8 October 2026. Implementation checklists and evaluation criteria are editorial recommendations. Illustrations are explanatory examples, not customer results. - [Identity governance overview](https://learn.microsoft.com/en-us/entra/id-governance/identity-governance-overview), Microsoft Learn; updated 8 May 2026. Verified 12 September 2026. - [SP 800-207: Zero Trust Architecture](https://csrc.nist.gov/pubs/sp/800/207/final), NIST; August 2020. Verified 12 September 2026. - [SP 800-53 Rev. 5: Security and Privacy Controls](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final), NIST; September 2020; current publication record consulted. Verified 12 September 2026. - [midPoint roles and policies](https://docs.evolveum.com/midpoint/reference/support-4.10/roles-policies/), Evolveum; updated 1 August 2025. Verified 12 September 2026. - [midPoint synchronisation](https://docs.evolveum.com/midpoint/reference/support-4.10/synchronization/), Evolveum; living documentation, version 4.10. Verified 12 September 2026. - [RFC 7644: SCIM Protocol](https://www.rfc-editor.org/info/rfc7644/), RFC Editor; September 2015. Verified 12 September 2026. - [Access reviews overview](https://learn.microsoft.com/en-us/entra/id-governance/access-reviews-overview), Microsoft Learn; living documentation. Verified 12 September 2026. - [Revoke user access in an emergency](https://learn.microsoft.com/en-us/entra/identity/users/users-revoke-access), Microsoft Learn; living documentation. Verified 12 September 2026. - [Directive (EU) 2022/2555, Article 21](https://eur-lex.europa.eu/eli/dir/2022/2555/oj), European Union; 14 December 2022. Verified 12 September 2026. - [Regulation (EU) 2016/679, Articles 5, 24 and 32](https://eur-lex.europa.eu/eli/reg/2016/679/oj), European Union; 27 April 2016. Verified 12 September 2026. - [Product scope and integration status](https://easyiga.com/product), easyIGA; current production page. Verified 12 September 2026. - [Company background and experience](https://easyiga.com/about), easyIGA; current production page. Verified 12 September 2026. Photograph: [Vitaly Gariev / Unsplash](https://unsplash.com/photos/team-collaborating-around-a-computer-in-an-office-UikYLDQj9_I), published 26 September 2025; [Unsplash License](https://unsplash.com/license) verified 12 September 2026. The people shown are illustrative and are not identified as our staff or customers. eI About the author ## easyIGA team Our team’s midPoint delivery experience informs easyIGA and the practical guidance on this website. Meet the people behind the product on About us. [About the easyIGA team →](https://easyiga.com/about)