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
3.4.2OFFICIAL STATEMENT BELOWBASIC REQUIREMENTPENDING NIST SME REVIEW

3.4.2 — Security configuration enforcement

3.4 Configuration Management · NIST SP 800-171 Rev. 2 · The heading label is this site's navigational shorthand; the official language is the statement below.

Official requirement statement (verbatim)

Establish and enforce security configuration settings for information technology products employed in organizational systems.

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

What this requirement is after

Out-of-the-box settings favor convenience over security. This requirement makes you pick a hardened configuration for the products you run — and enforce it, so the settings survive contact with real users and real deadlines.

Mapped practices

Brilliant at the Basics practices that support this requirement

Operational supportModerate confidence

Why: Documented, portable configuration baselines — the practice's mechanism for swapping products without security regressions — are what keep established security settings maintainable when the stack changes underneath them.

What this does not claim: The requirement is to establish and enforce the settings, and the practice does neither: it makes an existing configuration standard survivable through product change. Contributes to the requirement's durability rather than its substance, and the enforcement tooling and drift measurement remain separate work.

Practice-side activities
  • Express security configuration standards in portable, vendor-neutral terms
  • Re-verify settings against the standard whenever a product is adopted or swapped
Evidence this produces
  • Portable baseline documentation reused across a product change
  • Post-migration verification showing settings carried over

Review status: Technical review complete · Reviewed by inDirectIT practitioner review — CUI security and NIST SP 800-171 engineering · updated 2026-08-06

Doing the work

Implementation considerations and evidence

Implementation considerationsIndependent guidance — tailor to your environment
  • Adopt an established benchmark — CIS Benchmarks, DISA STIGs, or vendor security baselines — rather than inventing settings from scratch; tailor and record the deviations.
  • Enforce through policy engines (MDM, group policy, cloud configuration management) instead of hand-configuring machines that drift the day after.
  • Measure drift: an enforcement tool that reports the percentage of systems matching the standard turns this requirement into an operating metric.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • The adopted configuration standard with documented deviations
  • Enforcement policy exports from the tools that apply it
  • Drift reporting against the standard over time, not just at a point in time

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

Artifacts

Templates and worksheets with a mapped relationship

WORKSHEET · REVIEW ANNUALLY PER PLATFORMConfiguration Baseline Worksheet
The other revision

Where this lands in Rev. 3

Provenance

Sources and review status

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