03.16.02 Unsupported system components: NIST 800-171

What 03.16.02 unsupported system components requires in plain terms

03.16.02 requires you to replace any system component once its developer, vendor or manufacturer no longer supports it. Where a component cannot be replaced, you must provide options for mitigating its risk or for getting alternative sources of continued support. The requirement exists because software and hardware that no one patches keep their known flaws indefinitely, and a CUI environment that depends on them inherits that exposure. This is a new requirement in Rev. 3 with no Rev. 2 equivalent, and its source control is SA-22 from SP 800-53 Rev. 5. If a contract or assessment now asks about end-of-life systems that touch CUI, expect the question to be answered with dated evidence, not with a general statement that patching happens.

The difficulty is rarely the replacement itself. Most organizations struggle first because they have no complete inventory of what touches CUI, so an end-of-life server or application can sit outside every review. Ownership is often unclear too: the systems team may run a server, the business unit may own the application, and no one is assigned to watch vendor end-of-support dates. Before you plan any replacement, confirm that your asset records cover every component in the CUI boundary, including network equipment, appliances and software on endpoints, and that each item has a named owner and a recorded support end date.

Once that list exists, sort each unsupported component into one of two paths. Components that can be replaced go on a funded plan with a target date and a named approver. Components that cannot be replaced, such as a vendor-locked device or an application with no successor, need a documented risk decision: compensating controls, isolation, restricted access, enhanced monitoring, or a third-party support contract. Ask your assessor which evidence they expect for each path, because the requirement's assessment procedure looks for procedures, documented replacement or continued-use decisions, and records showing the work was done.

Which systems and parties 03.16.02 reaches in a nonfederal environment

Requirement 03.16.02 applies to any component that touches CUI or protects the systems that do, so scoping starts with an inventory of what is in the boundary. The cards below cover the decisions that most often change the amount of replacement, mitigation and evidence work, and the points to settle with the federal agency before the scope is fixed.

Systems that handle or protect CUI

Start with every system that stores, processes or transmits CUI, plus the security tools that protect it, such as identity services, logging platforms, endpoint agents and backup systems. A security tool that has lost vendor support is still an unsupported component if it protects CUI, even when no CUI sits on it directly. Confirm the boundary with the system security plan and record which components sit inside it, so the replacement review covers the same set of systems the assessor will examine.

Hardware and firmware, not only software

Support ends for firmware and hardware as well as operating systems and applications. Routers, switches, firewalls, storage arrays, hypervisor hosts, BIOS and baseboard controllers, and printers or multifunction devices may stop receiving security updates while the software on top still looks current. Ask each manufacturer for its end-of-support dates for every model in the boundary, and include firmware versions in the component inventory.

Components supplied by third parties

Software embedded in vendor appliances, managed service platforms and licensed libraries often has a support lifecycle set by someone other than the organization. A vendor may end support for a product while the organization still depends on it through a contract. Review each external service agreement for support end dates and notice periods, and record which party is responsible for replacement. The related duties for external providers sit under 03.16.03, so the two requirements should be scoped together.

Legacy systems kept for business reasons

Some unsupported systems stay in service because a line-of-business application, a data format or a regulator-facing process depends on them. These are the components most likely to need documented risk mitigation rather than replacement. Record the business reason, the owner, the compensating controls such as network isolation or restricted access, and the date by which replacement will be reviewed. An assessor will ask who approved continued use and how it is monitored.

Agency scope and organization-defined values

NIST states that the federal agency holding the contract is responsible for how SP 800-171 applies, and Rev. 3 requirements carry organization-defined parameters whose values may be set by the agency or, if the agency does not set them, by the nonfederal organization. Before scoping 03.16.02, ask the contracting officer or agency security office which systems are in scope, what support lifecycle or replacement timeline applies, and which parameter values they expect. Write the answers into the scope document.

Inventory sources that feed the scope

A complete list of components is the input to every replacement decision. Asset management and inventory tools can record hardware, software and network devices, and agent-based tools can report installed software, services and open ports from each endpoint. Compare the inventory output with vendor lifecycle information and with the boundary diagram. Gaps between the three usually point to the components that will otherwise be missed at assessment time.

How an assessor tests 03.16.02 and what passes

This table breaks down how SP 800-171A Rev. 3 tests 03.16.02 across the examine, interview and test methods, along with the evidence an assessor will ask for. Use it to prepare the artifacts each method needs, since a single process that cannot be shown in records, staff answers and a working replacement cycle will not pass.

