Access reviews are snapshots, so they can confirm that access exists but not whether it is still justified, actively used, or safe to remove. The hardest cases depend on context that changes between review cycles, such as dormant service accounts, undocumented jobs, or role changes that happen after certification. Investigation fills that gap by answering the questions the review cycle cannot.
Why This Matters for Security Teams
Access reviews are built to certify known entitlements at a point in time, but the hardest identity cases are often the ones that look legitimate on paper and unsafe in practice. That is especially true for service accounts, API keys, automation jobs, and delegated agents whose access changes outside the review window. NHI Mgmt Group’s Ultimate Guide to NHIs highlights that only 5.7% of organisations have full visibility into their service accounts, which means many reviewers are certifying what they cannot fully observe.
The gap is not just completeness, but context. A dormant credential may still pass review because it belongs to a valid system, while a newly overprivileged one may not surface until the next cycle. That is why access review alone rarely catches excessive privilege, stale secrets, or shadow automation. The review says “exists”; investigation asks “why, for whom, and whether it still should.” Current guidance from the OWASP Non-Human Identity Top 10 treats visibility and lifecycle control as foundational, not optional. In practice, many security teams discover the most dangerous NHI cases only after an incident, not through a clean certification cycle.
How It Works in Practice
The practical difference is that access reviews operate on inventory, while investigation operates on evidence. A reviewer can confirm that a service account exists, but investigation checks whether it is used, what system invoked it, what secrets it can reach, and whether the business owner still exists. For NHIs, that often requires correlating IAM records, CI/CD activity, workload telemetry, secret manager logs, and application ownership data. NHI Mgmt Group’s NHI Lifecycle Management Guide is useful here because lifecycle state often determines whether a credential is active, orphaned, or eligible for revocation.
Security teams usually need a layered workflow:
- Run the access review to confirm the entitlement exists.
- Investigate high-risk or ambiguous cases to confirm current business justification.
- Check last use, secret age, rotation status, and owning application.
- Validate whether the identity is tied to a human owner, a pipeline, or an autonomous workload.
- Revoke or scope down access when evidence does not support continued use.
This is where standards reinforce the operational model. NIST SP 800-53 Rev 5 Security and Privacy Controls supports accountability, least privilege, and periodic review, but the hard cases need investigation because the control cannot infer business context on its own. For NHIs specifically, the 52 NHI Breaches Analysis shows how often compromised or mismanaged machine identities remain reachable long after they should have been retired. These controls tend to break down in fast-moving CI/CD environments because ownership, usage, and privilege can change between certification cycles.
Common Variations and Edge Cases
Tighter investigation often increases operational overhead, requiring organisations to balance faster recertification against deeper validation. That tradeoff is most visible in environments with shared service accounts, ephemeral workloads, or outsourced operations where one entitlement may support many systems and many owners. In those cases, a simple access review can generate false confidence because no single approver has enough context to judge whether access is truly justified.
Best practice is evolving, but current guidance suggests treating certain cases as investigation-first rather than review-only: orphaned accounts, long-lived API keys, privilege spikes after role changes, and automation used by undocumented jobs. The issue is not that access reviews are wrong; it is that some identities do not behave like static human users. They are tied to code, schedules, pipelines, and integrations, so their “ownership” may be technical rather than organisational. That is why groups like NHI Mgmt Group emphasize lifecycle and exposure analysis alongside certification. The Top 10 NHI Issues and the Ultimate Guide to NHIs — Key Challenges and Risks both point to the same operational reality: the hardest identity cases are usually the ones with weak ownership, poor telemetry, or stale secrets. In those conditions, an access review may confirm the paper trail, but only investigation can determine whether the identity should still exist at all.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Identity visibility gaps cause access reviews to miss risky machine identities. |
| OWASP Agentic AI Top 10 | A-03 | Autonomous agents need runtime checks, not static approval snapshots. |
| CSA MAESTRO | GOV-02 | Agent governance requires lifecycle and accountability beyond periodic reviews. |
| NIST AI RMF | GOVERN | AI risk governance needs continuous accountability for changing identity behavior. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege review is relevant, but evidence must supplement certification. |
Document responsibility, monitoring, and escalation paths for non-static AI-driven identities.
