What should organisations test first when evaluating an IGA platform?

Start with identity and access data quality before certifications or approvals. Verify that identities are matched correctly, duplicate accounts are visible, and unmatched accounts are identified. Then confirm the platform can associate users with applications, roles, and entitlements using your real attributes. If the underlying identity picture is incomplete, every downstream governance decision will be weaker.

What to Test First in an IGA Platform

The first test should be the quality of the identity and access data the platform can actually govern. If matching is weak, every approval, certification and entitlement review is built on a partial view. That means testing duplicate detection, unmatched account handling and attribute fidelity before you spend time on workflow polish or dashboard output. The platform has to prove it can reconcile the real identity graph, not just import records.

That matters because identity governance is only as reliable as the data underneath it. A platform that cannot clearly relate a person to all of their accounts, roles and entitlements will miss shadow access, hide duplicates and leave reviewers approving or revoking the wrong thing. NHIMG’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, a useful reminder that incomplete identity visibility is a common operating condition rather than an edge case.

In practice, the best early test is whether the platform can find the identity truth you already know is messy, instead of only showing the records that are easy to map.

How to Validate the Core Identity Picture

Start with a representative slice of your environment and force the platform to reconcile it end to end. Use active identities, disabled identities, shared accounts, contractors, service accounts, orphaned entitlements and applications with inconsistent attribute quality. The goal is to see whether the IGA engine can resolve the same person across sources, surface duplicates, and flag accounts that have no confident owner or no valid match.

Check whether the platform can join identities across HR, directory and application sources using your real attribute patterns, not idealised samples.
Verify that unmatched accounts are visible as a distinct governance problem, not hidden in an exception bucket.
Confirm that duplicate identities are exposed clearly enough to support review, cleanup and ownership assignment.
Test whether users are associated with applications, roles and entitlements in a way reviewers can trust during certification.

This is where certification value is earned or lost. If the platform cannot explain why a user has a role, entitlement or application relationship, then access reviews become clerical exercises rather than governance controls. For identity and access problems, a broad control reference such as NIST SP 800-53 Rev 5 Security and Privacy Controls is most useful when you are mapping the test results to access, audit and account-management requirements, but the first operational question is still whether the identity joins are trustworthy.

These controls tend to break down when the source systems disagree on attribute quality, because the platform can automate the workflow while still leaving the underlying identity model unresolved.

Common Edge Cases That Change the Test

Tighter identity matching often increases cleanup effort, so organisations need to balance fast onboarding against governance accuracy. The right threshold depends on how much residual ambiguity the business will tolerate in certification and access revocation.

One common edge case is population mix. If the IGA platform is tested only on employees, it may look strong while failing on contractors, privileged admins or non-human accounts with different ownership patterns. Another is role design: some platforms can report entitlements well but cannot model nested roles or application-specific attributes with enough fidelity to support meaningful reviews. Also watch for systems where access is granted outside the normal joiner-mover-leaver path, because those often create unmatched or stale records that an IGA tool must still surface.

Where the organisation relies on automation-heavy estates, a secondary reference point such as the OWASP Non-Human Identity Top 10 can help frame why visibility and ownership tests matter, but only if non-human access is actually part of the identity scope being evaluated. If it is, the test should prove that the platform can distinguish human users from machine accounts without collapsing both into vague entitlement records. That distinction becomes critical when access is shared, long-lived or delegated across systems.

Practitioners should assume that any platform can produce a certification screen; the real question is whether it can produce a defensible identity model when the directory data is incomplete, duplicated or out of sync.

Risk and Threat Considerations

The main risk is governance failure caused by false confidence. If identity records are duplicated, incomplete or wrongly matched, the platform can approve access that should be revoked, miss orphaned accounts and leave excessive privileges in place. That creates exposure even when the workflow itself appears to be operating correctly.

Failure mechanism: Weak reconciliation lets stale accounts, aliases and attribute mismatches survive into certifications and access reviews. Reviewers then approve entitlements against the wrong identity, or miss accounts that were never mapped to a clear owner in the first place.

Impact: Access decisions become untrustworthy, orphaned or duplicated accounts remain active, and the organisation loses the governance signal it expected from the IGA platform. In a mature environment, the control failure is not that the tool lacks features, but that it governs a bad identity picture with precision.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	ID.AM — Asset Management	Identity inventory and account visibility underpin trustworthy governance.
Recommendation — Inventory identities, accounts and entitlements before relying on governance workflows.
CIS Controls v8	5 — Account Management	IGA testing centers on account visibility, ownership and lifecycle control.
	6 — Access Control Management	Role and entitlement mapping is the core of IGA review and certification.
Recommendation — Validate that accounts are uniquely tracked, owned and removed when no longer needed. Test whether access can be linked to users, roles and applications with defensible accuracy.
NIST SP 800-63	5 — Identity Proofing and Enrollment	Reliable identity data starts with correctly established identity records.
	6 — Authenticators	Account linkage and lifecycle decisions depend on authentic identity records.
Recommendation — Verify identity proofing inputs so duplicate or mismatched identities do not enter governance. Check that authenticators and account bindings remain consistent across target systems.

Practitioner Guidance

What to prioritise: Validate identity reconciliation before workflow depth, because certifications and approvals do not compensate for poor matching. The first acceptance test is whether the platform can show every active account, identify duplicates and explain unmatched records in a way operations can action.

What to verify: Use real source data from HR, directory and target applications, then check whether the platform produces the same ownership and entitlement picture your administrators expect. If the platform cannot reliably link a user to the right accounts and roles, treat later certification results as provisional rather than authoritative.

Practitioner takeaway: An IGA platform should first prove it can govern identity truth, not merely display governance workflows; if the identity graph is wrong, the rest of the control stack becomes an expensive approximation.