SA-22 Unsupported system components: what it requires

What SA-22 unsupported system components requires in plain terms

Your inventory shows end-of-life hardware, software or firmware still running in production, and SA-22 asks what happens next. The control gives the organization two permitted paths: replace the component once support is no longer available from its developer, vendor or manufacturer, or put in place defined alternative sources of continued support, such as in-house engineering that can produce patches and fixes. Either path must be deliberate and recorded. Leaving a component running simply because nobody has looked at it does not satisfy the control. The reason this matters is practical: a component that no longer receives vendor security updates keeps its known flaws indefinitely, and attackers rely on exactly that gap.

The control is hard to meet for reasons that have little to do with policy. Most organizations cannot say with confidence which components are out of support, because the asset register is incomplete, business units buy software outside procurement, and embedded firmware in network gear, controllers, printers and appliances is rarely tracked at all. Start by reconciling your asset data against vendor end-of-life announcements for each hardware model, operating system, library and firmware version. Where the inventory is weak, a tool that collects installed software and hardware from each endpoint, such as the open-source GLPI Assets module or the Wazuh Syscollector module, can give you a starting list to check against vendor lifecycle dates.

SA-22 applies at the Low, Moderate and High baselines in SP 800-53B, so a system at any impact level must handle unsupported components. The control also carries an enhancement that is withdrawn in Release 5.2.0, so assessors will work from the base control text. Assessors will look for documented evidence of replacement and, for components kept in service, documented approvals that include a justification. The organization owns this decision. A reasoned risk acceptance signed by the accountable owner, with compensating controls, a review date and a retirement plan, is what an assessor can test. Confirm with your assessor which compensating controls they expect for each retained component.

Which components and teams SA-22 covers in your environment

SA-22 reaches further than the servers in a data center. It applies to any system component whose support has ended or may end, including software, firmware, network gear and services that a provider runs for you. The cards below name the scoping decisions that change the work and the teams that have to agree on them before an assessor asks.

Operating systems and applications past support

Start with the software inventory: operating systems, middleware, databases and business applications whose developer has announced end of support or stopped issuing security fixes. For each item, record the vendor's published end-of-support date and whether a paid extended support contract exists. Platform engineering owns the inventory, while application owners decide whether to upgrade, replace or accept the risk. Confirm the vendor's support lifecycle policy in writing, because that policy, not internal assumptions, is what the assessor will compare against.

Network and industrial hardware

Switches, routers, firewalls, industrial controllers and building systems often run firmware that the manufacturer no longer patches, and they are easy to forget because they sit outside the server estate. Network engineering and operations teams should own their lifecycle records, including model, firmware version and end-of-support status. Check whether an operational technology team manages any of these devices, since replacing them may require a plant outage window and a formal change request.

Firmware on appliances and embedded devices

Appliances such as storage arrays, backup devices, hypervisor hosts and badge readers carry firmware that is separate from the operating system and frequently missed in software inventories. Hardware asset management and the vendors' support contracts define what can be patched and by whom. Decide whether a firmware release that the manufacturer has stopped maintaining counts as an unsupported component, and document that decision with the same rigor as a discontinued operating system.

Extended and alternative support arrangements

A decision to pay for extended vendor support, or to use a third-party maintainer or an in-house team, is an alternative source of continued support under the control. Procurement should confirm the scope, duration and what the contract actually covers, such as security patches, not only break-fix tickets. Legal and procurement review the contract terms, and the security team confirms that the support source can deliver fixes within the timelines the organization has set.

Cloud-managed and third-party services

Where a provider runs the platform, support for the underlying components sits with that provider, not with your team. Vendor management should collect each provider's documented support and deprecation policy and check whether it commits to replacing components before they become unsupported. Record these dependencies in the SA-9 external services inventory so that the SA-22 evidence and the supplier oversight evidence point to the same records.

Risk decisions and documented approvals

When a component cannot be replaced yet, the control expects a documented approval that includes justification for continued use. Assign risk owners who can accept the residual risk, and require that each approval states compensating measures, a review date and the condition for retirement. Governance teams should confirm who signs these decisions. Baselines matter here: SA-22 applies at the low, moderate and high impact levels, and FedRAMP's Rev5 baselines require it at Classes B, C and D, so the same process must satisfy each applicable baseline your system is authorized under.

How an assessor tests the SA-22 unsupported components control

This table shows how an SP 800-53A assessor tests SA-22 through its two determination statements, the examine, interview and test methods, the evidence requested and the findings that commonly appear. Read it as a checklist of what must exist on paper and in the environment before an assessment begins.

