Guide

Zombie Session Revocation

A JIT session expires. The platform revokes the IAM credential and marks the session closed. The engineer's SSH connection to the production database server keeps running. The credential is gone; the session is not. This gap between credential revocation and session termination is the zombie session problem, and it's more common than JIT platform documentation tends to let on.

Why the gap exists

When an IAM credential is revoked or a vault checkout is returned, the access control layer that authenticated the session gets updated. The IAM role no longer exists; the vault password has rotated; the session proxy has marked the session expired. From the JIT platform's perspective, access has ended.

But an established network connection doesn't re-authenticate just because a credential was revoked. An SSH session authenticated with an IAM-issued key stays open until the connection is explicitly terminated or the underlying TCP socket drops. A database session authenticated via a vaulted credential stays active until the connection is closed. The session is alive; the credential that created it no longer is. Hence: zombie.

The zombie window, the time between credential revocation and session termination, depends on the protocol, the target, and what the session is actually doing. An interactive SSH session where the engineer is actively working can persist for hours after credential expiry. An idle database connection maintained by a connection pool can persist indefinitely. A long-running query that started within the JIT window will complete after it, using network access the JIT platform has notionally already revoked.

Exposure by architecture

How exposed an architecture is to zombie sessions comes down to one question: does the platform control the network connection itself, or only the credential that authenticated it?

Architecture	Zombie session exposure	Why
Cloud-IAM-based JIT, no network-layer control	High	Revoking the IAM role updates the control plane, but connections that already cached the credential at session start can continue for the cached credential's remaining lifetime
Direct SSH access, credential-only revocation	High	Established SSH connections don't re-authenticate on key rotation or IAM credential change; the session persists until something actively terminates it
Database connection pools (NHI/automated access)	High	Application connection pools hold connections open across session boundaries; a JIT-granted credential that authenticated a pooled connection stays cached until the pool recycles it
Proxy-based JIT	Low	The session proxy controls the network layer, not just the authentication layer; when the JIT session expires, the proxy terminates the underlying connection directly
Certificate-based JIT with platform-controlled connections	Low	Connections authenticated through the platform's own reverse proxy can be terminated by the platform on certificate expiry, rather than left to the endpoint

Exposure level reflects architectural default behavior, not a judgment on any specific vendor's overall design. A platform with high exposure on this dimension may still be the right choice once the operational mitigations below are in place.

The structural pattern across both rows: architectures where the JIT platform owns the connection lifecycle, not just the credential, terminate sessions cleanly by default. Architectures that operate purely at the credential layer revoke the key and leave connection teardown to the endpoint, which means zombie session risk shifts from a platform problem to an operational one that the buyer has to own.

Operational mitigations for credential-only platforms

Where the JIT platform doesn't control the connection lifecycle, session termination requires additional controls layered on top:

Network-layer session termination. A network policy that drops connections from the source IP or to the target resource when the JIT session expires can force termination independent of the IAM layer. This requires network policy management that the JIT platform can signal at session expiry, a webhook, an event stream, or direct integration with a firewall or network policy controller.

Short session windows plus activity monitoring. Shorter session windows reduce the zombie window's practical impact. If sessions typically run 15 to 30 minutes and in-session activity is monitored, the gap between credential revocation and session termination is bounded rather than open-ended. This doesn't eliminate zombie sessions; it limits their duration and makes them easier to detect when they occur.

Target-side session management. Some targets can be configured to enforce session timeout independent of the IAM credential entirely. A database can be configured to terminate idle connections after a set number of minutes. A host's SSH configuration can enforce its own connection timeouts. These controls reduce the zombie window at the target but require per-target configuration at scale, which is real operational overhead to budget for.

What to ask any JIT vendor directly: when a session expires, what specifically terminates the underlying network connection, and does that happen automatically or does it depend on a separate control the buyer has to build? If the answer is "the credential is revoked," that's a credential-layer answer to a connection-layer question, and the zombie session gap is the buyer's to close, not the platform's.

Key point

Credential revocation is not session termination. If the JIT platform's session-end signal doesn't trigger network-layer connection teardown, zombie sessions are a natural consequence of the architecture, not an edge case. Buyers evaluating JIT platforms for interactive human access to production infrastructure should ask vendors directly which layer they actually control, and budget for the operational mitigations above wherever the answer is "credential only."