Reviewers cannot distinguish legitimate access from unnecessary access if they only see a name and a checkbox. Without usage, role, ownership, and application context, certification becomes a formality, and risky access survives because the decision-maker has too little evidence to act confidently.
Why This Matters for Security Teams
Access reviews fail when they are treated as a checkbox exercise instead of a decision about operational risk. A reviewer who cannot see usage history, system ownership, or whether an entitlement is still needed has no reliable way to separate legitimate access from stale access. That is especially dangerous for secrets, service accounts, API keys, and other NHI credentials, where the blast radius is often larger than the account name suggests.
NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts, which means most reviewers are already starting from incomplete evidence in the Ultimate Guide to NHIs. In practice, this turns recertification into a formal approval step rather than a control that removes risk. The result is predictable: access survives because no one can confidently prove it should be removed. Current guidance from the OWASP Non-Human Identity Top 10 treats visibility and lifecycle control as prerequisites, not optional enhancements. In practice, many security teams discover excessive access only after an incident forces them to reconstruct ownership and usage from logs.
How It Works in Practice
Reviewer context changes access certification from a name-based approval into an evidence-based decision. At minimum, the reviewer needs to know who owns the identity, what application or pipeline uses it, when it was last used, what privileges it has, and whether there is an approved business reason for retention. Without that context, the reviewer is guessing. With it, the reviewer can identify accounts that are dormant, mis-scoped, overprivileged, or orphaned.
For NHIs, the strongest process is to enrich the review packet before the certification task starts. That usually means pulling together:
- usage telemetry such as last authentication, last API call, or last secret retrieval
- ownership data linking the identity to a team, service, or workload
- entitlement detail showing roles, resource scope, and privilege level
- lifecycle status such as active, deprecated, rotating, or scheduled for retirement
- change context such as recent deployments, incident tickets, or automation updates
This is where lifecycle governance matters. The NHI Lifecycle Management Guide emphasizes that review decisions should be connected to creation, rotation, and offboarding, not treated as isolated annual events. Pair that with evidence from the 52 NHI Breaches Analysis, which shows how often overlooked credentials and weak visibility contribute to compromise. In operating terms, the reviewer should be able to answer one question quickly: if this access is retained, what concrete workload depends on it today?
Where teams have mature controls, this evidence is assembled automatically from IAM, secrets managers, CMDBs, and observability tools, then fed into review workflows as a single decision record. The practical goal is not perfect certainty, but enough context to support removal when the entitlement no longer has a defensible business owner. These controls tend to break down when identity inventories are stale and ownership data is missing because reviewers cannot verify whether the access is still tied to an active workload.
Common Variations and Edge Cases
Tighter review criteria often increases operational overhead, requiring organisations to balance reduced risk against slower certification cycles and more exceptions. That tradeoff is real, especially in environments with many ephemeral workloads, shared service identities, or fast-moving CI/CD pipelines. Best practice is evolving, but current guidance suggests that the answer is not more manual review effort. It is better context, better automation, and narrower reviewer scope.
There are several edge cases where context is hard to supply. Shared service accounts may support multiple applications, making a single owner insufficient. Legacy systems may not emit usable usage telemetry, which leaves reviewers with partial evidence. High-churn engineering environments can create access that is valid for days, not quarters, so annual reviews arrive too late to matter. In those cases, access review should be supplemented with short-lived credentials, stronger lifecycle controls, and automated expiry rather than relying on human judgment alone. The OWASP model for NHI governance and the NHIMG research above both point to the same operational truth: when reviewer context is thin, recertification becomes a paperwork control, not a security control.
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 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while 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 | Reviewer context is impossible without clear NHI ownership and inventory. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Access reviews should catch stale or unrotated credentials tied to old usage. |
| NIST CSF 2.0 | PR.AC-4 | Context-rich reviews support least privilege and entitlement validation. |
Use review evidence to remove dormant credentials and trigger rotation or revocation.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
