SA-22, Unsupported System Components, says to replace components when the developer, vendor or manufacturer no longer supports them, or to provide alternative sources of support. For software, that means tracking end of life dates for libraries, runtimes and base images, and recording a plan for each one that is past support.
What the control says
The Rev. 5 text has two options. Replace components when support is no longer available, or provide alternative sources of continued support for unsupported components, as the organization defines. SA-22 is in the low, moderate and high baselines.
The discussion defines support as patches, firmware updates, replacement parts and maintenance contracts. It gives the risk plainly: when a vendor no longer provides critical patches, adversaries get an opportunity to exploit weaknesses in what is installed.
When exceptions are allowed
The discussion names two cases for not replacing: systems that provide critical mission or business capabilities where newer technologies are not available, and systems so isolated that installing replacements is not an option. Those are exceptions with a reason, not a default.
Alternative support
The discussion lists two routes. Build in-house support, for example custom patches for critical software. Or contract an external provider for ongoing support. It notes that such contracts can include open source software value-added vendors.
It also lists risk reduction measures such as prohibiting connection of unsupported components to public or uncontrolled networks, or other isolation.
Applying it to software
- Find them. List runtimes, frameworks, base images and libraries with their support status. An SBOM and an inventory give you the list.
- Source the dates. Use each project's own published support policy. Where none exists, treat the component as a risk and note that.
- Sort by exposure. Internet-facing, handling sensitive data and without a patch path come first.
- Choose a path per component: upgrade, replace, buy support, isolate or accept with a review date.
- Record it. Component, status, decision, owner, date.
A library with no release for years is not automatically unsupported in the control's sense. The question is whether anyone will provide a security fix if one is needed. If not, treat it as unsupported.
Common traps
Base images pinned years ago. The application is current while the image underneath is not.
Transitive dependencies. The abandoned package is three levels down and nobody owns it.
Accepting risk with no end date. An exception should carry a review date.
Try it yourself
Open the demo and click a dependency, then look for how deep in the tree an old package can hide.
Click through it at your own pace, or open it full screen.
Quick check
Must every unsupported component be replaced at once?
No. The control allows alternative support, and the discussion names narrow exceptions for critical or isolated systems. Each needs a documented reason.
Does SA-22 apply to low baseline systems?
Yes. It appears in low, moderate and high in the Rev. 5 baseline profiles checked.
Safeguard's SBOM and dependency scanning and asset discovery list what runs, and its compliance and evidence automation stores decisions and review dates. A free scan is at gold.safeguard.sh/scan.
Sources
- NIST SP 800-53 Rev. 5 catalog and baseline profiles, SA-22 (OSCAL content)
- NIST SP 800-53 Rev. 5 page
Last reviewed: 19 October 2026.