Assessment method	Assessment objects	Evidence an assessor will request	Where it usually fails
Examine	System and services acquisition policy and procedures; procedures for replacing or continuing use of unsupported components	Approved policy, documented replacement procedure, risk-acceptance rules for components that cannot be replaced	Policy exists but names no owner, trigger or review date, so it cannot be tested
Examine	Documented evidence of replacing unsupported system components	Dated records of retired or replaced items, change tickets, decommissioning records, updated asset entries	Replacement records are missing, or replaced items still appear in the inventory
Interview	Personnel with system and services acquisition responsibilities	Clear answers on how end-of-support dates are tracked and who approves exceptions	Acquisition staff are unaware that the procedure covers unsupported components
Interview	Personnel responsible for component replacement	Walk-through of a recent replacement or continued-use decision, from identification to closure	Engineers describe the intended process, but records show it was not followed
Test	Processes for replacing unsupported system components	Observed replacement or mitigation cycle run against a sample of end-of-support items	Process is never exercised, so the assessor cannot see it working on real components
Inventory check (illustrative)	Component list checked against vendor support end dates	Inventory showing support status and end-of-support date for each component, including network gear and appliances	Inventory omits end-of-life items such as embedded devices, firmware or older appliances
Risk mitigation (illustrative)	Continued-use decisions for components that cannot be replaced	Documented compensating controls, isolation settings, monitoring and an approved risk acceptance with an owner	Mitigations are described in general terms with no link to the specific unsupported component

Why 03.16.02 matters now: Rev. 3, CMMC and the 2026 DoD position

03.16.02 is one of the 19 requirements that NIST's change analysis lists as new in Rev. 3, and NIST maps no Rev. 2 requirement to it. That gap matters because CMMC Level 2 assesses the 110 Rev. 2 requirements, so it has no matching requirement ID for unsupported system components. An organization can therefore pass a CMMC-aligned review on every Rev. 2 control and still have no documented answer to the question this requirement asks: which systems in the CUI boundary have lost vendor support, and what replaces them or keeps them defensible. Treat the gap as a planning item, not as a reason to skip the work.

The current contract position is mixed and changes quickly. DoW Class Deviation 2026-O0025, Revision 3, signed 3 September 2026, has contracting officers use a revised DFARS 252.204-7012 that names SP 800-171 Revision 2 explicitly. It cites a 13 July 2026 DoW CIO memorandum requiring baseline compliance with Rev. 2 while CMMC Phase 2 is suspended. A FAR overhaul proposed rule published 23 June 2026 would instead require contractors handling CUI to comply with Rev. 3, using organization-defined parameter values published by the DoW CIO. That rule was not final as of October 2026. Confirm which version your contracts, task orders and subcontract flow-downs cite, and ask the contracting officer in writing if the wording is unclear.

Plan for Rev. 3 wording in the system security plan regardless of which version the current contract names. Record, for every system in scope, its vendor support end date, the owner of the replacement decision, and either the planned replacement or the documented risk mitigation or alternative support source. Ask your assessor and your contracting officer to confirm how they will test this requirement before your assessment, because the 2 determination statements in SP 800-171A Rev. 3 expect evidence of an actual replacement process, not only a policy statement.

How to implement 03.16.02 step by step

This sequence turns 03.16.02 into a working routine: know which components have lost support, assign each one an owner, decide what happens to it, and keep the records an assessor will ask to see.

