SI-2(6): Removal of Previous Versions of Software and Firmware

SI-2(6) requires you to remove previous versions of software and firmware after you install an updated version, so older binaries, packages, and images cannot be invoked, rolled back to, or exploited. Operationalize it by defining “previous versions” by platform, enforcing automated uninstall/purge in your patch workflows, and keeping evidence that removal occurred. ¹

Key takeaways:

• Define what “previous versions” means for each technology (endpoints, servers, containers, network gear, OT) and document allowed exceptions.
• Build removal into patching, imaging, and firmware upgrade workflows, with verification checks and rollback controls.
• Retain machine-verifiable evidence (tool logs, package inventories, firmware baselines, change records) that shows prior versions are gone.

The si-2(6): removal of previous versions of software and firmware requirement is a control enhancement under NIST SP 800-53 SI-2 that tightens your patch process: installing an update is not enough if older code remains resident and callable. Old versions can reappear through rollback paths, side-by-side installs, cached installers, leftover libraries, inactive partitions, or “gold images” that still contain vulnerable components.

For a Compliance Officer, CCO, or GRC lead, the practical goal is straightforward: make “remove old versions” a standard outcome of every update event, then prove it with repeatable evidence. The hard part is scoping. “Software and firmware” spans endpoints, servers, hypervisors, container images, network devices, IoT, and specialized appliances. Removal also collides with operational realities like emergency rollback, vendor support constraints, and regulated environments where changes must be tightly controlled.

This page translates SI-2(6) into an implementable requirement: who owns it, where it lives in change/patch operations, what to automate, what to measure, and what artifacts auditors ask for. It also highlights common failure modes, especially where teams patch successfully but cannot demonstrate removal of the prior version. ²

Regulatory text

Requirement (verbatim): “Remove previous versions of {{ insert: param, si-02.06_odp }} after updated versions have been installed.” ¹

What the operator must do

• Trigger condition: an updated version is installed (software update or firmware upgrade).
• Required outcome: the previous version is removed (not merely unused).
• Scope placeholder: the parameterized text (“{{ insert: param, si-02.06_odp }}”) is organization-defined in your system security plan or equivalent control statement. Treat it as “software and firmware in scope for the system.” ¹

A compliant interpretation is that you must prevent old versions from remaining available for execution, reinstallation, or downgrade in normal operations, unless you document an exception with compensating controls.

Plain-English interpretation (what SI-2(6) really demands)

If you update something, you must also clean up the old version so it cannot be brought back accidentally or abused deliberately.

This applies to:

• Installed applications and agents (old binaries, DLLs, services, kernel extensions).
• Package-managed software (older packages still installed “alongside” new ones).
• Firmware and boot components (older firmware images stored in alternate partitions or retained as “secondary” images).
• Deployment artifacts (gold images, VM templates, container base images, offline installers) that would redeploy old versions into production.

SI-2(6) is not asking you to eliminate your ability to recover. It is asking you to control recovery paths so they do not become an untracked downgrade route. Your documented exception process is where you handle legitimate rollback requirements.

Who it applies to (entity and operational context)

Entity types

• Federal information systems implementing NIST SP 800-53 controls. ²
• Contractor systems handling federal data where NIST SP 800-53 is flowed down contractually or via an aligned program. ²

Operational contexts where this control is “live”

• Enterprise patch management for endpoints and servers
• Network device firmware management (switches, firewalls, routers, VPN concentrators)
• Virtualization and cloud images (AMIs, templates, golden images)
• Container build pipelines and registries
• OT/IoT or appliance fleets where firmware upgrades are vendor-controlled
• Any environment with strict change control where rollback is common

What you actually need to do (step-by-step)

1) Set scope and definitions (write it down)

Create a short “SI-2(6) Implementation Standard” that defines:

• In-scope asset classes: endpoints, servers, network gear, hypervisors, containers, appliances, OT (as applicable).
• What counts as “previous versions” by platform:
  • OS/package managers: older installed packages, cached packages, superseded libraries.
  • Windows/macOS: side-by-side installs, leftover services/drivers, old agent versions.
  • Containers: older tags and vulnerable base layers in your registry.
  • Firmware: secondary images, fallback partitions, downloaded firmware blobs.
