SI-14: Non-persistence

Quick-reference card

What this control requires

SI-14 requires organizations to deploy system components and services that don’t retain state between sessions, starting fresh from a known-good baseline every time. This control targets the persistence that attackers depend on by mandating that components are initiated in a verified state and terminated at the end of a session or on a defined schedule.

In practice, this means your infrastructure must include mechanisms to refresh, reimage, or replace components so that any unauthorized changes, implanted malware, or configuration drift are wiped automatically. Organizations define which components are non-persistent, establish the trusted baseline those components return to, and set the frequency at which termination and re-initialization occur. The goal isn’t just to detect compromise after the fact but to ensure that compromise can’t survive a refresh cycle.

The scope of SI-14 spans operating system images, virtual machines, containers, and any service layer where an attacker could establish a foothold. This control doesn’t replace detection capabilities, but it fundamentally limits how long any undetected intrusion can persist. For organizations building a defense-in-depth posture aligned with NIST SP 800-53, non-persistence adds a structural layer that reduces reliance on knowing exactly when or how an attacker got in.

Why it matters

Most organizations assume they’ll detect a compromise before an attacker causes damage. Non-persistence flips that assumption by acknowledging that advanced persistent threats (APTs) are designed specifically to evade detection and maintain long-term access. The longer a system component retains its state, the wider the window an attacker has to escalate privileges, move laterally, and exfiltrate data.

Without non-persistent components, your environment carries accumulated risk. Every hour a compromised system continues to run is an hour where malware can propagate, backdoors can be installed, and attacker tooling can embed itself deeper into your infrastructure. Periodic reimaging and component refresh cycles collapse that window, forcing attackers to re-exploit systems from scratch after every reset.

From a compliance and audit perspective, SI-14 isn’t part of any baseline, which means organizations that implement it are doing so as a risk-driven enhancement. Auditors reviewing your system and information integrity controls will look for evidence that non-persistence is deliberately scoped and consistently enforced. Gaps here signal that your organization hasn’t addressed a well-documented APT mitigation strategy, which can raise questions during risk assessments about the maturity of your overall security program.

The compliance risk extends to third-party oversight as well. If your vendors handle sensitive data or operate infrastructure on your behalf, their failure to implement non-persistence techniques leaves your supply chain exposed to the same persistent threats. Organizations conducting third-party risk assessments should evaluate whether vendors use ephemeral compute resources, container orchestration, or scheduled reimaging to limit attacker dwell time.

The following vectors represent what attackers exploit when non-persistence controls are absent:

• Persistent malware implants that survive reboots by embedding in system images or firmware, maintaining access indefinitely across sessions
• Configuration drift exploitation where unauthorized changes accumulate over time and create unmonitored attack paths
• Lateral movement through long-lived sessions that give attackers time to discover credentials, escalate privileges, and pivot to adjacent systems
• Supply chain compromise via stale vendor infrastructure where compromised vendor components persist without refresh cycles, exposing downstream organizations
• Backdoor installation in static environments where attackers plant persistent access mechanisms that remain undetected because the environment is never returned to a known state

How to implement

The core challenge with SI-14 is that non-persistence fundamentally conflicts with how most production environments are managed. Teams are accustomed to long-lived servers, persistent configurations, and cumulative patching. Shifting to ephemeral components requires rethinking infrastructure architecture, operational workflows, and change management processes.

For your organization

Start by identifying which system components are candidates for non-persistence. Not every component needs to be ephemeral, but high-risk targets such as web-facing servers, application containers, and development environments benefit the most from refresh cycles.

Build your trusted baseline images using a hardened, validated configuration. These golden images should be version-controlled, integrity-checked, and stored in a secure repository, so that every time a component is refreshed or reimaged, it returns to this exact state.

Use infrastructure-as-code tools to define and enforce these baselines, ensuring that configuration drift is eliminated at every refresh cycle. This approach also provides auditable evidence that your refresh process consistently produces components matching the approved baseline.

Define your termination and refresh frequency based on risk. Session-based termination works for user-facing services where components are destroyed at logout. For backend infrastructure, set organization-defined intervals, balancing the security benefit of frequent refreshes against the operational cost of potential service disruption. Document the rationale behind your chosen frequency so auditors can validate that the decision reflects your threat model.

Implement the technical mechanisms that enable non-persistence. Container orchestration platforms can spin up fresh instances from trusted images on every deployment, and virtual desktop infrastructure (VDI) can reset user environments at session end.

Immutable infrastructure patterns prevent runtime modifications entirely, forcing all changes through the build pipeline. Continuous monitoring of your attack surface helps verify that refreshed components match their expected baseline state.