Build a component inventory with support status
Start with a complete list of system components that handle or support CUI in scope: hardware, operating systems, firmware, applications and libraries. For each item, record the developer, vendor or manufacturer, the installed version and the end-of-support date published by that source. Endpoint and asset tools can populate much of this, and an inventory platform such as GLPI or a Wazuh Syscollector deployment can collect hardware, software and installed versions, but support dates usually come from vendor lifecycle pages and must be added by hand. The step is done when every in-scope component has a dated entry with a support status of supported, unsupported or approaching end of support, and the inventory is stored where the assessor can review it.
Assign a named owner to each component
Give every inventory entry one accountable owner, usually the system administrator, application owner or platform team lead who can approve a change or fund a replacement. Owners should be named by role and person, and each assignment should be recorded in the inventory. Where a component has no clear owner, treat that gap as a finding in its own right, because an unowned unsupported component will not be replaced or monitored. The step is done when no in-scope component lacks an owner and the assignments are signed off by the security or IT leadership responsible for the system security plan.
Write the replacement and continued-use procedure
Document the procedure that governs how the organization handles components once support ends. It should describe how support status is checked, who is notified when a component reaches end of support, how replacement is prioritized and funded, what risk mitigation options exist for components that cannot be replaced, and how alternative sources of support, such as a third-party maintainer, are evaluated and approved. The assessment procedure for 03.16.02 specifically looks for procedures covering both replacement and continued use, so both paths belong in one document. The step is done when the procedure is approved, version controlled and linked from the system security plan.
Decide the path for each unsupported component
For every component past its support date, record one of three outcomes: replace it, keep it under a documented risk mitigation, or continue it with an alternative source of support. Replacement is the default, and it should be planned against the system's change control process. Where replacement is not possible, the mitigation record should state the compensating measures, such as network isolation, restricted access, enhanced monitoring or removing the component from CUI handling, and the residual risk accepted by the owner. The step is done when each unsupported item has a decision and a target action, and no item is left in an undecided state.
Record each decision with a formal approval
Create a decision record for each unsupported component. It should include the component identifier, the support end date, the chosen path, the mitigation or alternative support details, the named owner, the approver and the date of approval. For risk acceptance, the approver should be someone with authority to accept the residual risk on behalf of the organization, not only the technical owner. These records are the documented evidence an assessor will examine for 03.16.02, so they should be kept with the inventory and the procedure. The step is done when every decision has an approved record that cross-references the inventory entry.
Run the procedure on a recurring schedule
Set a review cadence for the inventory, the owner assignments and the decision records, and rerun the support-status check whenever a component is added, upgraded or reaches a published end-of-support date. Vulnerability scanners such as Greenbone Community Edition or Fleet can help identify software that has fallen behind, though they do not confirm vendor support status on their own. Each cycle should update the inventory, close completed replacements and reopen decisions where a mitigation has expired or the residual risk has changed. The step is done when a dated log shows each review cycle, the changes it produced and the approvals behind them. Ask the assessor or compliance lead to confirm the review frequency that fits your system security plan.

Evidence that satisfies 03.16.02 and how to keep it current

An assessor testing 03.16.02 looks for a chain of records: a policy, an inventory, proof of replacement, and documented decisions for anything that stays in service. No single artifact carries the requirement, so each card below should be refreshed on a set schedule and tied to the others.

Acquisition policy and replacement procedure

The policy states that unsupported components are replaced or placed under alternative support, and the procedure says who decides, who approves, and how a component is tagged when its support ends. Assessors examine both documents and then interview the people named in them. Check that the owner roles still exist and that the procedure matches what staff actually do. Review it at least once a year and after any change to the asset management or change control process.

Component inventory with support status

The inventory lists each system component with its version, owner, and a support end date or status taken from the developer, vendor or manufacturer. Without that status column, nobody can show which components are unsupported. Pull the inventory from discovery tools where possible and reconcile it against procurement records. Refresh it on a recurring schedule and compare it against vendor end-of-support notices so new end-of-life announcements are caught before the date passes.

Replacement records and decommission evidence

For each component replaced, keep the change ticket, purchase order or license record, the installation or cutover record, and the decommission record showing the old component was removed from service or network. Assessors often sample these records to test whether the procedure was followed. Confirm that tickets link back to the inventory entry and that decommissioned hardware or software is recorded as retired, not simply dropped from a list.

Risk acceptance for components that cannot be replaced

Some systems, such as industrial controllers or legacy applications, cannot be replaced immediately. For each one, record the mitigation, such as network isolation, restricted access or enhanced monitoring, the residual risk, and a dated sign-off by an accountable owner. Set a review date for every acceptance and re-approve it when the date arrives or the threat picture changes. Assessors look for the sign-off date and evidence that the mitigation is in place.

Log of alternative support arrangements

When a component stays in use, record the alternative source of continued support, such as a third-party maintenance contract, an internal patching capability, or a vendor extended-support agreement. The log should name the provider, the scope of support, the contract or agreement reference, and the expiry or review date. Confirm each arrangement still covers the component's current version. Gaps in this log are a common reason an otherwise complete file fails review.

Recurring review cycle

Set a recurring review that brings the inventory, replacement records, risk acceptances and support log together and checks them against each other. The review should record its date, attendees, changes and open actions, so the file shows the requirement is operated continuously. Schedule it before each assessment and after major changes such as an acquisition or a new vendor end-of-support notice. Ask the assessor or your contracting officer which review interval they expect for your environment.

Which open-source tools produce 03.16.02 evidence

No single tool proves that unsupported components were replaced or that a continued-support decision was made. The tools below produce the inventory and vulnerability data an assessor can sample, which is the starting point for showing that unsupported components were found and then handled through a documented decision.

GLPI Assets inventory

