Quick-reference card
| Field | Value |
|---|---|
| Control ID | SA-22 |
| Control Name | Unsupported System Components |
| Framework | NIST SP 800-53 Revision 5 |
| Control Family | System and Services Acquisition |
| Baselines | LOW MODERATE HIGH |
| Relevance | Organization (First Party and Third Party) |
| Risk Severity | HIGH |
What this control requires
SA-22 requires organizations to replace system components that no longer receive patches, firmware updates, or maintenance from their original developer, vendor, or manufacturer. When replacement isn’t possible, you must establish alternative support through in-house capabilities or contractual relationships with external providers.
Most organizations underestimate how quickly unsupported components accumulate. A server running an end-of-life operating system or a legacy application that no longer receives security patches creates a gap that no amount of perimeter defense can close. The control exists because unsupported components don’t just represent technical debt. They represent unpatched vulnerabilities that attackers actively target, knowing that no fix is coming.
In practice, SA-22 forces two decisions. First, you need a process to identify when components lose vendor support and a timeline for replacing them. Second, for components that can’t be replaced because they support critical mission or business functions, you need a documented alternative support plan. That plan might involve developing custom patches internally, contracting with a third-party provider, or isolating the component from public networks to reduce exposure. The NIST SP 800-53 framework treats this control as foundational across all baselines because unsupported components introduce risk regardless of your organization’s size or industry.
Why it matters
Organizations that fail to manage unsupported system components face direct audit and certification risk. Auditors reviewing your System and Services Acquisition controls will look for documented evidence that you’ve identified, replaced, or formally approved the continued use of every unsupported component in your environment. Missing that evidence can result in certification withdrawal, regulatory findings, or failed assessments.
The consequences extend beyond audit outcomes. Unsupported components can’t receive security patches, which means known vulnerabilities remain permanently open. Regulatory bodies increasingly treat the presence of end-of-life software as a material deficiency in an organization’s security posture, particularly in industries subject to HIPAA, PCI DSS, or FedRAMP requirements.
Specifically, the risk compounds over time. Every month an unsupported component stays in production, the number of publicly disclosed vulnerabilities affecting it grows while the likelihood of a vendor-issued fix stays at zero. Your supply chain risk management plan should account for this degradation explicitly.
What attackers exploit
Threat actors target unsupported components because the attack economics favor them. Common vectors include:
- Unpatched known vulnerabilities in operating systems, firmware, or applications that no longer receive security updates
- Missing firmware updates on network devices, IoT hardware, or embedded systems where the manufacturer has ended support
- Outdated cryptographic libraries in legacy software that rely on deprecated algorithms or protocols
- Abandoned third-party integrations where the original vendor no longer monitors for or responds to security issues
- Supply chain weaknesses introduced when vendors stop maintaining components that connect to upstream services or APIs
How to implement
The biggest implementation challenge with SA-22 isn’t the replacement itself. It’s maintaining accurate, current visibility into what’s running in your environment and when each component’s support lifecycle ends.
For your organization
Start by building a complete inventory of all system components, including operating systems, applications, firmware, middleware, and third-party libraries. Map each component to its vendor’s published end-of-life and end-of-support dates. Tools like software asset management (SAM) platforms and configuration management databases (CMDBs) can automate this tracking, but they’re only effective if you keep them current.
Once you have an inventory, establish a replacement timeline for each component approaching end of support. Your system security plan should define how far in advance you begin migration planning. Best practice is to start at least 12 months before a vendor’s announced end-of-support date, giving you time to test replacements without rushing.
For components that can’t be replaced, document a formal exception with justification. That documentation should include the business or mission criticality of the component, a risk assessment covering the specific vulnerabilities introduced, and the compensating controls you’ve put in place. Common compensating controls include network isolation, enhanced monitoring, and restricting the component’s connectivity to public or untrusted networks.
Produce the following evidence for audit readiness:
- A current inventory of all system components with support status
- Documented replacement timelines and migration plans
- Formal exception approvals for any unsupported components remaining in production
- Evidence of compensating controls applied to excepted components
Common mistakes include relying on spreadsheets that go stale within weeks, treating end-of-life tracking as a one-time project rather than a continuous process, and failing to include third-party libraries or embedded firmware in the inventory scope. The UpGuard Breach Risk platform can help identify externally visible components in your attack surface that may have reached end of life.
For your vendors
When assessing vendors against SA-22, you need to verify that they have a systematic approach to managing unsupported components, not just a stated policy. Request specific evidence rather than accepting general assurances.
Include these questions in your vendor risk assessments:
- Do you maintain a current inventory of all system components, including their vendor support status?
- What is your process for replacing components when vendor support ends?
- Do you have any unsupported components currently in production? If so, what compensating controls are in place?
- How do you track end-of-life and end-of-support dates across your technology stack?
- Can you provide documented approvals and risk assessments for any exceptions to your replacement policy?
Request these evidence artifacts from vendors:
- Their system and services acquisition policy, specifically the sections addressing unsupported components
- A redacted inventory showing component support status
- Exception documentation for any unsupported components, including compensating controls
- Their supply chain risk management plan
Red flags to watch for include vendors who can’t produce a component inventory, those who have no documented exception process, and vendors running publicly known end-of-life software on internet-facing systems. The absence of a supply chain risk management plan is another indicator of weak SA-22 compliance.
The UpGuard Vendor Risk platform enables you to assess and continuously monitor your vendors’ security posture, including the detection of outdated or unsupported technologies across their external attack surface.
Evidence examples
| Evidence Type | Example Artifact |
|---|---|
| System component inventory | Asset register listing all hardware, software, and firmware with vendor support status, end-of-life dates, and responsible owners |
| Acquisition and lifecycle policy | System and services acquisition policy defining replacement timelines, exception criteria, and approval workflows for unsupported components |
| Replacement documentation | Migration plans and change records showing completed replacements of unsupported components |
| Exception approvals | Documented justifications for continued use of unsupported components, including risk assessments and compensating controls |
| Supply chain risk management plan | Plan addressing how unsupported component risk is tracked across the organization’s supply chain |
| Network isolation records | Firewall rules, VLAN configurations, or segmentation evidence for isolated unsupported components |
Cross-framework mapping
| Framework | Control(s) | Coverage |
|---|---|---|
| NIST SP 800-171 Rev 3 | 03.16.02 Unsupported System Components | Partial |
Related controls
- PL-02 — System Security and Privacy Plans: Defines the system security plan where unsupported component exceptions and compensating controls are documented.
- SA-03 — System Development Life Cycle: Establishes the lifecycle management processes that determine when components reach end of support and require replacement planning.
Frequently asked questions
What is NIST SP 800-53 SA-22?
SA-22 requires organizations to replace system components when the developer, vendor, or manufacturer no longer provides support, including patches, firmware updates, and maintenance contracts. If replacement isn’t feasible, you must establish alternative support through in-house capabilities or external providers. The control applies across LOW, MODERATE, and HIGH baselines, making it a universal requirement within the NIST SP 800-53 compliance framework.
What happens if SA-22 is not implemented?
Failing to implement SA-22 means unsupported components remain in your environment without documented justification or compensating controls. Auditors treat the absence of documented approvals for continued use of unsupported components as a material finding that can lead to certification withdrawal or regulatory action. Your supply chain risk management plan will also be flagged as incomplete if it doesn’t address how unsupported component risk is tracked and mitigated.
How do you audit SA-22?
Auditing SA-22 starts with verifying that the organization maintains a current system component inventory showing vendor support status for each item. Assessors then confirm that unsupported components have either been replaced with documented evidence of the migration or have formal exception approvals with risk assessments and compensating controls. The procedures addressing replacement or continued use of unsupported system components should be specific enough to demonstrate that the organization isn’t relying on ad hoc decisions.
What is an unsupported system component?
An unsupported system component is any hardware, software, or firmware that no longer receives security patches, updates, or maintenance from its original manufacturer or developer. Common examples include operating systems past their end-of-life date, legacy applications whose vendors have ceased operations, and network devices with discontinued firmware support. Organizations that rely on these components must either replace them or produce documented evidence of alternative support arrangements, such as in-house patching or third-party maintenance contracts.