RMFInsider

SA-22 Unsupported System Components gives you exactly two ways out, and writing a paragraph about how aware you are of the problem is not one of them. Either you replace the component when the developer, vendor or manufacturer stops supporting it, or you provide an alternative source of continued support, which NIST SP 800-53 Rev 5 frames as in-house capability or support from an external provider the organization has named. That is the entire control. So when an assessor puts a finger on the box running an operating system the vendor retired, the question is never whether you knew. The question is which of those two paths you are on, who funds it, and what date it ends.

What SA-22 Says, and What It Does Not Say

The control statement has two parts. Part a: replace system components when support is no longer available from the developer, vendor or manufacturer. Part b: provide alternative sources of continued support for components that cannot be replaced, from in-house resources or from an external provider the organization defines. There is no part c.

The Rev 5 discussion is where the usable detail sits. It defines support for system components as including software patches, firmware updates, replacement parts and maintenance contracts. That list is your checklist for the word “support,” and it is wider than patching alone. The discussion grants two narrow reasons replacement might not happen: components delivering critical mission capability where newer technology is not available, and systems so isolated that installing replacement components is not an option. The operational technology discussion adds the line that matters for your write-up, which is to identify a way to keep the component supported and to consider additional compensating controls against known threats and vulnerabilities. Note also that there is no separate enhancement to satisfy: the alternative-sources language that once sat in SA-22(1) has been folded into the base control.

How DoD Turns This Into a CAT I

At the control layer SA-22 is a compliance status. At the scan layer it is a high-severity open finding, and that is the version your program manager hears about first. Control Correlation Identifier CCI-003376 carries the SA-22 replacement sentence word for word, which is how STIG rules trace back to it. In the General Purpose Operating System Security Requirements Guide, SRG-OS-000830-GPOS-00300 reads “The operating system must be a version supported by the vendor,” severity high, and its check text is as blunt as check text gets: if it is not a version supported by the vendor, this is a finding. On the application side, V-222659 in the Application Security and Development STIG reads “The application must be decommissioned when maintenance or support is no longer available,” also severity high, and its check asks whether every component is covered by a maintenance contract.

One retired component therefore produces a CAT I STIG finding and an SA-22 control gap pointing at the same box: two rows in two systems that have to tell the same story with the same end date.

What Actually Counts as Vendor Support

Assessors are not asking whether you have a relationship with the vendor. They are asking whether something will produce a fix for the specific version you are running. Use the Rev 5 list as the test:

• Security patches for the exact version and build in your inventory, not for the product family.
• Firmware updates for the hardware underneath it, which is the item people forget on appliances.
• Replacement parts, where the component is physical and a failure means a hunt on the secondary market.
• A maintenance contract with a named term, a named scope and an expiration date.
• A support channel that will accept a case and work it, rather than reply that the version is retired.

What does not count: a reseller’s assurance that they “still support it,” a community repository with no contractual obligation to you, an integrator’s verbal promise with nothing in the contract line, and a patch somebody backported with no test evidence. That last one is interesting, because in-house support is explicitly allowed under part b. It just means you inherited the vendor’s job, including the SI-2 obligation to test updates for effectiveness and side effects before installation. Claim it and be ready to show the test records.

Extended Support Contracts Are the Strongest Artifact You Can Buy

Vendors sell the exact thing part b asks for, and the paperwork is self-documenting. Windows 10 reached end of support on 14 October 2025. Microsoft’s commercial Extended Security Updates program covers version 22H2 devices for a maximum of three years, Year One beginning November 2025, priced at 61 dollars per device for Year One under volume licensing and doubling each consecutive year. Read the scope before you cite it as mitigation: ESU delivers Critical and Important security updates under Microsoft Security Response Center severity ratings and nothing else. No new features, no customer-requested non-security fixes, no design change requests, no general technical support beyond activation and installation.

Red Hat draws a line that trips up write-ups constantly. The Extended Life Phase of a Red Hat Enterprise Linux release provides access to previously released content and limited technical support, and explicitly no bug fixes, no security fixes and no hardware enablement. Extended Life Cycle Support is a separate paid add-on that keeps delivering errata under the standard criteria for the last minor release, where security errata cover Critical and Important issues plus Moderate ones at CVSS 7 or above. Two phases that sound alike and mean opposite things.

