Control statement
- a.Replace system components when support for the components is no longer available from the developer, vendor, or manufacturer; or
- b.Provide the following options for alternative sources for continued support for unsupported components [Organization-defined: sa-22_odp.01].
Discussion
Support for system components includes software patches, firmware updates, replacement parts, and maintenance contracts. An example of unsupported components includes when vendors no longer provide critical software patches or product updates, which can result in an opportunity for adversaries to exploit weaknesses in the installed components. Exceptions to replacing unsupported system components include systems that provide critical mission or business capabilities where newer technologies are not available or where the systems are so isolated that installing replacement components is not an option. Alternative sources for support address the need to provide continued support for system components that are no longer supported by the original manufacturers, developers, or vendors when such components remain essential to organizational mission and business functions. If necessary, organizations can establish in-house support by developing customized patches for critical software components or, alternatively, obtain the services of external providers who provide ongoing support for the designated unsupported components through contractual relationships. Such contractual relationships can include open-source software value-added vendors. The increased risk of using unsupported system components can be mitigated, for example, by prohibiting the connection of such components to public or uncontrolled networks, or implementing other forms of isolation.
Organization-defined parameters
These values must be resolved through the organization’s tailoring and governance process. Bracketed parameter references in the control text identify where a decision is required.
From control text to operational evidence
Use Unsupported System Components as a testable risk decision. Translate the official statement into accountable people, repeatable processes, configured technology, and evidence that demonstrates the outcome over time. In this family, pay particular attention to secure acquisition, engineering, development lifecycle, supplier expectations, and system integrity by design.
Implementation workflow
- Define the control boundary, responsible owner, inherited portions, and systems or processes in scope.
- Resolve each organization-defined parameter before declaring the control implemented.
- Document how the implementation satisfies every clause of the official control statement.
- Collect evidence as a normal byproduct of operation rather than only before an assessment.
- Review exceptions, changes, and monitoring results on a risk-based cadence.
Evidence examples
- security requirements in contracts and specifications
- architecture and design review records
- development lifecycle evidence
- supplier assessment and acceptance records
Common failure patterns
- security requirements added after procurement
- supplier claims accepted without evidence
- development exceptions become permanent
- security architecture not tied to testable requirements
Questions practitioners should ask
- What risk decision is this control intended to support in this system?
- Which parts are implemented locally, inherited, shared, or not applicable—and what evidence supports that decision?
- Do the documented narrative, deployed configuration, operating process, and collected evidence agree?
- What event or threshold requires the implementation to be reviewed or changed?
Assessment objectives and methods
Show the assessment objective
- SA-22a.system components are replaced when support for the components is no longer available from the developer, vendor, or manufacturer;
- SA-22b.[Organization-defined: sa-22_odp.01] provide options for alternative sources for continued support for unsupported components.
Examine
- System and services acquisition policy
- procedures addressing the replacement or continued use of unsupported system components
- documented evidence of replacing unsupported system components
- documented approvals (including justification) for the continued use of unsupported system components
- system security plan
- supply chain risk management plan
- other relevant documents or records
Interview
- Organizational personnel with system and service acquisition responsibilities
- organizational personnel with information security responsibilities
- organizational personnel with the responsibility for the system development life cycle
- organizational personnel responsible for component replacement
Test
- Organizational processes for replacing unsupported system components
- mechanisms supporting and/or implementing the replacement of unsupported system components
Related controls
These relationships come from the official OSCAL catalog. They indicate useful dependencies or context, not automatic inheritance or equivalence.
Control enhancements
Enhancements add specificity, strength, or scope to the base control. Baseline badges show explicit selections in the official SP 800-53B OSCAL profiles.
SA-22(1) — Alternative Sources for Continued Support
This enhancement is marked withdrawn in the official OSCAL catalog. Related-control metadata below may identify where its intent was incorporated.
Authoritative sources
Bare Metal Cyber is an independent educational publisher and is not affiliated with or endorsed by NIST. Official control requirements and interpretations remain with NIST and the responsible authorizing organization.