Yes. Service accounts and connected applications should be certified as non-human identities with explicit ownership, business purpose and renewal criteria. If the programme reviews only employees, the highest-risk access paths can remain invisible. Governance should require that machine access is owned, justified and removed when no longer needed.
Why service accounts should not be certified like employee accounts
access certification is meant to answer two different questions: who has access, and why that access still exists. For service accounts, the right review lens is not employment status, but whether the non-human identity still has a current business purpose, an accountable owner, and a bounded set of systems it is allowed to reach. Treating machine access as if it were just another user list misses that distinction.
That is why Access Reviews and Certification Guide emphasises including NHIs and closing the loop on removal, while IAM and IGA Basics frames certification as entitlement governance, not headcount management. A service account can be valid long after the person who created it has moved teams, so the review has to test ownership, scope and renewal criteria rather than title or manager.
In practice, employee certifications often focus on role alignment and separation of duties. Service account certifications need additional checkpoints: what system or process uses the account, whether the credential is still active, whether the account is shared, and whether the access can be replaced by a better control such as workload identity or managed credentials. If those details are not reviewed, the certification can be formally complete but operationally useless.
What a proper service-account certification must prove
A useful certification campaign should establish that every service account has a named owner, a documented purpose, a known downstream dependency, and a renewal rule. The point is to prove that the account is still needed for a live service, not merely that it exists in an inventory. That is especially important when service accounts are tied to integrations, batch jobs, cloud workloads, or databases that may keep running silently after the original project is forgotten.
Service Account Security Guide and NHI Ownership and Accountability Guide both reinforce the same governance idea: access is only reviewable when ownership is explicit. Certification should therefore ask whether the owner can justify the access, whether a backup owner exists, and whether the account will be rotated, re-scoped, or removed at the next renewal point.
This also changes how evidence is judged. For employee access, a reviewer may accept HR and manager context. For service accounts, the reviewer needs operational evidence: the application, the system dependency, the credential location, the authentication method, and the expected expiry or review interval. Without that evidence, the review becomes a rubber stamp.
How to run certification so machine access does not disappear
The best approach is to separate human and non-human review queues, then apply different questions to each. Employee access can still be reviewed by role, job function and manager approval. Service accounts should be grouped by application, environment and owner, then certified against business purpose, privilege level and renewal date. That makes it easier to spot orphaned accounts, stale integrations and excessive standing access that no employee reviewer would notice.
Top 10 NHI Issues highlights the broader failure patterns that certification should catch, including visibility gaps, overprivilege and unmanaged credentials. When a service account review finds no current owner, no documented dependency, or no removal path, the right response is not to keep certifying it by default. It is to pause, confirm whether the application is still in use, and then re-certify only if the access can be justified and bounded.
Guide to NHI Rotation Challenges is also relevant because renewal without rotation discipline often fails in real environments. If a certification process approves a service account that still uses a long-lived secret, the organisation should treat the review as incomplete until there is a clear plan for credential lifecycle control, not just a sign-off in the ticketing system.
Risk and Threat Considerations
Service accounts often hold privileged, persistent access that is invisible to employee-focused review cycles. If they are certified only through the same workflow as user accounts, organisations can preserve dormant access paths, unowned credentials and excessive permissions long after the original business need has changed.
Failure mechanism: The review validates employment records rather than actual machine usage, so stale integrations, shared credentials and forgotten application accounts keep their access until something breaks or is abused.
Impact: Attackers and insiders can use overlooked service accounts for lateral movement, data access, or persistence, while defenders lose the chance to revoke access before the next credential compromise or system change.
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 and CIS Controls v8 set 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 | Service accounts need lifecycle review, ownership and removal criteria. |
| IA-5 — Authenticator Management | Service account certification depends on controlling long-lived secrets and credentials. | |
| AC-6 — Least Privilege | Certification should verify service accounts retain only the access needed for their function. | |
| Recommendation — Review service accounts separately and disable accounts that no longer have a documented business purpose. Rotate and retire service-account authenticators on a defined schedule. Limit each service account to the minimum permissions required for its workload. | ||
| CIS Controls v8 | CIS-5 — Account Management | Service-account reviews are an account management control, not just user access hygiene. |
| Recommendation — Inventory, review and remove unused service accounts on a recurring basis. | ||
| ISO/IEC 27001:2022 | A.5.18 — Access rights | Certification is fundamentally a review of whether access rights remain justified. |
| Recommendation — Periodically review and revoke access rights that no longer match business need. | ||
Practitioner Guidance
What to verify: Require a named business and technical owner, a live downstream dependency, and a renewal date for every service account. If a reviewer cannot explain what would fail if the account were removed, the account is not ready for certification.
Decision rule: If the account can authenticate to production systems, treat privilege scope and credential lifecycle as the primary certification criteria. If the account is only tied to a legacy process, certify it only with an explicit removal or replacement plan.
Common mistake: Do not let employee recertification evidence stand in for service-account governance. A current manager is not proof that a machine identity is still required, well-scoped, or safe.
Practitioner takeaway: Certification is effective only when it tests whether the access is still operationally justified, not merely whether the account still exists.
Related resources from NHI Mgmt Group
- How can organisations govern AI agents that use service accounts and tokens?
- Should organisations treat service accounts like human users in access reviews?
- Should organisations treat agentic AI access differently from service account access?
- Should organisations treat OAuth apps differently from service accounts?