| name | SA-22_unsupported-system-components |
| description | Replace system components when support for the components is no longer available from the developer, vendor, or manufacturer; |
| category | configuration |
| version | 5.2.0 |
| author | cyberstrike-official |
| tags | ["nist","sp800-53","rev5","sa-22","sa"] |
| tech_stack | ["any"] |
| cwe_ids | ["CWE-16"] |
| chains_with | ["PL-2","SA-3"] |
| prerequisites | [] |
| severity_boost | {"PL-2":"Chain with PL-2 for comprehensive security coverage","SA-3":"Chain with SA-3 for comprehensive security coverage"} |
SA-22 Unsupported System Components
High-Level Description
Family: System and Services Acquisition (SA)
Framework: NIST SP 800-53 Rev 5
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.
What to Check
How to Test
Step 1: Review Documentation
Examine the System Security Plan (SSP) and related artifacts for SA-22 implementation details. Verify the organization has documented how this control is satisfied.
Step 2: Validate Implementation
# For cloud environments, use cloud-audit-mcp tools
# For on-premises, review system configurations directly
# Example: Check if account management policies exist
grep -r "account.management\|access.control" /etc/security/ 2>/dev/null
Step 3: Test Operating Effectiveness
Verify the control is actively functioning, not just documented. Check logs, configurations, and operational evidence.
Tools
