Yes. If reviews only cover human users, they miss the delegated access paths that automation relies on. Governance has to include the non-human identities behind the workflow, or privilege creep will remain outside the review scope.
Why access reviews must cover automation as well as people
Access reviews are only effective when they reflect the full path to production access. If a workflow can create, refresh, or reuse access without a human sitting in the approval loop, the review has to examine that delegated mechanism, not just the person who triggered it.
That is why service accounts, workload credentials, and other non-human access paths belong in the same review population as user accounts. In practice, the control question is whether the business function still needs the access, whether the owner is known, and whether the credential or token is still justified for the current job.
When teams separate “user review” from “automation review,” they usually inherit blind spots around shared accounts, dormant workflows, and cross-environment permissions. Those are the cases where access looks tidy on paper but remains active in code, schedulers, CI/CD jobs, or platform integrations.
What reviewers should look for in workflow and service account access
The review should identify what the automation is allowed to do, what depends on it, and whether the access is still aligned to the purpose it was created for. That means validating the owner, the business process, the scope of permissions, the environment boundary, and whether the identity is still actively used.
For service accounts, reviewers should ask whether the account is tied to a named system, whether the permissions are narrowly scoped, and whether the credential has a rotation or expiry model. For automated workflows, reviewers should confirm that the workflow cannot silently expand its own privilege through inherited roles, broad API scopes, or reused secrets.
Where possible, the review evidence should show both the entitlement and the operational dependency. A good review does not only say “approved,” it shows why the workflow still needs access and who would be accountable if that access were removed.
That is especially important when the automation has indirect access to sensitive systems through tokens, federated trust, or orchestration layers. The reviewer needs to see the actual access path, not just the application name attached to it.
Why this matters when access reviews are used as a control
Access reviews are supposed to reduce privilege creep, but privilege creep often accumulates fastest in non-human accounts because they are less visible and easier to exempt. If automation is excluded, the organization may still pass a formal review while leaving high-impact access untouched.
This is why the control should be designed around effective access, not account type. A workflow that can call production APIs, deploy code, read secrets, or impersonate other services creates the same governance problem as a human user with those permissions, even if no one logs in interactively.
For a practical baseline, Access Reviews and Certification Guide covers how to include NHI and service-account populations in certification campaigns, and Service Account Security Guide is a useful companion for the governance checks that make reviews actionable.
Risk and Threat Considerations
Automated workflows and service accounts can hide long-lived access, broad entitlements, and stale ownership, which makes them attractive targets for abuse. If review programs ignore them, organizations lose visibility into some of the most persistent access paths in the environment.
Failure mechanism: A workflow continues to hold permissions after the business need changes, or a service account keeps broad access because no one is responsible for recertifying it. That can let dormant credentials, reused tokens, or overbroad API scopes survive normal review cycles.
Impact: Attackers and insiders can exploit the unreviewed path for unauthorized access, lateral movement, data exposure, or privilege escalation. Even without active abuse, the organization carries hidden blast radius and audit exposure because the review evidence does not reflect the true access surface.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Access reviews and recertification are part of account governance for users and service accounts. |
| IA-5 — Authenticator Management | Automated workflows rely on credentials, tokens, and keys that require lifecycle control. | |
| AC-6 — Least Privilege | Workflow and service-account permissions should be limited to the minimum needed for their task. | |
| Recommendation — Review account necessity, scope, and ownership on a recurring basis. Track and rotate authenticators used by automated identities. Reduce each automated identity to the minimum permissions needed. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access reviews are a core access-control governance activity for all identity types. |
| A.8.2 — Privileged access rights | Service accounts often carry elevated rights that must be reviewed and justified. | |
| Recommendation — Define and operate access reviews that cover non-human access paths. Recertify privileged non-human access and remove unnecessary elevation. | ||
Practitioner Guidance
What to prioritise: Put every identity that can reach production systems into the same certification population, including service accounts, workload identities, and scheduled automation. If a control owner cannot explain why a workflow still needs its access, treat that as a review failure, not an administrative gap.
What to verify: Confirm the business owner, technical owner, effective permissions, and credential lifecycle for each automated identity. Reviews are strongest when they verify actual use, not just the existence of an account record.
Common mistake: Treating automation as “system access” outside the access review process. That shortcut usually creates unreviewed privilege that persists longer than human access and is harder to detect after the fact.
Practitioner takeaway: If an identity can act on behalf of the business, it must be certifiable on the same basis as a person, otherwise the review is incomplete by design.
Related resources from NHI Mgmt Group
- What breaks when access reviews do not include cloud service accounts and projects?
- What breaks when healthcare access reviews do not include privileged users and service accounts?
- How should security teams run access reviews for non-human identities?
- When do NHI access reviews create more value than a one-time cleanup?