TL;DR: Kubernetes offboarding often fails because static kubeconfigs and long-lived service account tokens keep working after an engineer leaves, according to Twingate, even when central identity access is disabled. Offboarding only closes the gap when cluster credentials are moved off endpoints and tied to short-lived, centrally governed sessions.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Twingate's blog post: Kubernetes offboarding fails when static kubeconfigs, long-lived tokens, and break-glass credentials survive identity disablement.
Why it matters: IAM and platform teams need revocation to reach cluster credentials themselves, not just the corporate directory, or leaver access remains live in Kubernetes.
By the numbers:
- 79% of former employees still had at least one active work account after leaving, according to Twingate's blog post.
- 82% of people who returned their laptop still had a working login somewhere, according to Twingate's blog post.
Context
Kubernetes access is not governed the same way as SaaS or email access, because credentials can exist outside the identity provider and keep working after offboarding. Static kubeconfigs, service account tokens, and copied certs create a revocation problem that HR leaver workflows do not naturally reach.
The key issue is architectural: if the credential lives on an engineer's laptop, in a shared vault, or in a CI runner, disabling the user account does not necessarily stop cluster access. That makes Kubernetes a test of whether identity governance reaches the endpoint where access is actually enforced.
Key questions
Q: How do kubeconfigs keep working after offboarding?
A: Kubeconfigs keep working after offboarding when they contain long-lived client certificates, bearer tokens, or embedded credentials that are not tied to the person’s account lifecycle. Revoke the underlying cluster credential, remove stale kubeconfig files, and rotate the cluster CA or trust chain where certificates were issued from a reusable authority.
Q: Why does relying on long lived secret based service account tokens increase Kubernetes risk?
A: Long lived secret based tokens increase risk because they remain usable far beyond the workload session that created them. If they are exposed in logs, manifests, or a compromised pod, an attacker can reuse them until they are revoked. That extends the attack window, weakens workload isolation, and makes Kubernetes authentication harder to contain during an incident.
Q: What is the difference between OIDC access and static kubeconfig access?
A: OIDC access uses short-lived tokens issued after the user authenticates through an identity provider, so access can be controlled by group membership, claims, and session expiry. Static kubeconfig access usually relies on saved credentials or certificates that remain valid until they are explicitly rotated or revoked, which makes offboarding harder.
Q: What should teams do first when Kubernetes offboarding is weak?
A: First, inventory every Kubernetes credential, service account, token and kubeconfig, then revoke or rotate anything that still grants cluster access. Trace each identity to an owner, remove stale RBAC bindings and fix any path where cluster credentials exist outside the IdP. Finally, enforce short-lived access and automated offboarding.
Technical breakdown
Why static kubeconfigs outlive offboarding
A kubeconfig can contain a client certificate, token, or cluster endpoint that remains valid independently of the user directory. In many self-managed clusters, a signed client certificate cannot be revoked individually, so the only true invalidation path is expiry or cluster-wide rotation. That creates a large persistence window for former users and copied credentials. See the Employee Offboarding Security Guide.
Practical implication: Treat every static kubeconfig as a standing access artifact and remove it from offboarding assumptions.
How IdP-backed Kubernetes access changes revocation
OIDC and cloud IAM move authentication back to a central identity provider, so new tokens stop issuing when the account is disabled. That improves revocation speed, but only if every cluster trusts the same IdP and no fallback credential survives in a vault, laptop, or namespace secret. The control is conditional, not absolute. See the IAM and IGA Basics.
Practical implication: Inventory every cluster trust path and eliminate any legacy access path that bypasses the central IdP.
Why access proxies shrink the credential footprint
An access proxy removes the cluster credential from the endpoint and brokers the connection through a short-lived session. The engineer authenticates to the proxy with corporate identity, and the proxy enforces whether the API server is reachable at all. That changes revocation from hunting down scattered kubeconfigs to ending one live session.
Practical implication: Shift privileged cluster access behind a broker so identity disablement ends access without endpoint cleanup.
Threat narrative
Attacker objective: Retain access to Kubernetes clusters after offboarding so cluster actions remain possible without an active corporate account.
- entry: The access path begins with a kubeconfig, service account token, or cached cluster credential that survives the engineer's departure.
- escalation: The credential remains usable because offboarding only disables the corporate account while the cluster trust artifact still authenticates.
- impact: Former users can continue reaching Kubernetes workloads, administrative APIs, or sensitive namespaces until the credential expires or is removed.
Breaches seen in the wild
- Ledger Connect Kit npm compromise 2023: Attackers phished a former Ledger employee with unrevoked npm access and published a wallet-draining Connect Kit, stealing about $600k on 14 Dec 2023.
- Coupang Signing Key Breach: Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Offboarding that stops at the directory does not stop Kubernetes access. The problem is not just whether a user is disabled in Okta, Entra, or Google. It is whether the cluster still accepts a kubeconfig, a copied certificate, or a service account token that was issued before the leaver workflow started. The implication is that identity governance must extend to the cluster credential itself, not only the human account.
Static kubeconfigs create revocation debt. Once a client certificate is embedded in a kubeconfig, the organisation inherits a credential that often cannot be invalidated cleanly on a per-user basis. That is a structural mismatch between leaver processes and Kubernetes authentication design, and it is why many programmes still discover surviving access long after offboarding is complete. The practitioner conclusion is to treat the kubeconfig as the revocation boundary, not the user record.
Short-lived, centrally brokered sessions are the practical control shift. Kubernetes access works better when the engineer never owns the cluster credential in the first place. If the proxy or access layer holds the sensitive material and ties session validity to the IdP, then identity disablement can actually end access. The governance question becomes whether access is still being issued into places offboarding cannot reach.
Credential residency outside the IdP is the real failure mode: the governance assumption was designed for access that lives in a central directory and can be removed there. That assumption fails when the actor owns a kubeconfig, token, or cert that remains valid after offboarding because the cluster accepts it directly. The implication is that revocation models built around human lifecycle events must be rethought for credentials that outlive the identity event itself.
From our research library:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
- Around 59% of companies report experiencing a data breach related to poorly managed offboarding processes.
- Read next: Employee Offboarding Security Guide
What this signals
Credential residency is the central Kubernetes offboarding problem: when access material exists on endpoints, in shared vaults, or in CI, human leaver workflows cannot reliably revoke it. That is why the control point has to move from user deletion to credential location and session design.
Offboarding should be measured by reachable access, not account status: the decisive question is whether a disabled identity can still open the cluster API, not whether the HR record is closed. Programmes that cannot answer that cluster by cluster are still carrying live access debt.
For practitioners
- Inventory every surviving Kubernetes credential Search laptops, bastion hosts, CI secrets, shared vaults, and namespace secrets for kubeconfigs, client certs, and service account tokens that can still authenticate after a leaver event.
- Wire each cluster to a single identity source Confirm that every production and legacy cluster trusts the same corporate IdP path and that no admin.conf, cached token, or alternate workspace tenant can bypass it.
- Move privileged cluster access behind a broker Use an access layer that keeps the cluster credential off the endpoint and ties each session to identity, expiry, and revocation rather than local files.
- Rotate cluster CA on a scheduled basis Plan for the fact that some static client certificates cannot be individually revoked, so the cluster CA lifecycle must eventually retire forgotten credentials.
Key takeaways
- Kubernetes offboarding fails when credentials outlive the employee record and remain usable outside the identity provider.
- The evidence in the source points to a broad residual-access problem, with many former users still able to reach at least one system after departure.
- The control boundary has to shift from user disablement to credential residency, token lifetime, and proxy-mediated session revocation.
Related NHI Mgmt Group resources: Employee Offboarding Security Guide · SaaS deprovisioning · Joiner-Mover-Leaver (JML) Guide · Ledger Connect Kit npm compromise 2023
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 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Cluster credentials survive leaver workflows in the same way unmanaged NHIs do. |
| NHI-07 — Long-Lived Secrets | Static kubeconfigs and service account tokens remain valid long after the user leaves. | |
| Recommendation — Map Kubernetes offboarding to NHI-01 and revoke every surviving cluster credential on departure. Eliminate long-lived Kubernetes secrets and replace them with short-lived, centrally brokered access. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Kubernetes credentials here behave like authenticators that need lifecycle control and rotation. |
| Recommendation — Use IA-5 to govern issuance, rotation, and retirement of Kubernetes authenticators. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about whether permissions still work after identity disablement. |
| Recommendation — Audit Kubernetes entitlements so disabled identities cannot retain active cluster access. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Residual kubeconfigs and tokens support continued credential use and movement inside clusters. |
| Recommendation — Hunt for leftover kubeconfigs and mapped credentials that preserve access after offboarding. | ||
Key terms
- Kubeconfig: Kubeconfig is the file Kubernetes uses to store cluster connection details and authentication information. If it is exposed, world-readable, or synced insecurely, an attacker may gain access to the cluster. Strong file permissions and careful handling are essential because it directly governs administrative reach.
- Cluster CA Rotation: Cluster CA Rotation is the process of replacing the certificate authority that signs Kubernetes cluster certificates. It is used to retire old trust roots and issue new ones, so nodes, clients, and components must trust the updated CA and any certificates signed by the previous authority are no longer relied on.
- ServiceAccount Token: A ServiceAccount Token is a credential that lets software act as a specific service account without a human user present. In identity systems, it grants authenticated access to APIs, cloud services, or internal resources, so its scope, lifetime, storage, and rotation must be tightly controlled to reduce NHI risk and unauthorized use.
- OpenID Connect: OpenID Connect is an identity layer built on OAuth 2.0 that lets applications authenticate users with compact tokens and standardised key discovery. It is widely used for modern web, mobile, and API-driven systems because it reduces integration overhead compared with older federation patterns.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on November 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org