Yes. Non-human identities can hold persistent access, reach sensitive systems, and outlive the business purpose that created them. If they are excluded from review, organizations leave a major blind spot in governance. Service accounts, API keys, tokens, and certificates should be reviewed with the same ownership and risk logic used for human users.
Why This Matters for Security Teams
Access reviews are not just for employees. Non-human identities can persist long after a project ends, remain embedded in pipelines, and retain reach into production systems, cloud APIs, and vaults. If they are excluded, reviewers miss the credentials most likely to be forgotten, over-permissioned, or reused across environments. NHI Mgmt Group research shows that 97% of NHIs carry excessive privileges, which makes review scope a governance issue as much as a technical one. See the Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10 for the risk patterns that most often show up in reviews.
The practical failure is usually not a missing policy. It is a review process designed around headcount, manager attestations, and job roles, while service accounts, API keys, certificates, and tokens are owned by systems, vendors, or no one at all. That leaves access recertification blind to machine-to-machine trust. In practice, many security teams encounter NHI-related exposure only after an incident reveals that a dormant credential still had access, rather than through intentional review.
How It Works in Practice
A usable access review process starts by inventorying NHIs with the same rigor used for human identities: owner, purpose, system scope, privilege level, last use, expiry, and dependency chain. Current guidance suggests that reviews should not ask whether the identity is “active” in a human sense, but whether it still has a valid business purpose and a current technical owner. That means grouping service accounts, workload identities, OAuth clients, keys, certificates, and tokens into the review population.
Two sources are especially useful here: the NHI Lifecycle Management Guide for lifecycle ownership and the 52 NHI Breaches Analysis for how missed review steps turn into incidents. For control design, the OWASP Non-Human Identity Top 10 is a useful reference point for over-privilege, secret sprawl, and missing ownership.
- Review NHIs by application, pipeline, cloud account, and environment, not only by user directory.
- Require a named technical owner and a business justification for each identity.
- Flag credentials with no expiry, no rotation history, or permissions broader than current task need.
- Revoke or reissue secrets that are no longer tied to an approved workload.
- Pair review outcomes with JIT provisioning and rotation so approvals do not become permanent entitlements.
These controls tend to break down in legacy systems and shared-service environments because identity ownership is fragmented and revocation can interrupt critical automation.
Common Variations and Edge Cases
Tighter review discipline often increases operational overhead, requiring organisations to balance stronger governance against pipeline stability and support burden. That tradeoff is real, especially where a single NHI supports many downstream services or where a vendor-managed integration cannot be easily broken apart.
There is no universal standard for every environment yet, but the best practice is evolving toward risk-based review rather than one-size-fits-all attestation. High-risk NHIs, such as production deployers, database service accounts, CI/CD credentials, and third-party API integrations, should be reviewed more often than low-impact internal automation. Where workloads are highly dynamic, review should focus on whether access is still justified, whether it is scoped to the minimum needed, and whether secrets are short-lived or still effectively standing privileges.
One common exception is ephemeral automation that is issued per task and expires quickly. Even then, the underlying workload identity still needs periodic review, because the absence of long-lived secrets does not remove the need for ownership and trust validation. Another edge case is multi-cloud or partner-connected ecosystems, where NHI evidence may live in different consoles or vaults. In those environments, review quality depends on correlating logs, vault records, and workload metadata rather than relying on directory reports alone. The JetBrains GitHub plugin token exposure is a reminder that exposed machine credentials often become visible only after they have already been abused.
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 Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers review, rotation, and lifecycle control for non-human credentials. |
| NIST CSF 2.0 | PR.AC-1 | Identity governance requires knowing who or what is authorized to access resources. |
| NIST Zero Trust (SP 800-207) | PL-3 | Zero Trust demands continuous verification of workload access and trust assumptions. |
Include NHIs in access reviews and revoke or rotate any credential lacking current business need.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 1, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
