SA-22, Unsupported System Components, gives the organization two choices. Replace system components when support from the developer, vendor or manufacturer is no longer available, or provide options for alternative sources of continued support for unsupported components. The enhancement, SA-22.1, is titled Alternative Sources for Continued Support.
800-53 binds US federal systems, and others through contract. For small and mid size companies it is a reference, and one auditors apply with little sympathy. An end of life operating system on a production host is a finding almost everywhere.
What it means in practice
The guidance defines support as software patches, firmware updates, replacement parts and maintenance contracts. The risk is plain: when a vendor stops issuing critical patches, attackers get permanent opportunities against known flaws.
It allows exceptions. Systems that provide critical business capability where newer technology is not available may stay, and so may systems so isolated that replacement is impractical. Exceptions need controls, and the guidance mentions in-house support by building customized patches for critical software, contracting with a third party, or moving to open source with community support. It also suggests isolating the component from public or uncontrolled networks.
The same rule applies to software dependencies. A library that has not had a release in years, with an archived repository, is an unsupported component even though nobody bought it.
Evidence to collect
- A component inventory that records vendor, version and support end date.
- A list of components past or near end of support, with a decision for each.
- Replacement project plans with dates.
- For exceptions: the risk acceptance, the compensating controls and the review date.
- Network diagrams showing isolation of the exceptions.
- Contracts for alternative support, if you use them.
Common gaps
No inventory, so end of support dates are discovered during an incident.
Exceptions without expiry. A temporary risk acceptance that renews itself for six years is not a control.
Looking only at operating systems and databases. Frameworks, libraries and firmware age out too.
Treating a running system as proof it is fine.
Click through it at your own pace, or open it full screen.
How to implement it
- Build the inventory first. You cannot retire what you have not found.
- Add support end dates, from vendor lifecycle pages for products and from release history for open source projects.
- Review the list each quarter and flag anything within twelve months of end of support.
- For each flagged item pick replace, support elsewhere, or accept with controls.
- Set an expiry on every exception and assign an owner.
- Check your dependencies for abandoned packages. A scan, such as the free one at gold.safeguard.sh/scan, lists what you use. Reachability analysis helps you judge whether a known flaw in an old library is actually exercised by your code.
Quick check
Can you keep an unsupported component?
Yes, as an exception, with alternative support or compensating controls such as isolation, and a documented decision.
Does SA-22 cover open source libraries?
The control speaks of components with no support from a developer, vendor or manufacturer. An abandoned library fits that idea, so most assessors will expect you to track it.
