Why do mature IGA programmes still miss real access risk?

Why This Matters for Security Teams

IGA programmes are designed to certify who should have access, but real access risk often emerges where the identity model is incomplete. That gap matters because modern enterprises now rely on service accounts, API keys, contractors, and shadow workflows that never pass cleanly through periodic certification. NHI Management Group’s Ultimate Guide to NHIs shows that only 5.7% of organisations have full visibility into their service accounts, which helps explain why access reviews can look disciplined while missing material exposure.

The problem is not that certification is useless. The problem is that it validates a snapshot, while risk changes continuously through ticketing exceptions, privilege creep, stale entitlements, and accounts created outside the central joiner-mover-leaver flow. That is why mature IGA can still miss the access paths that matter most. Current guidance from the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 both point toward better asset visibility and continuous control validation, not just scheduled attestations. In practice, many security teams discover the real gap only after an audit sample passes while an attacker is already using an account the catalogue never knew existed.

How It Works in Practice

Mature programmes usually have strong mechanics for governance: role models, periodic recertification, approval workflows, SoD checks, and reporting. Those controls work best when the identity source of truth is complete and access paths flow through the same system. In the real world, however, access is often granted through side channels that bypass the intended lifecycle.

Common failure points include:

• Tickets that approve access, but do not detect whether the entitlement actually landed in the target system.
• Contractors or third parties who keep access after project completion because the source record was never closed.
• Service accounts and secrets created in scripts, CI/CD pipelines, or infrastructure code rather than the IGA platform.
• Stale role mappings where a user still matches a job profile after duties have changed.

This is why mature IGA increasingly needs continuous discovery, reconciliation, and event-driven review instead of relying only on quarterly or annual attestations. The 52 NHI Breaches Analysis is useful here because it reinforces a pattern seen across incidents: identities and credentials that are not continuously observed tend to remain active far longer than governance teams expect. Practical teams are pairing certification with log-based validation, entitlement diffs, privileged access analytics, and tighter integration with PAM and secrets management. That direction aligns with OWASP Non-Human Identity Top 10 guidance on lifecycle and visibility, which treats unknown or unmanaged identities as a primary risk surface. These controls tend to break down in highly federated environments where each business unit owns its own app stack and no single team can reconcile entitlements end to end.

Common Variations and Edge Cases

Tighter access governance often increases operational overhead, requiring organisations to balance assurance against speed and business flexibility. That tradeoff becomes sharper in environments with rapid provisioning, mergers, outsourced operations, or heavy use of machine identities, because the number of access events can outpace manual review capacity.

There is no universal standard for this yet, but current guidance suggests three practical distinctions. First, human access and non-human access should not be governed identically; service accounts and tokens need shorter review cycles, ownership, and expiration controls that match their runtime use. Second, exceptions matter. A one-time emergency grant can become long-lived if the programme only tracks approvals and not expiry or revocation. Third, data quality is not a side issue. If the identity catalogue, HR feed, contractor registry, or asset inventory is stale, recertification will faithfully certify the wrong state.

The strongest programmes move from pure attestations to continuous assurance, then treat recertification as one signal among several. That approach is consistent with NIST CSF 2.0 and the NHI research emphasis on visibility, but it still depends on operational discipline: clean ownership, reliable event feeds, and a defined process for orphaned or out-of-band access. Mature IGA does not fail because the model is too weak. It fails when the model is too narrow to see the access paths that drift outside it.

Related resources from NHI Mgmt Group

• Why do access control models still fail in mature IAM programmes?
• Why do shadow IT apps create identity risk even when users still have valid SSO access?
• Who is accountable when a unified IGA platform still misses stale access?
• When does JIT access create more risk than it reduces?