Service accounts often carry durable permissions that outlast the people or projects that created them. If they are not included in review scope, organisations lose visibility into hidden authority and delayed offboarding. That is why NHI review discipline belongs in the same governance programme as human access reviews.
Why This Matters for Security Teams
Access reviews are not just a human identity control. service account, API keys, and automation identities often hold durable permissions that outlive the people who created them, which means unused access can remain active long after a project, team, or vendor relationship has changed. That is why review scope must include non-human identities, not just employees. NHI Mgmt Group’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, and the risk is reflected in the OWASP Non-Human Identity Top 10, which treats over-privilege and weak lifecycle governance as core failure modes.
For security teams, the issue is not just stale access. It is hidden authority that bypasses normal joiner-mover-leaver processes, creating blind spots in offboarding, segregation of duties, and incident response. A service account may not “belong” to a person in the same way an employee account does, but it still represents a security boundary and should be reviewed against business need, ownership, and privilege scope. In practice, many security teams encounter misuse only after a breach, not during routine recertification.
How It Works in Practice
A practical access review for service accounts starts with inventory. Teams need to know what exists, who owns it, what system it supports, and whether the account is still tied to an active workload. The NHI Lifecycle Management Guide is useful here because service accounts should be treated as lifecycle-managed assets, not static exceptions. Once inventory exists, the review should test three questions: is the account still needed, does it have the minimum permissions required, and is the credential still appropriate for the current environment?
- Confirm a named human owner and an operational backup owner.
- Review last-used timestamps, authentication patterns, and upstream dependency records.
- Validate permissions against current task requirements, not historical convenience.
- Check whether secrets are stored in approved systems and rotated on schedule.
- Retire or quarantine accounts with no clear business purpose or ownership.
Access review cadence should align to risk. High-impact accounts that touch production, customer data, or CI/CD pipelines deserve more frequent recertification than low-risk internal automations. Current guidance suggests using review evidence from logs, CMDB records, and secret managers instead of relying on manager attestation alone, because managers often do not know which non-human identities exist. The 52 NHI Breaches Analysis shows how quickly hidden service account access becomes material when it is left outside governance. These controls tend to break down in highly automated environments where accounts are dynamically created by pipelines faster than review workflows can track them.
Common Variations and Edge Cases
Tighter review controls often increase operational overhead, so organisations have to balance governance strength against deployment speed and support burden. That tradeoff is real, especially where service accounts are created for ephemeral jobs, integration testing, or vendor-operated workloads. Best practice is evolving, but the direction is clear: review the account’s purpose and trust boundary, not just whether the account is technically “shared.”
Some environments need different treatment:
- CI/CD and orchestration platforms may create short-lived identities that should be validated through automated policy rather than manual recertification.
- Vendor-managed service accounts often require contract-backed ownership and faster revocation triggers than internal accounts.
- Break-glass and disaster recovery accounts may be exempt from normal frequency, but they still need periodic review and documented approval.
This is also where the broader NHI issue becomes visible. When organisations fail to track the full account population, access reviews become symbolic rather than effective. NHI Mgmt Group’s guidance shows that durable secrets and poor offboarding are common, and that is why review programmes must include non-human identities explicitly rather than assuming human access tooling will cover them. For organisations still maturing their model, the safest starting point is to review the highest-privilege service accounts first and then expand coverage systematically.
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-01 | Service accounts need inventory, ownership, and review like other NHIs. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access review is central to controlling service account drift. |
| NIST AI RMF | Governance and accountability apply to non-human identities with persistent authority. |
Map service account permissions to least-privilege checks and revoke unneeded access promptly.
