Reviews miss the places where overprovisioning often hides. Service accounts, project-level roles, and inherited permissions can retain broad access long after the original reason has expired, so a review that only covers human users gives a false sense of control.
Why This Matters for Security Teams
Access reviews that exclude cloud service accounts and project-scoped roles miss the identities that often carry the most operational reach. That gap is dangerous because non-human access is usually granted for automation, deployment, data movement, and platform administration, then inherited across projects and environments long after the original task ends. The result is a review that looks complete on paper while leaving broad access untouched in practice. OWASP’s Non-Human Identity Top 10 highlights how service identities and secrets become durable attack paths when they are not governed as first-class identities.
NHIMG research shows this is not a theoretical issue. The 2024 Non-Human Identity Security Report found that 88.5% of organisations say their non-human IAM practices lag behind or only match their human IAM maturity. In practice, many security teams discover the exposure only after a project cleanup, incident review, or cloud billing investigation reveals dormant service accounts with still-valid permissions.
How It Works in Practice
A useful access review has to treat cloud service accounts, workload identities, and project-level permissions as part of the identity inventory, not as infrastructure exceptions. That means the review scope should include cloud-native principals, inherited IAM bindings, resource-group or project roles, automation accounts, and any secrets or tokens used by those identities. NIST’s Zero Trust Architecture guidance reinforces the idea that access must be continuously evaluated, not assumed safe because it was approved once.
Operationally, teams should reconcile three views at the same time: who owns the service account, what projects or subscriptions it can reach, and which permissions are inherited from parent folders, org units, or group membership. This is where cloud reviews often fail. A project might appear low-risk while its service account can still read storage, modify secrets, or assume a higher-privilege role elsewhere. The 52 NHI Breaches Analysis shows how missed non-human identities repeatedly turn into persistence and privilege escalation paths.
- Include service accounts, managed identities, workload identities, and API credentials in every review cycle.
- Validate effective permissions, not just assigned roles, because inheritance often hides excess access.
- Map each identity to an owning team, a business purpose, and a retirement date.
- Flag any project that has no active owner, no current ticket, or no clear dependency.
Current guidance suggests reviews should also verify whether access is still needed for automation pipelines, backups, monitoring, and cross-project deployments, because those are the places where “temporary” access tends to become permanent. These controls tend to break down in fast-moving multi-cloud environments where project sprawl, nested inheritance, and shared automation accounts make effective access difficult to reconstruct quickly.
Common Variations and Edge Cases
Tighter review scope often increases operational overhead, requiring organisations to balance audit completeness against cloud-team workload. That tradeoff is real, especially where platform teams manage hundreds of short-lived projects or where a single service account supports many deployment paths. Best practice is evolving, but there is no universal standard for this yet: some organisations review by project, others by workload class, and others by permission risk tier.
Edge cases matter. Shared CI/CD accounts may be legitimate but still need task-level scoping and rotation. Break-glass accounts should be excluded from routine access patterns only if they have separate approval, monitoring, and expiry controls. Project-level roles can also look excessive when inheritance is misunderstood; in those cases the fix is not to remove access blindly, but to trace the effective permission chain and remove what is truly unused. NHIMG’s Ultimate Guide to NHIs and NHI Lifecycle Management Guide are useful references for building that full lifecycle view.
The practical rule is simple: if an access review cannot answer who owns the identity, why it exists, and when it should be removed, then the review is incomplete. Cloud service accounts and projects are often where that answer is hardest to prove.
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 | Service accounts need rotation and expiry controls, not permanent access. |
| NIST CSF 2.0 | PR.AC-4 | Access reviews must include effective permissions for cloud identities. |
| NIST Zero Trust (SP 800-207) | RA-3 | Continuous evaluation is needed because project access changes over time. |
Inventory all non-human identities and replace standing secrets with short-lived credentials.
