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 continues running. The credential is gone; the session is not. This gap between credential revocation and session termination is the zombie session problem, and it is more common than JIT platform documentation suggests.

Why the gap exists

When an IAM credential is revoked or a vault checkout is returned, the access control layer that authenticated the session is 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 does not re-authenticate on credential revocation. An SSH session authenticated with the IAM-issued key remains open until the connection is explicitly terminated or the underlying TCP socket drops. A database session authenticated via a vaulted credential remains 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 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 that the JIT platform has notionally revoked.

Which JIT architectures are most exposed

Cloud-IAM-based JIT without network-layer controls is most exposed. When a JIT platform revokes an AWS IAM role assignment, the IAM control plane is updated, but any established connections to services that cached the credentials at session start may continue for the duration of the cached credential's lifetime or until the connection is closed. CloudTrail will show the role revoked; the session may still be making API calls with the original credential until it expires.

SSH-based access is exposed because established SSH connections do not re-authenticate on key rotation or IAM credential change. An engineer with an open SSH session to a bastion host or production server will remain connected after the JIT session expires unless the session is actively terminated — by the JIT platform, by a network-layer control, or by the engineer closing the terminal.

Database connections and connection pools are exposed because application connection pools hold connections open across session boundaries. A JIT-granted database credential that authenticated a connection pool entry will remain cached in the pool until the connection is explicitly closed or the pool is recycled. This is primarily a concern in NHI/automated access contexts rather than interactive access.

Architectures with structural mitigations

Proxy-based JIT (StrongDM, CyberArk PSM) has a structural advantage here. The session proxy controls the network layer, not just the authentication layer. When the JIT session expires, the proxy terminates the underlying connection — not just the credential. The zombie window is zero because the proxy owns the connection lifecycle, not the endpoint. This is the strongest architectural mitigation for zombie sessions and is the primary operational advantage of proxy-based JIT over IAM-only JIT for interactive access.

Certificate-based JIT (Teleport) is less exposed than IAM-based approaches for interactive sessions because Teleport's proxy also controls the connection — certificates issued by Teleport CA are authenticated through Teleport's reverse proxy, and Teleport can terminate connections on certificate expiry. The connection lifecycle is managed by the platform, not left to the endpoint.

Britive's IAM-based JIT does not by itself terminate sessions; it revokes the IAM entity and relies on downstream credential expiry and connection teardown. The platform documentation is clear about this: zombie session revocation is a separate operational concern from IAM cleanup. This is not a defect in Britive's design — it is the correct behavior given the IAM layer it operates at — but buyers need to know the mitigation responsibility falls to the operator, not the platform.

Operational mitigations for IAM-based platforms

Where the JIT platform does not control the connection lifecycle, session termination requires additional controls:

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 session termination independent of the IAM layer. This requires network policy management that can be signaled by the JIT platform at session expiry — a webhook, an event, or direct integration with a firewall or network policy controller.

Short session window + activity monitoring. Short session windows reduce the zombie window's practical impact. If sessions are typically 15-30 minutes and the activity within the session is monitored, the gap between credential revocation and session termination is bounded. This does not eliminate zombie sessions; it limits their duration and detectability.

Target-side session management. Some targets can be configured to enforce session timeout independent of the IAM credential. A PostgreSQL database can be configured to terminate idle connections after N minutes. A Linux host's SSH configuration can enforce connection timeouts. These controls reduce the zombie window at the target but require per-target configuration at scale.