Reviews based only on granted permissions miss whether access was actually used, whether it was excessive, and whether it still matches the job or workload. That creates false confidence and weak audit evidence. Security teams need activity-aware review data so they can prove that privilege is not just assigned correctly but also kept current.
Why This Matters for Security Teams
Access reviews that look only at granted permissions create a paper trail, not a security signal. A service account, API key, or workload identity can be technically approved yet never used, used far more broadly than intended, or retained long after the job changed. That gap matters because review outcomes often drive audit posture, recertification, and exception handling, so stale entitlements can survive under the appearance of compliance.
NHI Management Group’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, and that visibility problem is exactly what makes permission-only reviews so brittle. The OWASP Non-Human Identity Top 10 also emphasises that NHI risk is about lifecycle, usage, and exposure, not just entitlement assignment. In practice, many security teams discover that access reviews were "successful" only after a dormant credential is abused or an audit asks for evidence of actual use.
How It Works in Practice
Effective review programs need to compare granted access with observed behaviour. That means pulling together entitlement data, authentication logs, token issuance records, API activity, and ownership metadata before reviewers make a decision. A permission that exists in an IAM directory but has no corresponding runtime activity may be candidate for removal, while a permission that is heavily used but not assigned to the current workload owner may indicate privilege creep or a broken operating model.
For NHIs, the review unit should be the workload or agent, not just the account string. Current guidance suggests pairing identity inventory with activity evidence from sources such as cloud audit logs, vault logs, CI/CD traces, and application telemetry. NHI Management Group’s NHI Lifecycle Management Guide is a useful reference point because it frames review as part of lifecycle control, including issuance, rotation, offboarding, and revocation.
- Check whether the permission was used in the review period, not just whether it was approved.
- Identify excess rights by comparing actual calls with the minimum required for the workload.
- Validate that the current owner, purpose, and environment still match the original approval.
- Flag credentials with no recent activity for deeper investigation rather than automatic retention.
- Use reviewer evidence that includes logs, not screenshots of role assignments alone.
Where possible, align review workflows with policy-as-code and activity-aware controls so that recertification reflects runtime reality. These controls tend to break down when telemetry is fragmented across cloud, CI/CD, and third-party services because reviewers cannot reliably prove whether a granted permission was actually exercised.
Common Variations and Edge Cases
Tighter access review controls often increase operational overhead, requiring organisations to balance audit precision against reviewer fatigue and data quality. That tradeoff is especially visible for ephemeral workloads, shared service accounts, and agentic AI systems where a permission may be legitimate for one task and dangerous for the next.
There is no universal standard for what counts as sufficient "usage evidence" in every environment. Some teams treat any authenticated activity as proof of need, while others require task-level correlation to a ticket, deployment, or runbook. Best practice is evolving, but the direction is clear: reviews should ask whether access is still necessary, not merely whether it was once granted. The Ultimate Guide to NHIs — Key Challenges and Risks highlights that excessive privileges and weak visibility remain common failure modes, which makes historical approval records a poor substitute for current evidence.
Another edge case is dormant but business-critical access, such as break-glass accounts or recovery credentials. Those may be intentionally unused for long periods, so the review process should rely on explicit justification, stronger monitoring, and stricter expiry rather than assuming inactivity equals safety. Permission-only reviews usually fail fastest in environments with many machine identities, because ownership changes, automation drift, and incomplete logs make the original approval look valid long after the underlying use case has disappeared.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 | Reviews must include usage and lifecycle evidence, not just granted permissions. |
| NIST CSF 2.0 | PR.AA-01 | Identity proofing and access review both need current, evidence-based validation. |
| NIST AI RMF | AI RMF governance supports ongoing monitoring of system behaviour and access risk. |
Require activity-aware recertification for NHIs and revoke access that is unneeded or unused.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
