How do access reviews need to change for service accounts and workload identities?

Access reviews for non-human identities should verify current business purpose, owner, expiration, and downstream dependencies rather than using the same evidence set as human recertification. Service accounts often outlive the process they were created for, so reviews must look for orphaned credentials and unnecessary privilege, not just stale usernames.

Why This Matters for Security Teams

Access reviews for service accounts and workload identities are not a simple recertification exercise. Human access reviews answer “does this person still need this role?” NHI reviews have to answer “does this identity still exist for a valid workload, with the right owner, scope, and expiry?” That shift matters because machine identities accumulate faster than governance processes can keep up, and review packs built for people miss orphaned credentials, hidden dependencies, and excessive privilege.

NHI Management Group notes that only 5.7% of organisations have full visibility into their service accounts, which makes blind recertification especially risky. Current guidance also aligns with the OWASP Non-Human Identity Top 10 and the broader findings in Ultimate Guide to NHIs, both of which emphasise visibility, ownership, rotation, and lifecycle control. In practice, many security teams encounter runaway privilege only after a pipeline, integration, or container workload has already inherited a long-forgotten identity.

How It Works in Practice

Access reviews need to be rebuilt around the identity’s operational purpose, not the employee-style notion of recertification. For each service account or workload identity, reviewers should confirm four things: a current business or technical owner, an active workload or service that justifies the identity, an expiration or rotation expectation, and any downstream systems that depend on it. If the identity cannot be tied to a running workload, it should be treated as suspect until proven otherwise.

The best evidence set is different from human IAM. Instead of manager approval and job title, review packets should include deployment metadata, CMDB or pipeline references, runtime logs, token issuance records, and secret or certificate expiry data. Where possible, align the identity to workload identity primitives such as SPIFFE IDs and short-lived tokens as described in the SPIFFE workload identity specification. That makes review decisions evidence-based rather than name-based.

• Verify whether the identity is bound to a real workload, pipeline, or service.
• Check whether the owner can name the system, purpose, and renewal process.
• Confirm the secret, token, or certificate has a defined TTL and rotation path.
• Identify downstream dependencies before removal to avoid accidental outages.
• Look for excessive privilege, especially broad read, write, or admin scope.

Reviews also need to inspect whether the identity is still compatible with least privilege and zero standing privilege. If an account has no runtime proof of use, no documented owner, or a credential that never expires, the review should trigger remediation rather than a rubber stamp. These controls tend to break down in legacy environments where service accounts are shared across multiple applications and no one can reliably map identity to workload ownership.

Common Variations and Edge Cases

Tighter review requirements often increase operational overhead, so organisations have to balance assurance against change velocity. That tradeoff is real for CI/CD pipelines, autoscaling platforms, and ephemeral containers, where identities may exist for minutes or hours rather than months.

There is no universal standard for every environment yet, but current guidance suggests a few practical patterns. Short-lived workload identities should be reviewed by policy and telemetry rather than by one-off human approval. Long-lived service accounts should be grouped by application and retired aggressively when the process they support is decommissioned. Shared accounts are especially problematic because they obscure ownership and make true recertification impossible. The NHI Lifecycle Management Guide is useful here because it frames review as part of lifecycle governance, not a point-in-time checkbox. For deeper risk patterns, NHI Management Group’s 52 NHI Breaches Analysis shows how missed ownership and lingering access commonly precede compromise.

The most difficult edge case is dynamic infrastructure where identities are created automatically, rotated continuously, and consumed by other machines. In those environments, static review cadences can lag reality, so policy-as-code and continuous attestation become more reliable than quarterly recertification alone.

Related resources from NHI Mgmt Group

• How should security teams govern service accounts, machine identities and workload access differently?
• How should teams reduce the risk of orphaned service accounts and stale tokens?
• What breaks when service accounts are excluded from access reviews?
• Why do service accounts and third-party identities complicate compliance reviews?