IGA Buyer's Guide: Choosing Identity Governance

Identity governance and administration (IGA) platforms decide who has access to what, why and for how long, so a poor choice shows up as orphaned accounts, rubber-stamped reviews and failed audits for years. IGA covers lifecycle automation, access requests, access reviews, roles and segregation of duties (SoD), all of which depend on connectors to the applications that hold the access. Options range from long-established suites with deep customisation to cloud-native products and governance features built into identity providers. This vendor-neutral guide is for identity, security, audit and IT teams writing requirements, running an RFP or replacing a platform, and ends with a proof of concept you can run on your own applications.

Key takeaways

Integration is the real cost. Connecting HR and your hardest applications is harder than the platform itself, so test those connectors before you sign.
Judge depth, not ticks. Lifecycle automation, access requests, reviews with context, role management and SoD all appear on every datasheet; assess how well each works on your data.
Close the loop. A review decision or a leaver event only counts when the access is actually removed in the target system and the removal is evidenced.
Govern non-human identities and AI agents. Service accounts, OAuth apps, API keys and agents need owners, reviews and offboarding, and many IGA tools were not designed for them.
Weigh time to value against flexibility. Heavy customisation is expensive to build and upgrade, so score operating effort alongside features.

Define requirements

Populations: employees, contractors, partners and other non-employees, service accounts, OAuth apps and AI agents. Record how many of each and who is accountable for them today.
Authoritative sources: HR for employees, a non-employee or vendor management system for contractors, and a source of truth for workload and agent identities. Note data quality problems now. See the Identity Data Quality Guide.
Applications: how many, which support SCIM, directories or major SaaS APIs, and which are custom, on-premises or disconnected (no API at all). RFC 7644 defines standard SCIM endpoints such as /Users, /Groups and /Bulk, but filtering and bulk operations are optional for service providers, so "supports SCIM" still needs testing. See the SCIM Provisioning Guide.
Compliance drivers: SOX Section 404 requires management to assess internal control over financial reporting, which in practice draws in access to financial systems; PCI DSS v4.0.1 requirement 7.2.4 calls for user accounts and access privileges, including third-party accounts, to be reviewed at least once every six months; the HIPAA Security Rule (45 CFR 164.312) requires access to electronic protected health information to be limited to persons or software programs granted access rights; and DORA Article 9(4)(c) requires financial entities to limit logical access to what legitimate, approved functions require. See the Identity Security Regulatory Map.
Current maturity and pain points: slow onboarding, access that survives role changes, failed audit findings, orphaned accounts and review fatigue. See the Identity Governance Maturity Model.

Map requirements to the frameworks you report against

Mapping each requirement to a control gives auditors a trail and makes the business case.

Requirement	NIST CSF 2.0	NIST SP 800-53 Rev. 5	ISO/IEC 27001:2022 Annex A	CIS Controls v8.1	OWASP NHI Top 10 (2025)
Identity and account lifecycle (joiners, movers, leavers)	PR.AA-01	AC-2, AC-2(1), AC-2(3), PS-4, PS-5, IA-4	5.16 Identity management	5.1, 5.3, 6.1, 6.2	NHI1 Improper Offboarding
Access requests and least privilege	PR.AA-05	AC-2, AC-6	5.15 Access control, 5.18 Access rights	6.1, 6.8	NHI5 Overprivileged NHI
Access reviews and certification	PR.AA-05	AC-2, AC-6(7)	5.18 Access rights	5.1, 5.5, 6.8	NHI1, NHI5
Segregation of duties	PR.AA-05	AC-5	5.3 Segregation of duties	6.8	NHI10 Human Use of NHI
Audit trail and monitoring	DE.CM-03	AC-2(4), AC-2(12), AU-6	8.15 Logging, 8.16 Monitoring activities	8.11	NHI10
Service account and agent ownership	PR.AA-01	AC-2, IA-4	5.16 Identity management	5.5	NHI1, NHI7 Long-Lived Secrets, NHI9 NHI Reuse

