Independent DIB implementation resource — not affiliated with or endorsed by the U.S. Department of WarView the official DoW campaign ↗
Brilliant at the BasicsDIB Resource Center
03.16.02OFFICIAL TITLEPENDING NIST SME REVIEW

03.16.02 — Unsupported System Components

03.16 System and Services Acquisition · NIST SP 800-171 Rev. 3

Independent summary of the official requirement

Replace system components when support is no longer available from the developer, vendor, or manufacturer; when replacement is not possible, provide options for mitigating the resulting risk.

Rev. 3 requirement text is multi-part and parameterized with organization-defined values, so this site summarizes rather than reproduces it. The summary is independent — read the official publication for the binding wording.

NIST SP 800-171 Rev. 3 — Protecting CUI in Nonfederal Systems ↗NIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI ↗
Independent interpretation

What this requirement is after

An unsupported component is a permanent vulnerability: no patch will ever come, and every flaw discovered after end-of-support is a flaw forever. The requirement's default answer is replacement; where a production constraint makes replacement genuinely impossible, the organization must still produce deliberate risk options — isolation, restriction, extended support — rather than silence.

Across revisions

New in Rev. 3 with no Rev. 2 counterpart — end-of-support handling was previously implied through risk assessment and flaw remediation; it is now its own assessable requirement.

Mapped practices

Brilliant at the Basics practices that support this requirement

Direct implementation supportHigh confidence

Why: Retiring the systems attackers count on you keeping is this requirement in campaign language: strategic technical debt reduction exists to find unsupported and end-of-life components and replace them on a deliberate, funded schedule. No practice-requirement pair in this group is a closer fit.

What this does not claim: Supports implementation of the requirement without exhausting it: the requirement also demands documented risk-mitigation options for every component that genuinely cannot be replaced, and a retirement roadmap that goes silent about its exceptions leaves that half unimplemented. An assessor reads the unsupported-component register against the asset inventory, not against the roadmap's ambitions.

Practice-side activities
  • Build and maintain the unsupported and end-of-life register from inventory and vendor lifecycle data
  • Sequence replacements by exposure and business consequence, with funded milestones
  • Document mitigation — isolation, restriction, extended support — with owners and revisit dates for components that must remain
Evidence this produces
  • The unsupported-component register with support-end dates
  • Retirement records showing the register shrinking quarter over quarter
  • Mitigation decisions for retained components, each with an owner and review date

Where this holds: Strongest where vendor lifecycle data exists; homegrown and orphaned software needs a deliberate support-status decision rather than a vendor date.

Review status: Pending NIST SME review · Reviewed by Brilliant at the Basics editorial — practitioner-authored; NIST SME review pending · updated 2026-08-06

Doing the work

Implementation considerations and evidence

Implementation considerationsIndependent guidance — tailor to your environment
  • Derive the unsupported list from the asset inventory and vendor lifecycle data, and keep it current — end-of-support is a date you can see coming years out.
  • Prioritize replacement by exposure: an unsupported operating system on an internet-reachable server and one on an isolated bench instrument are not the same problem.
  • For components that must stay, document the mitigation decision — segmentation, removed network reachability, an extended support agreement — with an owner and a revisit date, so 'temporary' does not silently mean permanent.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • The unsupported-component register reconciled against the asset inventory, with support-end dates
  • Retirement and replacement records showing the register shrinking over time
  • Documented risk-mitigation decisions for components that cannot yet be replaced, each with an owner and review date

Suggested owners, derived from the mapped practices and artifacts: IT leader. Ownership is a named person in your organization, not a role on a website.

Artifacts

Templates and worksheets with a mapped relationship

No artifact in the library names this requirement yet. The library index groups everything by category and practice.

The other revision

Where this came from in Rev. 2

No direct Rev. 2 counterpart — this requirement is new in Rev. 3. Open the transition crosswalk →

Provenance

Sources and review status

Primary sourcesNIST SP 800-171 Rev. 3 — Protecting CUI in Nonfederal Systems · NIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI
Review statusPending NIST SME review
Content version1.0
Updated