Common mistakes include treating non-persistence as a checkbox without verifying that refreshed components return to the trusted baseline. Another frequent failure is setting refresh intervals that are too infrequent, which gives attackers a functionally persistent environment despite the control being “implemented.” Ensure your audit records capture each refresh event, the baseline image used, and confirmation that the component reached its known state.

For your vendors

When evaluating vendor compliance with SI-14, focus on whether the vendor has made deliberate architectural decisions to limit persistence rather than relying solely on traditional patching and detection.

Ask these questions during vendor assessments:

• Which system components in your environment are configured as non-persistent, and what criteria did you use to scope them?
• What is the trusted baseline for each non-persistent component, and how is baseline integrity verified before redeployment?
• What is your defined refresh or termination frequency, and what risk analysis supports that interval?
• Do you use container orchestration, immutable infrastructure, or virtual machine reimaging to enforce non-persistence?
• How do you ensure that persistent data stores (databases, logs) are segregated from non-persistent compute layers?

Request evidence that demonstrates active implementation, not just policy documentation. System design documents should show which components are ephemeral and which retain state.

Configuration management records should demonstrate regular refresh cycles, and audit logs should capture termination and re-initialization events with timestamps and baseline version references.

Red flags during vendor risk evaluation include vendors who claim non-persistence but can’t identify which components are ephemeral, vendors whose refresh intervals haven’t been reviewed in over a year, and vendors who lack audit trails for component reimaging events. If a vendor can’t demonstrate that their non-persistent components return to a known state after termination, the control is effectively unimplemented.

Verify vendor claims by requesting screenshots or exports from orchestration platforms showing container lifecycle policies, immutable image registries with version histories, and automated deployment pipelines that enforce fresh builds. Cross-reference these artifacts against the vendor’s system design documentation to confirm alignment.

Evidence examples

Cross-framework mapping

No cross-framework mappings are currently configured for this control.

Related controls

• SC-30 — Concealment and Misdirection: complements non-persistence by adding deception techniques that make it harder for attackers to identify and target persistent components in the first place
• SC-34 — Non-modifiable Executable Programs: reinforces non-persistence by ensuring that executable code cannot be altered at runtime, preventing attackers from modifying components between refresh cycles
• SI-21 — Information Refresh: extends the non-persistence concept to data and information sets, ensuring that cached or stored information is periodically replaced with trusted copies from authoritative sources

Frequently asked questions

What is NIST SP 800-53 SI-14?

SI-14 is a system and information integrity control that requires organizations to implement non-persistent system components initiated in a known state and terminated at the end of a session or on a defined schedule. The control reduces attacker dwell time by ensuring that compromised components are automatically replaced with trusted baseline images through reimaging, container refresh, or virtualization techniques. Because non-persistent components don’t retain state between sessions, any malware, unauthorized configuration changes, or backdoors installed by an attacker are eliminated at the next refresh cycle.

What happens if SI-14 is not implemented?

Without SI-14, system components retain their state indefinitely, giving attackers an unlimited window to maintain persistence after an initial compromise. Malware implants, backdoors, and unauthorized configuration changes survive reboots and patching cycles, allowing adversaries to escalate privileges and move laterally across your environment. Organizations also face audit risk, as failing to implement non-persistence techniques signals a gap in APT mitigation strategy that auditors and assessors may flag during compliance reviews. The absence of session termination and component reimaging controls makes it substantially harder to contain incidents and restore systems to a verified state.

How do you audit SI-14?

Auditing SI-14 starts with verifying that the organization has identified which system components are designated as non-persistent and that trusted baseline images exist for each one. Assessors examine system design documentation, container orchestration policies, and infrastructure-as-code templates to confirm that non-persistent components are initiated in a known state. Audit logs should demonstrate that termination events occur at session end or at the organization-defined frequency, with each event recording the baseline version applied during re-initialization. Threat monitoring capabilities complement auditing by validating that refreshed components match their expected configuration and that no unauthorized modifications persist between refresh cycles.

How does non-persistence protect against advanced persistent threats?

Non-persistence directly counters the core APT strategy of establishing long-term, undetected access within a target environment. By terminating system components and reimaging them from a trusted baseline on a defined schedule, organizations eliminate the persistent foothold that APT actors rely on to maintain access across sessions. This approach removes the need to first determine whether a compromise occurred, because every refresh cycle restores components to a verified known state regardless of what may have happened during the previous session. The result is a structural defense that reduces attacker dwell time and forces adversaries to re-exploit systems after each refresh, significantly increasing the cost and difficulty of sustained intrusion campaigns.