Unsupported System Components is a net-new requirement in R3 that addresses end-of-life technology, which is one of the most common findings in any real environment. It is part of the System and Services Acquisition (03.16) family. Unsupported System Components (03.16.02) has two (2) parts: replace system components when support is no longer available from the developer, vendor, or manufacturer, and provide options for risk mitigation or alternative sources of continued support for unsupported components that cannot be replaced. Per the NIST discussion, support for system components includes software patches, firmware updates, replacement parts, and maintenance contracts, and an example of unsupported components is when vendors no longer provide critical software patches or product updates, which can result in opportunities for adversaries to exploit weaknesses.
A common difficulty with this requirement is running end-of-life operating systems, appliances, or machine controllers and having no documented plan for them. This requirement is new for R3, and it gives you two acceptable paths: replace the component, or if you cannot, document mitigation options or an alternative support source. What is not acceptable is an unsupported component with no decision recorded against it. Per the NIST discussion, exceptions to replacing unsupported components include systems that provide critical mission or business capabilities when newer technologies are unavailable or when the systems are so isolated that installing replacement components is not an option.
Where things stand for companies facing the transition from NIST 800-171 R2 to R3:
The following is reproduced verbatim from NIST 800-171 R3, requirement 03.16.02 Unsupported System Components. Only the formatting has been adjusted for readability. This requirement has two (2) lettered parts:
The source control is SA-22 from NIST 800-53. There are no Organization-Defined Parameters (ODPs). Per the NIST discussion, organizations can establish in-house support by developing customized patches for critical software components or obtain the services of external service providers who provide ongoing support for unsupported components through contractual relationships, and the increased risk of using unsupported system components can be mitigated by prohibiting the connection of such components to public or uncontrolled networks or implementing other forms of isolation. You can read the requirement directly at NIST 800-171 R3, 03.16.02 (p. 70).
None (0). Requirement 03.16.02 contains no bracketed assignment, so there is no organization-defined value to select and nothing for the DoD to specify. The requirement applies as written.
Your System Security Plan (SSP) narrative for 03.16.02 therefore records how the requirement is implemented rather than a parameter you chose.
NIST 800-171A R3 breaks 03.16.02 into two (2) determination statements, and it has no Organization-Defined Parameters (ODPs). These AOs are:
The two (2) objectives are the two paths: replace, or if replacement is not possible, provide mitigation options or alternative support. The full guidance on assessment methods and objects, is in NIST 800-171A R3, 03.16.02 (p. 93).
Examine: system and services acquisition policy and procedures; procedures for the replacement or continued use of unsupported system components; documented evidence of replacing unsupported system components; documented approvals (including justification) for the continued use of unsupported system components; SCRM plan; system security plan.
Interview: personnel with system and service acquisition responsibilities; personnel responsible for component replacement; personnel with system development life cycle responsibilities; personnel with information security responsibilities.
Test: processes for replacing unsupported system components; mechanisms for supporting or implementing the replacement of unsupported system components.
03.16.02 is net new for R3 and has no corresponding requirement in NIST 800-171 R2:
Mapped against the two (2) AOs, both (2) are net new (significant effort), with none direct, indirect, or unmapped. The source control, SA-22, was not part of the R2 assessable requirement set, so there is no transition path. Even if you already track end-of-life dates, expect an assessor to look for documented replacement activity and documented approvals with justification for anything still running unsupported.
Source Control in NIST 800-53 R5:
Secure Controls Framework (SCF) Crosswalk
Organizations running a single control set across multiple frameworks can satisfy 03.16.02 through the following SCF controls:
The crosswalks from NIST 800-171 R3 and NIST 800-171A R3 to the SCF are available at no cost through the SCF Set Theory Relationship Mapping (STRM): https://securecontrolsframework.com/start-here/set-theory-relationship-mapping-strm. The STRM also carries the relationship type for each mapping (Equal, Subset Of, Intersects With), which tells you whether an SCF control fully satisfies the requirement or only part of it. Mapping above taken from SCF 2026.3.
The pitfalls for this net-new requirement are about the components you cannot easily replace, each of which needs documented evidence of due diligence and due care such as policies, standards, procedures, and configuration screenshots:
Reasonable objective evidence for an assessment is often subjective. The following examples of evidence to address NIST 800-171 R3 03.16.02 are sourced from the SCF Evidence Request List (ERL), available at https://securecontrolsframework.com/free-content/scf-download. These ERL artifacts are mapped to NIST 800-171 R3 03.16.02 through SCF controls. They establish a starting point for discussions on what an organization needs to have for evidence of due diligence and due care to withstand external scrutiny by an assessor or regulator.
Alongside these, keep the System Security Plan (SSP) narrative for 03.16.02.
With both AOs net new, 03.16.02 is a significant lift, and it is one of the few requirements where the constraint is usually budget and procurement lead time rather than documentation. A realistic sequence:
How many assessment objectives does NIST 800-171 R3 03.16.02 have? NIST 800-171A R3 breaks 03.16.02 into two (2) assessment objectives. An assessor works through each one separately, so each needs its own evidence.
Which NIST 800-53 R5 control does NIST 800-171 R3 03.16.02 come from? SA-22.
How many Organization-Defined Parameters (ODPs) does NIST 800-171 R3 03.16.02 have? None (0). The requirement contains no bracketed assignment, so there is no organization-defined value and nothing for the DoD to specify.
Where does NIST 800-171 R3 03.16.02 sit in the NIST 800-171 R3 Kill Chain? Phase 16, IT Asset Management (ITAM). The Kill Chain is a phased model for sequencing R3 implementation, and it assigns this requirement to that phase.
03.16.02 Unsupported System Components replaces components once the developer, vendor, or manufacturer stops supporting them, and provides risk mitigation options or alternative support for the ones that cannot be replaced. It is net new for R3 with no R2 predecessor, so both objectives are new work. The recurring problem is end-of-life technology sitting in the environment with no decision recorded against it. Know your support status, replace what you can, and for what you cannot, write down the justification and the mitigation, including isolation from uncontrolled networks.
Authoritative sources:
Authoritative sources:
This guide reproduces U.S. Government text from NIST 800-171 R3 and NIST 800-171A R3. It is educational, not legal or assessment advice. Last reviewed: 2026-09-22.