CSF 2.0 PR.AA-05 says access permissions, entitlements and authorisations are defined in a policy, managed, enforced and reviewed, and incorporate least privilege and separation of duties. PR.AA-01 covers identities and credentials for services and hardware as well as users, which brings non-human identities into scope.

Capability areas

Every vendor will claim all of these; look for them in a demonstration on your data, not on a prepared tenant.

Area	What to look for
Lifecycle (JML)	HR-driven joiners, movers and leavers; birthright rules; rehires; mover access removal, not only addition; leaver disablement everywhere. CIS Safeguard 6.2 calls for disabling accounts immediately on termination, rights revocation or role change, and notes that disabling rather than deleting may be needed to preserve audit trails. See the Joiner-Mover-Leaver Guide
Access requests	A catalogue written in business language; approval routing by owner and risk; time-bound access that expires on its own; policy and SoD checks before approval
Access reviews	Context for reviewers (last use, peer comparison, risk); event-triggered micro-certifications; rubber-stamp detection; closed-loop revocation with confirmation from the target system. See the Access Reviews Guide
Roles	Role mining from real entitlements, role modelling, owners for each role, and a lifecycle that retires stale roles. See the Role Mining and Role Design Guide
SoD	Cross-application rulesets at entitlement level; preventive checks at request time and detective checks on existing access; tracked mitigating controls with expiry. See the Segregation of Duties Guide
Connectors and provisioning	Breadth and depth of connectors (read and write, groups and fine-grained entitlements); SCIM; a managed workflow for disconnected applications; reconciliation that detects access granted outside the platform
Non-human identities and AI agents	Inventory of service accounts, OAuth apps, API keys and agents with a named owner, purpose and review date; reviews and offboarding for NHIs; integration with NHI security and secrets platforms. See the Service Account Security Guide
Analytics and AI	Outlier detection, access recommendations and natural-language requests, each with an explanation a reviewer and an auditor can follow
Reporting and audit	Evidence packs for auditors; a history of who requested, approved, reviewed and removed what, and why; exports to GRC tools

Non-human identities deserve a closer look because they rarely have an HR record to drive their lifecycle. CIS Safeguard 5.5 expects a service account inventory with department owner, review date and purpose, reviewed at least quarterly. The OWASP Non-Human Identities Top 10 (2025) ranks improper offboarding first and lists human use of NHIs, where activity cannot be told apart from automation, as a separate risk. AI agents act through tokens and service identities, so they need an accountable human sponsor, scoped entitlements and a defined end of life. See the NHI Ownership Guide and the AI Agent Identity Security Buyer's Guide.

Evaluation criteria

Score each shortlisted platform from 0 to 5 per criterion in your own environment, multiply by the weight and add up. The weights below are suggested defaults; move weight to SoD in a heavily regulated finance function, or to NHI governance where service accounts outnumber people.

Criterion	Weight (suggested default)	What good looks like
Connector coverage and depth	20%	Working connectors today for HR and your hardest applications, at entitlement level, with write-back; a managed process for disconnected applications
Lifecycle automation	15%	Joiner, mover and leaver events driven from authoritative sources; mover removal; leaver disablement within your target time
Access reviews	15%	Usage and peer context, risk-based scoping, event-triggered reviews, closed-loop revocation verified in the target system
Requests, roles and SoD	15%	Business-friendly catalogue, time-bound access, role mining on your data, cross-application SoD checked before provisioning
Non-human identity and AI agent governance	10%	NHIs and agents in the same inventory with owners, purpose and review dates; ownership transfer when the owner leaves; integration with NHI and secrets tools
Audit evidence and reporting	10%	Complete, exportable history of requests, approvals, reviews and removals; reports an auditor accepts without manual reworking
Security of the platform	5%	Strong admin authentication, granular admin roles, approval for high-impact changes, and least-privilege connector credentials that are stored, rotated and audited
Operations, upgrades and cost	10%	Configuration over custom code; upgrades that do not break customisations; realistic implementation effort; predictable licensing

