How should security teams govern access reviews when large parts of the environment are outside IGA scope?

Why This Matters for Security Teams

Access reviews lose value when they only cover the systems already inside IGA. The control may look complete on paper while databases, legacy applications, service accounts, and custom integrations remain outside the certification boundary. That creates a false sense of assurance and leaves the highest-risk identities unreviewed. Current guidance from NIST Cybersecurity Framework 2.0 and the Ultimate Guide to NHIs both point to visibility and governance as prerequisites, not afterthoughts.

This matters because exclusion is rarely limited to one edge case. In many enterprises, the ungoverned area contains the identities most likely to persist, be over-privileged, and evade review. NHIMG research shows only 5.7% of organisations have full visibility into their service accounts, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. In practice, many security teams discover those blind spots only after an incident forces a manual inventory, rather than through a deliberate access review design.

How It Works in Practice

Security teams should define scope as a measurable control boundary, then expand it iteratively. Start by inventorying what the IGA platform can certify, what it cannot see, and which systems still carry meaningful access risk. That includes databases, flat-file credentials, custom apps, batch jobs, and service identities. The goal is not to wait for perfect coverage, but to make excluded populations explicit, owned, and risk-ranked.

A practical model usually includes three steps:

• Tag every identity and entitlement by system type, owner, and review method.
• Separate human access, service access, and break-glass access into different review workflows.
• Track governed coverage as a metric, so leadership sees both reviewed and unreviewed access.

For non-human identities, access review should be paired with lifecycle controls such as rotation, revocation, and offboarding. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful here because certification without lifecycle enforcement often leaves stale secrets in place. The same principle aligns with the OWASP Non-Human Identity Top 10, which treats over-privilege and secret hygiene as core risks rather than administrative cleanup.

Where IGA cannot reach, current best practice is to create compensating controls: owner attestations, periodic entitlement exports, log-based verification, and separate review cadences for legacy and technical accounts. Those controls tend to break down when entitlement data is fragmented across custom tooling and undocumented admin access because reviewers cannot prove what was actually in scope.

Common Variations and Edge Cases

Tighter review scope often increases operational overhead, requiring organisations to balance assurance against the cost of inventorying hard-to-reach systems. That tradeoff is real, especially when legacy platforms, vendor-managed tools, or embedded service accounts do not expose clean certification data. Best practice is evolving here, and there is no universal standard for how to treat every excluded system.

One common variation is “partial IGA,” where human access is certified but machine access is left to platform owners. That can be acceptable only if the organisation can prove ownership, rotation, and revocation for those accounts. Another edge case is third-party access through federated or API-based integrations. NHIMG research in The State of Non-Human Identity Security shows 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which means those identities may never enter the standard review queue at all.

For audit purposes, teams should avoid saying “fully reviewed” unless the excluded population is explicitly documented and separately governed. The more accurate claim is “reviewed within current control scope.” That distinction matters because a control that cannot see a system cannot certify its access, and an unanswered ownership gap should be treated as a finding, not a footnote.

Related resources from NHI Mgmt Group

• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• How should security teams govern API keys used for generative AI access?
• How should security teams govern DNS migrations without losing control of delegated access?