Security requirement
- a.Replace system components when support for the components is no longer available from the developer, vendor, or manufacturer.
- b.Provide options for risk mitigation or alternative sources for continued support for unsupported components that cannot be replaced.
Discussion
Support for system components includes software patches, firmware updates, replacement parts, and maintenance contracts. An example of unsupported components includes when vendors no longer provide critical software patches or product updates, which can result in opportunities for adversaries to exploit weaknesses or deficiencies in the installed components. Exceptions to replacing unsupported system 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. Alternative sources of support address the need to provide continued support for system components that are no longer supported by the original manufacturers, developers, or vendors when such components remain essential to organizational missions and business functions. If necessary, 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. Such contractual relationships can include open-source software value-added vendors. 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.
Implementation perspective
Treat Unsupported System Components as a CUI protection outcome that must be reflected in the system boundary, documented implementation, operational behavior, and assessment evidence. Pay particular attention to security requirements in acquisition, secure development, supplier expectations, and acceptance evidence.
- Confirm the requirement is in scope for the CUI system components, services, users, and external connections being assessed.
- Resolve every organization-defined parameter through an approved governance and tailoring process.
- Map each clause of the requirement to an accountable owner, implementation mechanism, and evidence source.
- Verify that inherited and shared implementations are supported by current provider evidence and responsibility boundaries.
- Collect evidence during normal operation and review changes, exceptions, and deficiencies on a risk-based cadence.
Questions to ask
- Which CUI assets, data flows, users, and services are protected by this requirement?
- Which portions are implemented locally, inherited, shared, or not applicable, and what evidence supports that determination?
- Do the system security plan, deployed configuration, operating process, and assessment evidence tell the same story?
- What change, incident, or threshold should trigger reassessment?
Evidence and validation
- security requirements in contracts and specifications
- architecture and design review records
- development lifecycle evidence
- supplier assessment and acceptance records
Common failure patterns
- security requirements added after procurement
- supplier claims accepted without evidence
- development exceptions becoming permanent
- security architecture not tied to testable requirements
Assessment objectives and methods
Assessment objectives (2)
- b.
options for risk mitigation or alternative sources for continued support for unsupported components that cannot be replaced are provided.
- a.
system components are replaced when support for the components is no longer available from the developer, vendor, or manufacturer.
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
- other relevant documents or records
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
Source NIST SP 800-53 controls
These controls are referenced by the official SP 800-171 Rev. 3 OSCAL record. Open the corresponding control pages for complete control text, enhancements, D3FEND mappings, and related learning.
Authoritative sources
- NIST SP 800-171 Revision 3 official publication ↗
- NIST SP 800-171A Revision 3 official publication ↗
- NIST OSCAL Content release used for this import ↗
Bare Metal Cyber is an independent educational publisher and is not affiliated with or endorsed by NIST. The official publications, the responsible federal agency, and the governing contract or agreement determine applicability, tailoring, assessment depth, and required implementation.