The IGA platform holds write credentials for many of your most sensitive applications, so treat its connector accounts as non-human identities in their own right. NIST SP 800-53 AC-2(4) asks for automatic auditing of account creation, modification, enabling, disabling and removal, and AC-2(12) for monitoring of atypical account usage; both should apply to actions the platform itself performs.

In the Cloudflare Thanksgiving Breach 2023, one service token and three service accounts were not rotated after the Okta support system breach because Cloudflare mistakenly believed they were unused, and that was how the attacker got in. Real last-use data in front of owners and reviewers closes that gap.

Questions to ask vendors

How would you integrate our three hardest applications, what would it take, and how long would it take?
What happens to previously requested access when someone changes role, and how is removal confirmed in the target system?
How do you handle disconnected applications: who is tasked, how is completion evidenced and how is it reconciled later?
Show a review campaign with usage data and peer comparison, and how revocations are executed and verified.
How are SoD rules defined across applications, and is the check preventive at request time as well as detective?
How do you govern service accounts, OAuth apps, API keys and AI agents, including ownership, reviews and offboarding?
When an NHI owner leaves, how is ownership transferred, and what happens if nobody accepts it?
How are your connector credentials scoped, stored, rotated and monitored?
What customisations will we need, how do upgrades affect them, and can we speak to references of our size?

Red flags

Connector claims that turn out to be "build it yourself" frameworks: generic adapters counted as connectors.
Reviews that show only entitlement names without context: reviewers cannot judge cryptic group names.
Revocation that ends at a ticket: the review is marked complete when a task is raised, not when access is removed.
No path for disconnected applications other than manual spreadsheets: the riskiest access stays outside governance. The Colonial Pipeline Ransomware Attack 2021 began with a VPN account that, according to Mandiant, was no longer in use but had not been disabled.
NHI support limited to importing accounts: no ownership, review dates, lifecycle or offboarding for service accounts and agents.
AI features that cannot explain their output: recommendations nobody can justify to an auditor.
Estimates that depend heavily on professional services, or roadmap items offered in place of day-one capabilities.

Proof of concept

Run the proof of concept on your own HR data, applications and reviewers. The targets in brackets are suggested defaults; set your own before the test starts and score every vendor against the same ones.

Connect HR and three to five applications, including at least one difficult one. Success: entitlements imported at reviewable level, with write-back (suggested target: all chosen applications connected within the agreed PoC window, without custom code).
Run joiner, mover and leaver scenarios end to end. Success: birthright access granted on start, old access removed on move, and all accounts disabled on leave (suggested target: leaver disablement in connected applications within one hour of the HR event; disconnected applications tasked and evidenced).
Request time-bound access through the catalogue. Success: correct approver routing and automatic removal at expiry, confirmed in the target system.
Test an SoD rule that should block a conflicting request. Success: the request is stopped or routed for a recorded exception before provisioning, and an existing conflict is detected.
Run a small review campaign with real reviewers. Success: reviewers see usage and peer context; measure revocation rate, completion time and the time from "revoke" to confirmed removal (suggested target: confirmed removal within one working day).
Import service accounts, OAuth apps and at least one AI agent identity. Success: each has an owner, purpose and review date; a review and an ownership transfer on owner departure both work.
Produce the audit evidence. Success: an auditor, or your internal audit team, can trace one access grant from request to approval, review and removal without help from the vendor.

Track the same measures after go-live. See the Identity Security Metrics Guide.

Success criterion	What it shows	Target direction
Time from HR leaver event to disablement	Lifecycle automation works end to end	Down
Review revocation rate and time to confirmed removal	Reviews change access rather than rubber-stamp it	Revocations confirmed faster
SoD conflicts blocked before provisioning	Preventive controls work	Up
NHIs and agents with a named owner	Non-human identity governance is real	Up

Standards and references

How NHI Mgmt Group can help

We provide independent requirements, RFP and evaluation support for IGA and NHI governance programmes. Browse IGA, NHI and AI agent security vendors in our NHI and AI products directory, or contact us to discuss your evaluation.

IGA Buyer’s Guide