How should organisations evaluate IGA software for access governance?

Why This Matters for Security Teams

IGA software is often evaluated as a workflow tool, but access governance only works when the platform can reliably see entitlements, map them to real identities, and enforce review and removal actions where the data actually lives. That matters because orphaned accounts, stale entitlements, and inconsistent certifications are exactly the conditions that turn access governance into a compliance exercise instead of a risk-reduction control. Current guidance suggests treating governance as a control coverage problem, not a user experience problem, which aligns with the NIST Cybersecurity Framework 2.0 emphasis on measurable outcomes.

For non-human and privileged access, the stakes are even higher. NHIMG’s The 2024 ESG Report: Managing Non-Human Identities found that 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, which reinforces why governance tooling must prove it can handle fast-changing access estates. In practice, many security teams discover the gaps only after an audit failure, a recertification backlog, or a privilege escalation incident has already exposed them.

How It Works in Practice

A useful evaluation starts by testing whether the IGA platform can discover access from authoritative sources, not just import a directory snapshot. That means validating support for HR systems, cloud directories, SaaS applications, and on-premise platforms that actually hold entitlements. It also means checking whether the product can distinguish identities, accounts, roles, groups, and effective access, because governance breaks when these are collapsed into one generic record. The OWASP Non-Human Identity Top 10 is a useful lens here because access governance often fails first where machine accounts, service credentials, and automation identities are least visible.

From there, evaluate how the platform handles lifecycle controls:

• Can it provision, modify, and revoke access automatically from source-of-truth events?
• Can it enforce approval routing based on role, business unit, or risk tier?
• Can it run certifications with context, such as last use, ownership, and entitlement criticality?
• Can it produce audit evidence showing who approved, when access changed, and whether removal completed?

That evidence matters because access governance is only defensible when it is source-backed and time-bound. NHIMG’s Lifecycle Processes for Managing NHIs highlights that identity hygiene depends on continuous lifecycle control, not periodic cleanup. A strong IGA platform should also support policy-based exceptions, delegated ownership, and attestation workflows that separate business validation from technical enforcement. These controls tend to break down when the organisation has many custom applications, weak data ownership, or identity records that are not consistently reconciled across systems.

Common Variations and Edge Cases

Tighter access governance often increases operational overhead, so organisations need to balance automation against the cost of false positives, delayed approvals, and noisy certification campaigns. There is no universal standard for this yet, but best practice is evolving toward risk-based reviews, especially for privileged, service, and third-party access. Where the business has highly dynamic access, static quarterly recertification may create more fatigue than assurance.

Edge cases matter most in hybrid and federated environments. If the IGA platform cannot reconcile access across acquired businesses, shadow SaaS, or externally managed systems, governance reports may look complete while material risk remains hidden. The same problem appears when non-human identities are represented as generic users, because review campaigns then miss credential lifetime, ownership, and usage patterns. NHIMG’s 52 NHI Breaches Analysis is a reminder that poor visibility and weak lifecycle control are recurring failure modes, not one-off exceptions. For organisations comparing products, the real test is whether the platform can prove access decisions at the system level, not just generate attractive dashboards.

Related resources from NHI Mgmt Group

• How should organisations connect data security posture management with access governance?
• How can organisations make data access governance more effective?
• What is the difference between role-based access and API key governance for NHI security?
• Should organisations prioritise external exposure or internal credential governance first?