Test element	What the assessor requests	Common findings
Determination statement 1: replacement of unsupported components	Documented evidence that unsupported system components were replaced when developer, vendor or manufacturer support ended, or that defined alternative support was arranged	Replacement records missing for components already past end of support; no link between a support-end date and a retirement ticket
Determination statement 2: approval for continued use	Documented approvals for continued use of unsupported components, including the justification and the approving authority	Approvals absent, approved without a stated justification, or signed by someone without authority to accept the risk
Examine method	Asset inventory, vendor support matrices, change tickets, risk acceptance records and the approval documents themselves	Inventory lacks firmware and embedded components, so end-of-life items never reach the review list
Interview method	Owners of the systems, procurement staff and the people who maintain the support contracts, asked how end-of-support dates are learned and acted on	Staff describe a process that is not written down, or name a vendor contact who has left the organization
Test method	Sampling of listed components against vendor lifecycle pages or contract records, and checking that support status matches what the organization recorded	Vendor support has expired on a sampled device or package, but the record still shows it as supported
Compensating controls in approvals	Evidence that each approved exception names the compensating controls and who reviews them over time	Approvals accepted without a stated compensating control or a review date
Expired support not noticed	Dated records showing when the organization learned of each end-of-support notice and what it did next	No monitoring of vendor notices, so exceptions are discovered only at audit time

How to implement SA-22 from inventory to documented decision

This sequence takes an organization from an unknown set of aging components to a documented position on each one: replaced, covered by an alternative source of support, or kept under a signed risk decision that is reviewed on a schedule. Each step leaves an artifact an assessor can examine.

Build a complete component inventory
Start by listing every system component in scope, including hardware, operating systems, installed software, firmware, network devices and embedded appliances. Platform or infrastructure teams usually own this, with input from application owners who know about libraries and services they run. Native discovery is a good starting point: GLPI's Assets module can hold computers, network equipment and other devices entered manually or pushed by the GLPI Agent, and Wazuh's Syscollector collects hardware, operating system, software, services and open ports from endpoints. Firmware often needs a separate, manual pass. The output is an inventory extract with a unique identifier, owner, version and location for each item, and a check that it covers the system boundary in your system security plan.
Map each item to its support end date
For each inventory entry, record the end-of-support or end-of-life date published by the developer, vendor or manufacturer, along with any extended or paid support option and whether internal staff or a third party can provide support instead. Confirm dates against the vendor's own lifecycle documentation rather than secondary lists, and note the source and retrieval date. Where a component has no published date, record that as an open question for the vendor. Dependency-Track can help for software: it consumes CycloneDX SBOMs and flags outdated components, and Trivy can generate an SBOM from a target that you can feed into it. The output is a lifecycle register that links each inventory item to a support status source.
Classify each item by support status
Sort every item into one of three groups: supported by the developer, vendor or manufacturer; supported by a defined alternative source, such as in-house engineering or a contracted third party with written terms; or unsupported. The classification should be made by the owner of the component and reviewed by the security function, so that a component is not marked supported only because a contract exists on paper. Unsupported items are the ones that move into steps four and five. The output is a classified register that shows the count and owner for each group and the basis for each decision.
Plan replacement or alternative support
For each unsupported item, decide whether to replace it, move the function to a supported platform, or arrange alternative support. Replacement plans should name the target component, the dependency and data migration steps, the owner, and the cutover approach. Where alternative support is chosen, the plan should describe the scope of that support, the people or contract that provide it, and how patches or vulnerability fixes will reach the component. Cost drivers include the replacement hardware or licences, migration effort, testing, and any vendor charges for extended support. Ask for written quotes that separate one-time and recurring costs. The output is a replacement or support plan for each item, approved by the system owner.
Record the risk decision for anything retained
Where an unsupported component must stay in service for a period, document an approval that includes the business justification, the compensating controls such as network isolation, restricted access and enhanced monitoring, the residual risk, and the accountable approver. The SA-22 assessment procedure looks for documented approvals with justification for continued use, so the record should be specific to the component and signed by someone with authority over the risk. Avoid blanket exceptions that cover a product family. The output is a signed exception record for each retained item, stored with the plan of action and milestones where the risk is tracked.
Set a recurring review of the register
Schedule a recurring review of the lifecycle register, the replacement plans and the signed exceptions, and set a trigger for ad hoc review when a vendor announces an end-of-support date. Review should confirm that inventory discovery still matches reality, that vendor dates have not changed, that replacements are on track, and that each exception is still justified. Retired items should be removed from the inventory with evidence of decommissioning. The frequency should be set in your own policy, because no review interval is set by the standard. The output is dated review minutes and an updated register, which together show that the SA-22 requirement is operating and not a one-time exercise.