An extended support contract is the one artifact in this exercise nobody argues with, because it has a dollar figure and an expiration date on it and neither of those has an opinion. Put the contract number, the covered versions, the covered severity levels and the coverage end date into the control implementation statement, then set a reminder ninety days out, because coverage that lapses quietly turns a compliant control back into a CAT I with nobody touching the system.

Where SA-22 Meets SI-2 and RA-5

This is why an unsupported component feels like three findings: it is three findings. RA-5 requires you to remediate legitimate vulnerabilities within organization-defined response times and in accordance with an organizational assessment of risk. Your scanner will keep producing those vulnerabilities forever, and the normal remediation path does not exist.

SI-2 requires identifying, reporting and correcting system flaws, testing updates before installation, installing security-relevant software and firmware updates within an organization-defined time period of their release, and folding flaw remediation into configuration management. When there is no update to install, SI-2 does not quietly become satisfied. It becomes blocked, and the blocker is SA-22. The patch timeline mechanics are in the piece on SI-2 flaw remediation and DoD patch timelines.

Treat them as one root cause with three symptoms. Tie the RA-5 and SI-2 entries back to the SA-22 entry, give all three the same scheduled completion date, and make that date the one the replacement actually lands on. Where the authorizing official has to carry residual risk in the meantime, the vehicle is a written determination rather than a comment field, and the shape of a memo an AO will sign is in the post on risk acceptance and how AOs decide. A compensating control case and a risk acceptance are different documents doing different jobs, and submitting one when the reviewer wanted the other costs two weeks.

Writing the Compensating Control Case So It Survives Review

A compensating control case is not an argument that the finding is unfair. It is a statement that the specific risk the control addresses is handled another way, with evidence. Seven elements, and reviewers notice when one is missing:

• The component and version named exactly, with the vendor’s own published end-of-support date cited as the source.
• Which SA-22 path you are on, replacement or alternative support, and why the other is not available this fiscal year.
• The isolation described in control language: segmentation, the allowed flows in and out, what can reach it and from where.
• The detection you added on top, stated as what would fire and who receives it.
• The vulnerability classes the compensating controls cover, and the ones they do not, written plainly.
• The funding line and the fiscal year the replacement sits in, because “pending funding” with no year is not a plan.
• The role that signs the determination, and the date they signed it.

Two failure modes account for nearly every rejected case I have seen. The first reads as a defense of the status quo, which an assessor hears as an argument that the control should not apply. The second claims isolation the network diagram does not support. An assessor can open the firewall rule set, and if the box you called air-gapped has an allowed flow to a jump host on a routed network, you have a credibility problem that outlasts the finding.

Why a POA&M With No End Date Fails Review

The required contents of a remediation plan are not a local preference, and they predate the tooling. OMB Memorandum M-02-01 laid out the columns in 2002 and they still shape every POA&M format in federal use: type of weakness, responsible office, resources required, scheduled completion date, milestones with completion dates, changes to those milestones, source of the weakness, and status. Two instructions deserve rereading. The scheduled completion date is the target date for resolving the weakness, and the guidance states that the initial date entered should not be changed. The resources required column wants a funding estimate, its source, and non-funding obstacles such as a lack of personnel or expertise.

So “replacement pending funding” has no scheduled completion date, which empties the one column that lets a reviewer hold anybody accountable. A reviewer bouncing it is not being difficult. They were handed a row that cannot be tracked.

What works instead is a date anchored to something real, with milestones attached to the budget cycle: requirement validated, funds identified, procurement submitted, hardware received, migration test complete, production cutover, legacy component disconnected. Each gets a date, and the last one is the scheduled completion date for the control. The wording reviewers accept is in the guide on how to write a POA&M, the milestone discipline that keeps those dates from sliding a quarter at a time is in the piece on writing milestones that do not slip, and because a budget-dependent replacement will outlast at least one assessment, the review cadence in the write-up on how ISSOs actually track and close findings is what keeps the entry honest in the meantime.

If you are staring at a retired component right now, the sequence is short: get the vendor’s published end-of-support date, decide this week whether you are replacing it or buying continued support, price the support option before the next budget call, and write the entry with a real date on it. If you want the tracking side already built, the POA&M Tracker carries the milestone and scheduled completion date fields in the structure reviewers expect, so the only thing left for you to supply is the decision.