GLPI's Assets module records computers, software, network equipment, peripherals and racks, entered by hand or pushed automatically by the GLPI Agent through native inventory available since version 10. For 03.16.02, the asset record is the anchor: it shows which operating systems and devices exist and where they sit. Confirm whether your GLPI configuration captures lifecycle or end-of-support fields, because the module's default records do not establish vendor support status on their own. Assessors will ask whether the register stays current.

Wazuh Syscollector inventory

Wazuh's Syscollector module collects hardware, operating system, installed software, services and Windows updates from each endpoint and stores them in the Wazuh indexer for dashboard views and reports. This gives an independent, agent-collected view that can be compared against the asset register. Use the reports to show which endpoints run operating system versions or software packages that the vendor no longer supports. Confirm with Wazuh how your version handles end-of-life detection before relying on it for that purpose.

Fleet vulnerable software

Fleet matches the software installed on enrolled hosts against vulnerability sources including the NVD, OVAL definitions, Microsoft security bulletins, Amazon Linux advisories and OSV. Its output helps identify components with known flaws that may also be out of support, especially where a vendor has stopped issuing fixes. A finding alone does not show unsupported status, so check whether the affected release still receives security updates and record the replacement, mitigation or continued-support decision for each one.

Greenbone Community Edition scans

Greenbone Community Edition runs the OpenVAS Scanner against target systems using tests from the daily updated Greenbone Community Feed, controlled through gvmd. Its scan reports can show network-reachable services and software versions that are no longer maintained, which complements agent-based inventory. Scan coverage depends on the target list and credentials you provide, so confirm that scans reach the systems in your CUI boundary. Keep scan results tied to the decisions that followed them.

What meeting 03.16.02 costs in money and effort

This table breaks down the cost components of meeting 03.16.02 Unsupported system components, showing who gets paid, whether each cost is one-time or recurring, and what pushes it up or down. No price or duration figures are supplied for this requirement, so use the table to structure your own inventory and vendor quotes rather than as a benchmark.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it up or down
Inventory of components and support end dates	Internal staff, or a partner preparing the asset register	One-time build, then recurring upkeep	Number of components, how many sources of truth exist, and whether discovery is automated
Tooling and licenses	Vendors for commercial tools; none for open-source tools	Recurring for commercial licenses; hosting and administration recur for self-hosted tools	Commercial versus open-source choice, host sizing, and the staff time needed to run the tools
Engineering time to maintain support status tracking	Internal platform or IT engineers	Recurring	Frequency of vendor lifecycle changes and how support dates are sourced and verified
Replacement program: hardware and software purchases	Hardware and software vendors, resellers	One-time per replacement cycle	Count of unsupported components, vendor pricing, and whether replacements need new licensing
Migration and cutover effort	Internal teams, system owners, or an implementation partner under a fixed-scope agreement	One-time per system	Application dependencies, testing needs, downtime windows, and CUI handling during migration
Risk mitigation or alternative support for components that cannot be replaced	Third-party support providers, or internal teams applying compensating controls	Often recurring for support contracts; compensating controls may be one-time plus upkeep	Vendor support terms, system criticality, network isolation options, and how long replacement is delayed
Evidence upkeep and assessor preparation	Internal compliance staff, with optional outside help	Recurring	Number of systems in scope, how often records change, and whether evidence is generated automatically
External testing or independent review	Independent assessors or testing firms	Recurring at each assessment cycle	Scope of the assessment, number of systems, and sampling depth chosen by the assessor

Who does what for 03.16.02: your team, a partner and the auditor

Your organization owns requirement 03.16.02. Under the NIST framework, the system owner and the people accountable for acquisitions decide which components are unsupported, whether each one is replaced, and which mitigation applies to any component that cannot be replaced. Those decisions carry business and risk consequences, so they cannot be delegated to a vendor or an advisor. Your team also owns the system security plan, which describes how the requirement is met, and any risk acceptance that records why an unsupported component remains in service.

Replacement decisions: Approve the replacement schedule, budget and business justification for each unsupported component.
Risk acceptances: Sign off on residual risk for components that stay in service, with a named owner and review date.
System security plan: Describe the requirement, the procedure and the responsible roles in the plan your assessor will read.
Acquisition process: Check support end dates before purchasing software, hardware or firmware, and record them in procurement.
Procedures and training: Maintain the policy and procedures that staff follow when a support end date arrives.

Before engaging any partner or assessor, confirm internally who signs the replacement and risk acceptance records, because those names are the first thing an assessor will ask for.

Questions buyers ask about 03.16.02 before hiring help