Documenting the risk decision when a component stays in service

When an unsupported component has to stay in production, the organization must record a continued-use decision that an assessor can read and test. Under SA-22, the approval is the organization's own decision, made by an accountable owner who understands what is at stake. An assessor does not decide whether the component may stay. The assessor checks that the decision exists, that it is documented, and that the reasoning holds up. SP 800-53A Release 5.2.0 looks for documented approvals, including justification, for the continued use of unsupported system components, so the record itself is the evidence.

A usable record names the specific component by hostname or asset ID, the software or firmware version, and the vendor or community that no longer supports it. It states why replacement is not possible yet, such as a dependent application that has not been certified on a newer release or a hardware platform with no supported successor in the environment. The justification should explain why the risk is acceptable for now. The record also lists the compensating controls in place, such as network segmentation, restricted administrative access, additional logging or virtual patching, and the named owner who approved the exception. Each entry needs a review date and an expected end date for the exception. Ask your team to confirm these fields against the asset inventory so the record and the inventory agree.

An approved exception does not replace replacement planning. Each exception should link to a dated plan that moves the component to a supported version, a replacement, or an alternative source of support, and the review date should force a fresh look at whether that plan is still on track. Where the exception expires without a replacement, the decision lapses and must be re-approved or escalated. Keep these records in the same system as your inventory and plan of action entries, so assessors can trace each component from discovery to decision to closure. Inventory tooling such as GLPI or Wazuh Syscollector can help surface the components that need a record, but the decision itself remains with the organization.

Evidence that satisfies SA-22 and how to keep it current

An assessor testing SA-22 looks for proof that unsupported components are known, replaced or covered by a support arrangement, and that any continued use was approved with a reason. The cards below cover the artifacts that prove this and a routine for keeping each one current between assessments.

Component inventory with support end dates

This is the starting point for SA-22. The inventory lists each hardware, software and firmware component with its owner, version and the date the developer, vendor or manufacturer stops support. Assessors compare it against the system boundary, so gaps here undermine every other artifact. Keep it current by refreshing it from automated discovery on a fixed schedule and flagging any component whose support end date falls inside the next review cycle. Tools such as GLPI and Wazuh Syscollector can supply the raw inventory, but support dates usually need a manual or vendor-sourced field.

Replacement and migration records

When a component reaches end of support and is replaced, the record should show the original component, the replacement, the dates of cutover and decommissioning, and who verified the change. Assessors use these records to confirm the organization replaced components as its own process says it would. Link each record to the change ticket and the updated inventory entry. Review open migration projects at each cycle so that a planned replacement does not quietly slip past its support end date.

Vendor and extended support agreements

Where a component stays in use past its support end date, a vendor or third-party extended support contract, or a defined in-house support arrangement, is the evidence that continued support exists. The agreement should name the component, the coverage period and the scope of patches or fixes provided. Check the expiry date of each agreement against the inventory and renew before coverage lapses. Confirm with the vendor exactly what extended support includes, because some contracts cover only defined vulnerability fixes.

Signed continued-use approvals with justification

SA-22 expects documented approvals for any unsupported component that remains in service. Each approval should state the component, the business or mission reason it cannot be replaced yet, the compensating controls in place, the approver and the expiry date. Assessors examine these approvals directly, so an approval without a reason or an end date is weak evidence. Schedule a review before each expiry date and record either renewal with fresh justification or retirement of the component.

Review log of exceptions

A review log records each periodic check of the inventory and the exception list: what was reviewed, which components changed status, which approvals were renewed or closed, and who signed off. It shows that the organization looks at unsupported components on a defined cadence rather than only when an auditor asks. Keep the log append-only and tie each entry to the date of the review. Gaps in the log between cycles are a common finding.

Exception links to the SSP and POA&M

Every approved exception should appear in the system security and privacy plan, where the control implementation describes how SA-22 is met, and in the plan of action and milestones when a replacement is not yet complete. This linkage lets an assessor trace a component from the inventory to the approval and to the remediation milestone. Confirm that the plan of action and milestones carries the same expiry dates as the approvals, and that closed items are updated in both documents at the same time.

Open-source tools that build the SA-22 inventory and vulnerability evidence

SA-22 starts with knowing which components are in use and which of them have lost vendor support. The four tools below cover different parts of that picture: an asset register, endpoint inventory, software bill of materials analysis and container or package scanning.

GLPI asset register

