How do kubeconfigs keep working after offboarding?

Why kubeconfigs outlive the person who used them

Kubeconfigs keep working when they carry their own trust material. If the file contains a client certificate, bearer token, or other embedded credential that the cluster accepts directly, access continues until that specific credential is revoked, expires, or is no longer trusted by the API server.

That means offboarding the human account is often only part of the job. The real control point is the credential path inside the kubeconfig, not the user record in an identity system or ticketing workflow.

What makes a kubeconfig persist after offboarding

The most common failure is simple decoupling: the kubeconfig authenticates to the cluster using a certificate, token, or static credential that is not automatically bound to the person’s employment status. A user can be removed from an upstream directory, yet the kubeconfig still works if the cluster still trusts the embedded material.

This is why kubeconfigs behave differently from interactive login sessions. They are often operational artefacts that can survive account removal, especially when copied into laptops, CI runners, admin workstations, or scripts that were never cleaned up. The risk is highest when the same file is reused across environments or shared between operators.

For Kubernetes-specific identity and access patterns, NHIMG’s Kubernetes NHI Security Guide covers the broader control surface around service accounts, tokens, RBAC, and kubeconfig use.

What matters operationally is whether the credential is short-lived and centrally enforced, or long-lived and copied around. A kubeconfig that depends on reusable certificates or tokens can continue to authenticate long after the original operator should have lost access.

How to stop stale kubeconfigs from keeping access alive

The fix is to revoke the credential that the kubeconfig actually uses, then remove or replace the file wherever it was stored or distributed. If the kubeconfig relies on a client certificate, revoke the issuing authority or rotate the trust chain where that certificate came from. If it relies on a bearer token or other static secret, invalidate that secret at the source and confirm no secondary copies remain in automation, backups, or home directories.

Offboarding should also include a search for kubeconfigs in scripts, CI variables, build agents, secret stores, and shared admin tooling. If the same credential is embedded in multiple operational paths, revocation has to reach all of them or access will continue through the remaining copy.

NHIMG’s Employee Offboarding Security Guide is useful when you need a practical leaver workflow that includes session, token, and credential cleanup.

Where organisations manage joiner-mover-leaver processes centrally, the important design choice is to treat kubeconfigs as governed access artefacts, not just files. NHIMG’s Joiner-Mover-Leaver (JML) Guide is a good companion for aligning deprovisioning with credential lifecycle.

How to tell whether offboarding actually worked

Validation should be technical, not administrative. Test whether the removed user or revoked credential can still authenticate to the cluster, then check whether any known kubeconfigs still reference that trust path. If the answer is yes, the offboarding event is incomplete even if the HR or IAM record says the person is gone.

Also verify whether the cluster still accepts the old certificate chain or token type. In many environments, access persists because the cluster trusts a reusable authority rather than a unique, time-bounded identity. That is a control design issue, not just an execution mistake.

When you need a broader lifecycle view of how these artefacts linger, NHIMG’s NHI Lifecycle Management Guide covers provisioning, rotation, offboarding, and visibility across the credential lifecycle.

External guidance on digital identity and least privilege is also relevant here. NIST Cybersecurity Framework 2.0 helps frame the governance problem, while NIST SP 800-63 Digital Identity Guidelines is useful when you are deciding how strongly an authenticator should bind to a specific person and lifecycle event.

Risk and Threat Considerations

Stale kubeconfigs create an access path that survives the person. That is a direct privilege-retention risk, and it becomes more serious when the file is reused in automation, shared admin tooling, or multiple clusters because one forgotten credential can preserve broad operational access.

Failure mechanism: The cluster continues to trust a credential that was copied into the kubeconfig, so offboarding the user account does not remove the authenticating material that still works against the API server.

Impact: Former users, compromised laptops, or anyone who obtains the file can continue to access the cluster until the underlying credential, token, or trust chain is revoked, which can expose workloads, Secrets, and administrative actions.

Practitioner Guidance

What to verify: Confirm whether each kubeconfig authenticates with a user-bound, expiring credential or with a static certificate, token, or embedded secret. If the latter is true, treat the file itself as a sensitive access artefact that must be inventoried and retired.

Decision rule: If revoking the human account does not automatically invalidate cluster access, you need a separate revocation and rotation path for the kubeconfig credential. Do not assume directory offboarding, SSO disablement, or laptop collection will stop cluster access by themselves.

Practitioner takeaway: The right offboarding question is not “was the user removed?”, it is “does any trusted Kubernetes credential still authenticate on that user’s behalf?”

Related resources from NHI Mgmt Group

• Who is accountable when revoked sessions keep working after access should end?
• Why do former employees still keep access after offboarding in many organisations?
• How should security teams keep Sigma detections working after normalising telemetry to OCSF?
• What breaks when movers keep inherited access after a role change?