NIST SP 800-171 Rev. 3 3.16.2 — Unsupported System Components

What this control requires

This control mandates replacing system components when support is no longer available from the developer, vendor, or manufacturer. It also requires providing risk mitigation options or alternative sources of support for components that cannot be replaced, ensuring the continued functionality of critical components and minimizing vulnerabilities from unsupported systems. This control supports the Unsupported System Management capability within the Planning (3.16) family.

In plain English

This control mandates replacing system components when support is no longer available from the developer, vendor, or manufacturer. In practice, this means you can prove you system management-level controls on a defined cadence.

Why it matters

DoD contractors and their subcontractors must implement all 100 SP 800-171 requirements to keep CUI handling contracts. Gaps are scored against the SPRS scoring methodology; below a 110-point starting score, each unmet requirement deducts points and a below-threshold score can disqualify a bid.

This control is rated high. Auditors expect a named owner, a remediation SLA, and a tooling artefact that evidences continuous operation.

What an auditor looks for

A C3PAO conducting a CMMC Level 2 assessment uses NIST SP 800-171A objectives. They expect a System Security Plan (SSP), Plan of Action & Milestones (POA&M) for any gaps, and objective evidence (configurations, ticket records, training records) for every requirement.

Within Planning, the assessor will trace your implementation back to the catalogue reference (Requirement 3.16.2) and look for objective evidence on the latest two assessment cycles.

How to implement

Secure Development

Pipeline. Require code review, SAST (Semgrep / Snyk Code), SCA (Dependabot / Renovate), secret-scanning and IaC scanning in the merge pipeline.

Branch protection. Protected branches enforce reviews, signed commits and passing CI before merge; document the protection rules as the control evidence.

Operational checklist

• System. Document the trigger, the owner and the cadence.
• Risk. Document the trigger, the owner and the cadence.
• Security. Document the trigger, the owner and the cadence.
• Supply. Document the trigger, the owner and the cadence.
• Scope: management, functionality, security, system components, development.

Evidence to collect

• Vendor Risk Management. vendor_risk_management evidence

Third-party risk management evidence (assessments, contracts, due diligence) shows supplier oversight. Focus: Unsupported System Components.

Common pitfalls

• CI security checks set to warn-only; the merge button is faster than the security feedback.

How it maps to other frameworks

Computed from shared tags, control component and key-operation subjects — handy when you are reconciling controls across an audit.

• ISO/IEC 27001:2022 A.8.30 — Outsourced development
• NIST SP 800-53 Rev. 5 SA-12(2) — Supplier Reviews
• SOC 2 (2017 TSC) CC9.2 — Vendor Risk Management
• BSI C5:2020 OIS-03 — Interfaces and Dependencies
• ISO/IEC 42001:2023 A.10.2 — Allocation of responsibilities

Related controls in NIST SP 800-171 Rev. 3

• Requirement 3.16.3 — External System Services
• Requirement 3.17.3 — Supply Chain Requirements and Processes
• Requirement 3.16.1 — Security Engineering Principles
• Requirement 3.4.1 — Baseline Configuration
• Requirement 3.11.1 — Risk Assessment
• Requirement 3.13.2 — Recategorized as NCO

References

• NIST Computer Security Resource Center — NIST SP 800-171 Rev. 3
• Catalogue identifier: Requirement 3.16.2

Topics: governance riskvendor riskvendor managementsupply chain securitythird party monitoringsecure development