GLPI's Assets module records computers, monitors, software, network equipment, peripherals, printers, phones and racks. Entries can be typed in by hand or pushed automatically by the GLPI Agent, which is built into GLPI from version 10. For SA-22, the register is where each component gets an owner, a lifecycle status and a vendor support end date. Confirm that your team will maintain those date fields, since the tool does not supply end-of-life dates on its own. Check how the agent handles network devices and firmware versions in your environment before relying on it as the system of record.

Wazuh endpoint inventory

The Wazuh Syscollector module collects hardware, operating system, installed software, network interfaces, open ports, running processes, services, users, groups and Windows updates from each endpoint. It stores this data in the Wazuh indexer and shows it in dashboard inventory views and reports. For SA-22, this shows which operating systems and packages are actually running, which often differs from the asset register. Compare Syscollector output against your register each review cycle, and confirm coverage for any Linux distributions, appliances or embedded devices you operate, since agent support varies by platform.

Dependency-Track component risk

OWASP Dependency-Track consumes and produces CycloneDX SBOMs and VEX documents. It identifies components with known vulnerabilities, outdated or modified components and license risk, and tracks license use by SPDX license ID. For SA-22, the outdated-component findings are the closest fit to unsupported software in application stacks, because a library past its maintained line appears as a risk that needs a decision. Note that the tool flags version age and known issues, not vendor end-of-life announcements, so you still need to record the support status of each flagged component yourself.

Trivy package and SBOM scanning

Trivy identifies the OS packages and software dependencies in a target, such as a container image, filesystem or repository. It can export those findings as a software bill of materials and can also scan an existing SBOM. For SA-22, Trivy helps build the component list for container images and build artifacts, where unsupported base images and packages often hide. Confirm that the base image tags you run still receive vendor security updates, because a scanner shows what is installed, not whether the upstream maintainer still supports it.

What meeting SA-22 costs in money and effort

This table breaks down the cost components of meeting SA-22 by who is paid, whether each cost is one-time or recurring, what drives it up, and how to keep it down. Read it as a checklist for building a quote, since no price or duration is supplied for these components. The main takeaway is that the recurring costs of inventory and risk decisions usually outweigh the one-time cost of a single replacement.

Cost component	One-time or recurring, and who is paid	What drives it up and how to keep it down
Inventory build and maintenance	Mostly recurring. Staff time, plus the platform if an implementation partner configures discovery tools	Up with fleet size and firmware diversity. Down with automated discovery such as GLPI Agent or Wazuh Syscollector feeding one inventory
Lifecycle and vendor support research	Recurring. Internal staff or consultant time to check developer end-of-support dates	Up with the number of vendors and undocumented firmware. Down with a maintained lifecycle field in the inventory
Replacement or migration engineering	One-time per component, usually larger. Internal engineers or the implementation partner, plus hardware or subscription purchases	Up with tight coupling to legacy systems and missing test environments. Down by retiring components instead of extending them
Extended or alternative support contracts	Recurring. Paid to the vendor, a third-party support provider, or in-house support staff	Up with the number of unsupported items kept in service. Down by replacing the items that drive most of the contract cost first
Inventory tooling licenses	Recurring where commercial. Vendor license fees for commercial asset or inventory products	Open-source tools such as GLPI, Wazuh and Dependency-Track remove license spend but not operating effort, hosting or staff time to run them. Confirm each product's license terms before deployment
Risk decision and documentation time	Recurring. Staff time from system owners, security and risk owners to justify and approve each continued use	Up with the number of exceptions and reviews. Down with a standard exception template and a fixed review cycle tied to the plan of action and milestones
Auditor sampling effort	Recurring per assessment. Paid to the independent assessor, plus staff time to produce samples	Up with unclear inventory and missing approval records. Down by keeping replacement evidence and approvals in one indexed location ready for sampling

Who owns SA-22 and what an implementation partner or auditor can do

Your organization owns SA-22. Someone accountable must decide which components have lost support, whether to replace them or arrange alternative support, and whether any remaining unsupported component may stay in service. Those decisions, and the records behind them, cannot be delegated to a vendor or a consultant. The decision holder is usually the system owner working with security and the risk function, and the approval must be traceable to a named person with the authority to accept the risk.

Component inventory ownership: Your staff decide which asset sources are authoritative and who reviews the list for end-of-life status.
Replacement decisions: Your system owners choose between replacement, a contracted extended support arrangement or in-house support, and record the reason.
Risk acceptance: A named risk owner approves each continued use of an unsupported component, with justification and an expiry or review date.
Continued-use records: Your team keeps the approvals, justifications and follow-up tickets that show the decision was made and revisited.
Vendor and manufacturer contact: Your procurement and engineering staff confirm support end dates in writing from each vendor or manufacturer.

