A token should be revoked when the workload is retired, the service account’s purpose changes, or the token has outlived the access it was created to support. Teams should also revoke immediately after suspected exposure. If revocation is not part of the workload lifecycle, the organisation is leaving standing access in place by default.
Why This Matters for Security Teams
Kubernetes service account tokens often behave like standing credentials unless they are tied to a clear lifecycle. That is a problem because the token can outlive the pod, the deployment, or even the purpose it was created for. NHI governance is not just about issuance; it is about knowing when access must end. The pattern is familiar across identity programs: if revocation is not operationalised, exposure becomes default access. NHIMG research shows that 91% of former employee tokens remain active after offboarding, which is a lifecycle failure, not a tooling failure, and the same logic applies to service accounts.
Security teams should treat revocation as a normal lifecycle event, not an incident-only action. The NHI Lifecycle Management Guide is useful here because it frames identity retirement, rotation, and ownership changes as part of operational control, while the OWASP Non-Human Identity Top 10 reinforces that unused or overextended credentials are a common exposure path. In practice, many security teams encounter token misuse only after the workload is gone and the access should have died with it.
How It Works in Practice
Teams should revoke a Kubernetes service account token when the workload is decommissioned, when the application owner changes, when the token is no longer needed for a specific job, or when there is any credible sign of exposure. That means revocation logic should follow the workload lifecycle, not just the cluster lifecycle. If a service account supports a batch job, its token should be short-lived and automatically retired at job completion. If it supports a long-running service, the team should still define a TTL, a rotation trigger, and an owner for renewal or replacement.
Current guidance suggests pairing Kubernetes controls with broader NHI governance: bind each service account to a single purpose, avoid reuse across applications, and record the revoke condition before the token is issued. This is where Ultimate Guide to NHIs — Static vs Dynamic Secrets is especially relevant, because long-lived static credentials behave very differently from ephemeral ones. If the token is used in CI/CD, the Guide to the Secret Sprawl Challenge helps explain why secrets often remain valid long after the original use case disappears.
A practical revocation workflow usually includes:
- Inventory the service account owner, workload, and intended access scope.
- Set a clear expiry or rotation policy for the token, even if Kubernetes can auto-mount it.
- Revoke immediately after retirement, ownership transfer, or suspected leakage.
- Verify that downstream systems stop accepting the token before considering the change complete.
For teams using policy-as-code, this can be enforced through admission controls and lifecycle automation, but manual exceptions should be rare and documented. These controls tend to break down in shared clusters with overused service accounts because ownership becomes ambiguous and revocation can break multiple applications at once.
Common Variations and Edge Cases
Tighter revocation discipline often increases operational overhead, so organisations need to balance security gain against release friction. Shared namespaces, legacy controllers, and third-party operators complicate the answer because one token may support several jobs, and revoking it can cause immediate service disruption. That is why current guidance is evolving toward narrower workload identity, shorter-lived credentials, and explicit per-task authorization rather than broad, persistent access.
The hardest cases are long-running agents, controllers, and automation pipelines that cannot tolerate frequent credential churn. In those environments, revocation should still be tied to intent change, not just time. If the service account’s purpose changes from read-only telemetry to deployment control, the old token should be revoked and replaced rather than extended. If there is suspected exposure through logs, tickets, or code commits, revocation should happen first and investigation should follow. NHIMG research on exposed tokens shows why this matters: credential leakage is often discovered in collaboration tools and repositories, not just in the cluster itself, and the Salesloft OAuth token breach is a reminder that valid tokens are frequently the real blast radius. For a broader treatment of recurring failure patterns, see Top 10 NHI Issues and the OWASP Non-Human Identity Top 10. The practical limit appears when revocation is separated from ownership, because no one can prove the token is still needed.
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-03 | Token revocation and rotation are core NHI lifecycle controls. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access depends on timely removal of stale credentials. |
| NIST AI RMF | GOVERN | Lifecycle accountability for autonomous workloads requires governance and ownership. |
Assign clear owners for workload identities and require documented revocation criteria before issuance.
