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.04.06OFFICIAL TITLEPENDING NIST SME REVIEW

03.04.06 — Least Functionality

03.04 Configuration Management · NIST SP 800-171 Rev. 3

Independent summary of the official requirement

Requires configuring the system to provide only mission-essential capabilities; prohibiting or restricting use of organization-defined functions, ports, protocols, connections, and services; reviewing the system at an organization-defined frequency to identify unnecessary or nonsecure ones; and disabling or removing those found.

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

Every service a system runs is attack surface. Systems are shipped and kept lean — essential capability only, an explicit list of what is forbidden or restricted, and a periodic sweep for the things that crept back in.

Across revisions

Merges 3.4.6 (least functionality) and 3.4.7 (nonessential programs, ports, protocols, and services) into one requirement, with the review frequency an organization-defined parameter.

Mapped practices

Brilliant at the Basics practices that support this requirement

Contextual relationshipModerate confidence

Why: Retiring legacy systems removes nonessential and nonsecure functions wholesale — a decommissioned server is the most complete service disablement there is — and the practice's exposure-first sequencing tells the least-functionality review where to look first.

What this does not claim: The requirement's substance is configuration work on the systems that remain: mission-essential capability, a defined prohibited list, periodic review, and disablement. The practice shrinks and informs that work without performing any of it, so the relationship is contextual rather than implementation.

Practice-side activities
  • Retire or isolate unsupported systems whose services cannot be hardened
  • Feed end-of-life findings into the least-functionality review
Evidence this produces
  • Decommissioning records for retired systems
  • Debt-reduction plans naming exposed services

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
  • Fold the prohibited list into build baselines (03.04.01) so lean is the default, not a cleanup exercise.
  • The periodic review can be a port-and-service scan diffed against last quarter — cheap and revealing.
  • Legacy protocols — SMBv1, unsigned LDAP, Telnet — are the usual residents of the disable list and the usual re-arrivals after an appliance replacement.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • The documented prohibited and restricted list
  • Dated review results and the disablement actions that followed

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

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