Before any engagement, confirm that these roles have named people and that the risk acceptance authority is documented in your governance records.

Questions buyers ask about SA-22 unsupported components

Can we meet SA-22 without buying a new tool?

Yes, in principle. SA-22 asks for evidence that unsupported components are replaced or that a defined alternative source of support exists, and it does not name a product. Many organizations start with the inventory they already have, such as a configuration management database, a spreadsheet exported from procurement, or hypervisor and endpoint records. The gap is usually not the tool but the data: whether each asset has a vendor, a model, a version and a published end-of-support date. Open-source options such as GLPI can hold that register, and Wazuh can collect operating system and software details from endpoints. Confirm with your assessor which records they will accept as the authoritative inventory before you choose what to build.

How long does an unsupported component inventory and replacement program take?

The duration depends on the drivers, not on a fixed figure. The main ones are how many asset classes are in scope (servers, network devices, firmware, embedded systems and application runtimes all count), whether an accurate inventory already exists, how many systems depend on each unsupported item, and how long procurement and change windows take in your environment. Organizations with clean inventories and few legacy dependencies move faster. Those with undocumented firmware or applications tied to retired platforms usually need analysis before replacement can be scheduled. Ask any partner for a written scope and a timeline that separates inventory, risk decisions and replacement work.

What does the work require from our own team?

Your team owns the decisions and the operational knowledge, even when an implementation partner prepares the systems and evidence. Expect to provide system owners who can confirm what each asset does, change approvers who can schedule outages, procurement contacts who know contract and renewal dates, and an accountable risk owner who signs each decision to keep an unsupported component. An implementation partner can build the inventory, collect the version and support data, draft the decision records and configure monitoring. It cannot decide that a business process may run on a retired platform. Plan that owner time before the engagement starts, because it is often the constraint.

Does extended vendor support satisfy SA-22?

It can, if the extended support is a real, documented source of continued support for the specific component. SA-22 allows an organization to rely on defined alternative sources of support, such as in-house support or a third party, provided the arrangement is documented. A contract for extended security updates should state what it covers, which versions, what response it commits to, and when it ends. Treat it as a time-limited risk position with an end date, not as permanent compliance. Check the terms with your contract owner and your assessor, because a purchase order alone does not show that support continues through the period you need.

What will an assessor sample when testing SA-22?

An assessor tests the two determination statements in SP 800-53A for SA-22 by examining documented evidence. Expect requests for the inventory of components and their support status, records showing replacement of unsupported components, and documented approvals with justification for any component still in use. The assessor will usually choose a sample of components, including ones that are not on the replacement list, and trace each back to its record, owner, decision and current state. Interviews with system owners will test whether the approvals match what runs in production. Keep the inventory, the decision log and the change tickets linked so a single asset can be traced end to end.

Can a partner sign off on our unsupported component decisions?

No. A partner can prepare the inventory, the evidence and a draft of each decision record, but the organization must approve every risk acceptance, and only an independent assessor can report on whether SA-22 is met. Signing a decision on the organization's behalf would also remove the accountability that the control is designed to create. What a good partner provides is a clear record that shows who decided, when, on what evidence and with what compensating measures, such as segmentation or enhanced monitoring. Ask for that structure in writing before the work begins, and confirm the final approval path with your governance team.

How DeployOpen scopes and prepares SA-22 evidence

DeployOpen works on SA-22 as an implementation partner: it helps identify unsupported components in your self-hosted open-source environment, prepares the replacement or support evidence, and documents the risk decisions. Your organization owns the control and its decisions, and an independent assessor tests them.

How we scope

The written scope lists which systems, hardware, firmware and software inventories are in and out for SA-22.
It names who approves support alternatives and risk acceptances on your side.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

We configure inventory tools to record operating system, software and firmware versions against vendor end-of-life data you supply.
We build a SBOM-based component register using CycloneDX output and flag components that lack vendor or in-house support.
We set up a documented workflow that routes each unsupported component to replacement, alternative support or a recorded risk decision.

How we hand over

You receive the inventory configuration, the unsupported component register and the replacement or support plan.
Each risk decision arrives as a documented approval with justification, ready for examination by your assessor.
Your team receives written runbooks so the evidence can be refreshed without DeployOpen involvement.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
A retainer can keep the component register current as vendors publish new end-of-life dates.
Confirm with DeployOpen in the quote which support tasks are included and how often they recur.

SA-22 Unsupported system components