• Approved exceptions: vendor-required retention, rollback windows, safety constraints, air-gapped constraints.
• Exception handling: required approvals, compensating controls, and expiry/recertification.

Map this standard to a named control owner (usually Patch Management, Endpoint Engineering, Network Engineering, or Platform Engineering) and identify GRC as the reviewer who validates evidence quality. This aligns with the recommended practice to map SI-2(6) to an owner, procedure, and recurring evidence artifacts. ¹

2) Embed removal into your patch and change workflows

Update your patch SOPs so each update has two success criteria:

1. updated version installed, and
2. prior version removed (or exception recorded).

Practical implementation patterns:

• Endpoints/servers: enforce uninstall of superseded versions and remove install caches where feasible; block local admin downgrade paths where appropriate.
• Network devices: after firmware upgrade, validate the running image and remove old image files from flash/storage if the platform supports it; lock boot variables to the approved image.
• Golden images/templates: rebuild images after critical updates; deprecate and disable distribution of older images.
• Containers: rebuild and retag; prune older tags; set retention rules; prevent deployments from referencing old digests.

Tie removal actions to change tickets (or your equivalent change record). The goal is to prove the removal was not ad hoc.

3) Automate removal and verification (don’t rely on technicians)

Auditors expect consistency. Your best control is automation with logs.

Automation examples (choose what matches your stack):

• Patch tools: post-deploy scripts that remove superseded packages and verify installed versions.
• Configuration management: enforce “desired state” where only approved package versions are present.
• MDM/endpoint management: detection rules that flag old versions and remediate.
• Network automation: playbooks that remove inactive images and set boot order.
• Container registry policy: deny deployment of non-approved tags/digests; lifecycle policies that delete old artifacts.

4) Create a verification report that is easy to audit

Define a recurring report that answers two questions:

• “Which assets were updated?”
• “For those assets, do we have evidence the prior version is removed or formally excepted?”

Good verification sources include:

• Software inventory exports (current installed versions)
• Package manager state
• Firmware baseline/config exports
• Registry inventory (images/tags/digests)
• EDR/asset management detections for obsolete versions

5) Govern exceptions without weakening the control

A workable exception process includes:

• Business justification (why old version must remain)
• Compensating controls (restricted access, monitoring, removal of execution paths, network segmentation)
• Time bound: set an expiry and force re-approval
• Tracking: exceptions should be queryable and tied to asset IDs

6) Make it assessable: update your control narrative

In your SSP/control description (or control library), state:

• tools used,
• asset classes covered,
• how removal is enforced,
• how exceptions work,
• what evidence you retain per review cycle. ²

If you use Daydream for control mapping and evidence readiness, this is a clean place to link SI-2(6) to the owner, the procedure, and the evidence checklist so collection stays consistent release after release. ¹

Required evidence and artifacts to retain

Keep evidence that proves both installation of the update and removal of the old version:

Core artifacts (most audits ask for these)

• SI-2(6) procedure/standard (scope, definitions, exceptions)
• System/component inventory showing in-scope assets
• Patch/change records for a sample of updates (tickets, approvals, implementation notes)
• Before/after version evidence (tool output, screenshots only if necessary, command output, device “show version”)
• Removal logs (uninstall logs, package removal logs, automation job logs, firmware file deletion logs)
• Exception register with approvals and expiry

Helpful artifacts (reduce back-and-forth)

• Configuration baselines for firmware boot variables
• Container registry lifecycle policy config and deletion logs
• “Golden image” build pipeline logs and template deprecation records
• Monitoring alerts for prohibited versions and remediation actions

Common exam/audit questions and hangups

Expect questions like:

• “Define ‘previous versions’ for each platform. Does it include cached installers and images?”
• “Show evidence for a sample: update installed and prior version removed.”
• “How do you prevent rollback/downgrade to an insecure version?”
• “How do you handle vendor appliances that keep two firmware images by design?”
• “Where are exceptions documented, approved, and reviewed?”

