SI-14 asks you to implement non-persistent components and services that start in a known state and are terminated on a schedule or event you define. The idea is simple. If a server lives for hours and not years, an attacker has less time to use a foothold.
800-53 binds federal systems and contractors. For cloud native teams, much of this comes with the architecture.
What it means in practice
NIST ties it to advanced persistent threats. It assumes that over a long enough period some attacks will succeed, so it limits the window and the attack surface. Components are activated as needed from protected information and terminated periodically or after a session.
Containers that are replaced on every deploy, autoscaled instances rebuilt from an image, and short lived build runners are all examples. Enhancements go further: SI-14(1) Refresh from Trusted Sources, SI-14(2) Non-persistent Information, SI-14(3) Non-persistent Connectivity.
Evidence to collect
- Image build pipeline showing rebuilds from a trusted, signed source.
- Maximum instance or container lifetime settings.
- Deployment records showing replacement, not patching in place.
- Confirmation that state lives outside the disposable component.
Common gaps
Long lived pet servers beside the disposable ones. Images pulled from unverified registries. Credentials baked into images that outlive the instance.
How to implement it
Set a maximum lifetime, rebuild from a pinned base image, and keep data and secrets outside the instance. Scan images before they run, because a fresh component built from a vulnerable base is still vulnerable.
Quick check
Why does shortening lifetime help?
It gives an attacker less time to exploit vulnerabilities and shrinks the attack surface.
