A 2026 Sagiss report found 79% of former employees still had at least one active work account after leaving. For Kubernetes clusters, the problem is worse: static kubeconfigs and service account tokens often survive HR offboarding entirely. See Twingate Privileged Access for Kubernetes documentation for the architectural fix.

The Sagiss 2026 offboarding report, published in October 2026, surveyed 1,000 former employees and found that 79% still had access to at least one work account after leaving. More telling: 82% of people who dutifully returned their laptop still had a working login somewhere.

If that's the baseline for SaaS and email, think about what it means for Kubernetes.

Kubernetes access doesn't usually run through Okta's provisioning API. It runs through kubeconfig files scattered across laptops, CI runners, and ~/.kube/ directories on jump hosts nobody remembers setting up. When an engineer leaves, HR disables their email. The kubeconfig keeps working.

This post sorts Kubernetes access tooling by one question: when you disable an identity, does cluster access actually stop?

The three ways engineers authenticate to Kubernetes

Before we can talk about revocation, we have to be honest about how people actually get into clusters. There are roughly three patterns, and they fail very differently on offboarding day.

1. Static kubeconfigs with client certificates

The default kubeadm bootstrap, most self-hosted setups, and a lot of homegrown "share this file in 1Password" workflows end up here. The kubeconfig contains an x509 client certificate signed by the cluster CA.

The uncomfortable truth: core Kubernetes has no certificate revocation list. The official Kubernetes authentication documentation is explicit about this. Once a client cert is signed, it's valid until it expires. There is no kubectl revoke command. If you need to actually invalidate a certificate before its expiry, you rotate the cluster CA and reissue certs to every legitimate user, controller, and kubelet. Nobody does this casually.

In practice, "revocation" for static certs means one of:

• Waiting for the cert to expire (often a year out)

• Removing the user from any RBAC bindings that reference their cert subject

• Rotating the entire cluster CA

Option two only works if the cert was bound to a specific username or group that RBAC actually checks. A cert with CN=admin bound to cluster-admin is effectively a permanent root key.

2. IdP-backed authentication (OIDC and cloud IAM)

This is the right direction. The cluster trusts an external identity provider, and kubectl fetches a short-lived token on demand.

• OIDC: kubectl plugins like kubelogin or oidc-login open a browser, you authenticate to Okta / Google / Entra, and a JWT is passed to the API server. The API server validates it against the IdP.

• AWS EKS: aws eks get-token signs an STS GetCallerIdentity request. The aws-auth ConfigMap (or newer EKS access entries) maps IAM principals to Kubernetes users/groups.

• GKE: gke-gcloud-auth-plugin exchanges your Google identity for a cluster token.

• AKS: Entra ID integration maps directory users and groups to RBAC.

Revocation here is real, but conditional. Disable the user in the IdP and new tokens stop issuing. Existing tokens are usually short-lived (minutes to an hour), so access drains quickly.

The catch is in the word "usually." Revocation only works if:

1. Every cluster is actually wired to the IdP (no legacy clusters still using static admin.conf)

2. No engineer has saved a long-lived token or client cert as a fallback

3. Service account tokens the engineer created aren't still sitting in some namespace

4. The break-glass kubeconfig in your incident response runbook doesn't have their name on it

In most orgs I've seen, at least two of those four fail.

3. Access-layer authentication (the credential never lives on the laptop)

The third pattern moves the cluster credential off the engineer's machine entirely. The engineer authenticates to an access proxy using their corporate identity. The proxy holds the cluster credentials and brokers the connection. The cluster API server is never exposed to the public internet, and the engineer's kubectl talks to a local endpoint that routes through the proxy.

In this model, there is nothing to revoke on the laptop. The kubeconfig, if there is one, points at a local or private endpoint that only works while the user's session is valid. Disable the identity in the IdP, and the proxy stops brokering. That's the whole revocation flow.

Twingate Privileged Access for Kubernetes works this way, but it's not the only implementation of the pattern. Teleport and some reverse-proxy ZTNA products follow a similar architecture. The architectural property matters more than the vendor.

A revocation reality check

Here's the question the Sagiss data really points at: after you disable the identity, what still works?

The pattern is obvious once you lay it out: the more the credential lives on the engineer's machine, the less your offboarding process actually reaches it.

Why OIDC alone isn't enough

