Topic starter
06/11/2026 6:55 pm
TL;DR: Kubernetes offboarding still leaves access alive when static kubeconfigs, cached tokens, or shared secrets survive a leaver workflow, according to Twingate's analysis. Practitioners need revocation to happen at session and credential issuance time, not only in HR or IdP systems.
Editorial analysis by NHI Mgmt Group, based on content published by Twingate: “Kubernetes Offboarding: Tools That Cut Access”.
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.
Key questions
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Kubernetes offboarding fails when credentials outlive the employee record and remain usable outside the identity provider.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/11/2026 6:56 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Kubernetes offboarding fails when kubeconfigs outlive access