Hangups that slow audits:

• Evidence exists but is not tied to specific assets (no hostname/serial/asset ID).
• Teams show “patched” status but cannot show uninstall/removal events.
• Containers and golden images are omitted from scope, despite being a common redeployment path.

Frequent implementation mistakes (and how to avoid them)

1. Assuming patching equals removal.
   Fix: require a removal verification step or a tool report that confirms old versions are absent.

2. Ignoring non-production artifact stores (images, templates, registries).
   Fix: treat build artifacts as in-scope because they become production.

3. Keeping rollback paths open without governance.
   Fix: document rollback as an exception with controls (restricted privilege, monitored changes, approved boot configs).

4. Manual-only processes.
   Fix: automate removal checks; use detective controls that open tickets when old versions are detected.

5. No parameterization.
   Fix: explicitly define the “organization-defined parameter” scope in your standard and SSP so assessors don’t have to guess. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source data for this requirement, so don’t anchor your internal justification on a specific regulator action.

Risk-wise, the control reduces:

• Exploitability from residual vulnerable components.
• Uncontrolled downgrades that reintroduce known vulnerabilities.
• Asset drift where inventory shows “updated,” but endpoints still run old libraries or agents.

For federal and contractor environments, the biggest practical risk is assessment failure due to weak evidence: assessors often accept that perfect removal is hard on every platform, but they expect a clear scope, consistent process, and defensible exceptions. ²

Practical 30/60/90-day execution plan

First 30 days (establish control design)

• Assign a control owner and RACI for endpoints, servers, network, cloud/platform, and build pipelines.
• Draft the SI-2(6) standard: definitions of “previous versions,” in-scope technologies, exception criteria.
• Identify where updates occur (patch tooling, firmware workflows, CI/CD) and where old versions can persist (install caches, registries, templates).
• Choose your “audit report” source of truth per platform (inventory, EDR, config management, registry reports).

Next 60 days (implement control operation)

• Update patch SOPs and change templates to include “remove prior version” and “verify removal” steps.
• Implement automation for at least the highest-risk platforms (internet-facing servers, privileged admin tooling, security agents, network edge).
• Stand up an exception register and require approvals; train operators on when exceptions are valid.
• Pilot an evidence pack for a small sample of updates across different asset classes.

By 90 days (stabilize, measure, and make it assessable)

• Produce a repeatable monthly/quarterly evidence bundle: sample tickets, inventories, removal logs, exceptions.
• Add detective monitoring for prohibited versions and tie alerts to remediation tickets.
• Expand coverage to “artifact sources” (gold images, VM templates, container base images).
• Run an internal mini-assessment: can you prove removal for a random sample without hand-curated screenshots?

Frequently Asked Questions

Does SI-2(6) mean we can’t keep rollback images for firmware?

You can keep rollback capability, but you need a governed exception or a design that prevents uncontrolled downgrade. Document how rollback is approved, who can execute it, and what monitoring exists. ¹

What counts as “previous versions” for container images?

Treat older tags/digests of base images and application images as previous versions if they can be deployed. Your control should cover registry retention rules and deployment policies that block old digests.

If a vendor appliance stores two firmware images and won’t delete the old one, are we noncompliant?

Not automatically, but you need to document the constraint and add compensating controls, such as locking boot order to the approved image and restricting who can change it. Capture evidence of the device’s configuration state.

Do cached installers and package caches have to be removed?

If caches enable reinstallation or downgrade, they are a reasonable interpretation of “previous versions” and often show up in findings. Decide per platform, document your rule, and keep evidence of cache controls where you enforce them. ¹

What evidence is strongest for auditors?

Tool-generated logs and inventories tied to asset identifiers beat screenshots. Pair a change record with a version report that shows the new version present and the old one absent.

How should GRC sample-test this control?

Pull a set of recent updates across asset classes and request the same evidence bundle each time: ticket, before/after version, removal log, and exceptions if any. You want a repeatable request that operators can satisfy quickly.

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5