I want to be fair to OIDC, because when it's deployed correctly it's genuinely good. But "deployed correctly" is doing a lot of work in that sentence.

A typical mid-size org has:

• Three production EKS clusters wired to IAM + OIDC

• One GKE cluster from the acquisition two years ago

• A self-hosted cluster running the observability stack, provisioned by an SRE who left in 2023

• Four dev clusters on Kind/k3s that engineers run locally but occasionally share access to

• A disaster-recovery kubeconfig in the ops team's shared vault

When Alice leaves, your IdP disable catches the first three. The GKE cluster was wired to a different Google Workspace tenant. The self-hosted cluster still uses the original admin.conf; everyone who's been there more than a year has a copy. The dev clusters have whatever Alice set up. The DR kubeconfig has CN=alice in it.

This isn't a failure of OIDC. It's a failure of the assumption that revocation happens at the identity layer when credentials live everywhere else.

The architectural fix: no cluster credential on the endpoint

If engineers never hold a cluster credential, disabling the identity is the revocation. That's the whole argument.

Concretely, this means:

1. The cluster API server has no public listener. It accepts connections only from inside the private network or from the access proxy's egress point.

2. Engineers authenticate to the access layer using corporate SSO, with MFA enforced by the IdP.

3. The access layer brokers the Kubernetes connection and passes the user's identity through to the cluster as an OIDC claim or impersonation header. Authorization is still handled by native Kubernetes RBAC.

4. Sessions are short-lived and tied to the IdP session. When the IdP session ends, the access ends.

5. No long-lived client certs, no static kubeconfigs, no service account tokens on laptops.

With Twingate specifically:

• The cluster sits behind a Connector that makes only outbound connections. There's no public API endpoint to scan for, no port 6443 open to the internet.

• Engineers install the Twingate Client and authenticate through the org's IdP (Okta, Google, Entra, etc.).

• When an engineer runs kubectl, the Client intercepts DNS for the cluster's private hostname and tunnels the connection through the Connector.

• The engineer's corporate identity is passed through as an OIDC token the cluster validates. RBAC in the cluster decides what they can actually do.

• Just-in-time access can gate connections behind time-bound approvals, so even authorized engineers don't hold standing access to production.

Disable the engineer in the IdP, and three things happen at once: the Client can't reauthenticate, the Twingate session expires, and any JIT grants revoke. The kubeconfig on their laptop, if there is one, points at a hostname that only resolves through a tunnel they can no longer open.

Important caveat: Twingate does not replace Kubernetes RBAC. It controls whether someone can reach the API server and as whom. What they can do once they're in is still up to the roles and bindings you've defined in the cluster. If you've been sloppy with RBAC, no access layer will save you.

What to actually do about it

If you only take one thing from this, make it a hard inventory question: for every cluster your org runs, which identity provider governs access, and what happens on that cluster when a user is disabled in the IdP?

If the answer for any cluster is "nothing happens" or "I'd have to log in and revoke things manually," that cluster is the Sagiss statistic. It's the account that stays live after the laptop comes back.

A reasonable sequence:

1. Audit for static kubeconfigs and long-lived service account tokens. Check ~/.kube/ on bastion hosts, CI secrets, shared vaults, and the ops team's Google Drive. Treat anything you find as a credential that will survive offboarding.

2. Wire every cluster to a central IdP. Even legacy clusters. OIDC via kubelogin is a weekend project for most setups.

3. Make the API server private. If kubectl works from a coffee shop without a VPN or proxy, something is wrong.

4. Move engineer access behind a proxy that enforces SSO and short sessions. That's the step that makes offboarding a single IdP action instead of a scavenger hunt.

5. Rotate the cluster CA on a schedule so that even forgotten client certs eventually die on their own.

The deeper point is that the Sagiss report isn't really about laziness in offboarding workflows. It's about architectures that let credentials outlive the identities that issued them. Kubernetes, by default, is one of those architectures. It doesn't have to be.

Closing

For a walkthrough of putting a Kubernetes cluster behind Twingate, including how identity is passed through to the API server and how JIT access policies are configured, see the Privileged Access for Kubernetes documentation and the Connectors overview.

New to Twingate? You can use Twingate for free for up to 5 users, request a personalized demo, or reach out to the team over on the Twingate subreddit.