How much effort does an unsupported component inventory and replacement program take?

The effort depends on how many components are in scope, how well the asset inventory already reflects reality, and how many of those components the vendor no longer supports. Most of the work sits in building an accurate list of hardware, operating systems, firmware and software, then matching each item to its vendor end-of-support date and its dependencies. Replacement is often the larger cost, because a retired operating system can break applications, integrations and maintenance tooling. Ask any partner for a written breakdown that separates discovery, lifecycle mapping, replacement planning and documentation, and state which of those you expect to do internally.

How long does a 03.16.02 program take, and what sets the timeline?

The timeline is set less by the requirement itself than by the state of your asset data and your change windows. Four drivers matter most: how current the inventory is, how many unsupported components depend on each other, whether replacement needs budget approval or procurement, and how much testing a production system needs before cutover. Programs with a reliable inventory can move directly to lifecycle decisions, while those starting from spreadsheets spend more time on discovery. Any timeline should come from a written scope that names the systems covered, and it should include the time for your assessor to review evidence.

What does the work need from our internal team?

Your team owns the decisions and the evidence, so it needs to be involved throughout. System owners must confirm which components they run and what depends on them. Procurement and finance must approve replacements or extended support contracts. Security must agree on how risk is handled for components that stay in service, and someone must own the documented procedure. Engineering staff must test replacements and sign off on cutover. A partner can prepare inventory data, lifecycle records and draft procedures, but the organization must approve them and keep them current.

Can a small team run 03.16.02 without outside help?

A small team can often complete the work alone if it has a reliable inventory, a short list of systems, and clear authority to retire or replace them. The harder cases are environments with many legacy systems, unclear ownership, or a contract that requires evidence in a specific format. Ask yourself whether someone can maintain the inventory, track vendor support dates and keep replacement records after the first pass. If that ongoing load is not realistic, outside help can focus on the initial build, with the recurring work kept in-house or under a support agreement.

Can we meet 03.16.02 if some unsupported components cannot be replaced?

Yes, the requirement allows for components that cannot be replaced, but it expects you to provide options for risk mitigation or alternative sources of continued support. In practice that means documenting each exception, the reason replacement is not possible, the compensating controls such as network isolation, restricted access and enhanced monitoring, and the alternative support route, such as a third-party maintenance provider or internal patch capability. Each exception needs an owner and a review date. Confirm with your contracting officer or assessor how they expect those exceptions to be recorded before you rely on them.

What evidence will an assessor ask for first?

Assessors start with the documented policy and procedures for acquiring, replacing or continuing use of unsupported components, then ask for records showing the procedure was followed. The most useful first artifacts are a current inventory of system components with support status and end-of-support dates, a list of replacement decisions with completion records, and documented risk mitigation for every component that remains in service. Assessors also interview the people who own acquisition and component replacement, so those people should be able to explain the process and show their records.

Can a partner sign off that we meet 03.16.02?

No. A partner can prepare systems, inventory records, replacement plans and documentation, but it cannot certify or attest that you meet the requirement. Only an independent assessor, such as an assessor recognized under the applicable program, can evaluate compliance and issue the report or result that a contract accepts. Your organization owns its controls and its statements about them. When you select a partner, ask for a written statement of what it will deliver and confirm with your assessor and contracting officer which evidence they will accept.

How DeployOpen scopes and prepares 03.16.02 evidence

DeployOpen helps organizations prepare the inventory, replacement records and risk mitigation evidence that 03.16.02 Unsupported system components asks for. The organization owns its requirement and its decisions, DeployOpen prepares the systems and documentation, and an independent assessor reaches any conclusion about compliance.

How we scope

The written scope lists which systems, components and asset sources are included for 03.16.02 Unsupported system components.
We confirm with your team which vendor support end dates and extended support records exist for in-scope components.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.

How we build

We configure inventory tooling such as GLPI, Wazuh Syscollector or Fleet so support status can be tracked per component.
We set up vulnerability visibility with Greenbone Community Edition to show which unsupported software is exposed.
We help define the replacement or continued-use procedure the organization will follow when a component reaches end of support.

How we hand over

We deliver the inventory exports, procedure documents and risk mitigation records mapped to the two 03.16.02 determination statements.
We document the roles of personnel with system and services acquisition and component replacement responsibilities.
Only an independent assessor or certification body issues assessment reports or certificates, so we hand over evidence for their review.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
A retainer can keep component support status current as vendor lifecycles change and new systems enter scope.
We confirm with you before any change to documented replacement or mitigation decisions, since those remain the organization's own.

03.16.02 Unsupported system components