Configuration Settings is where the baseline gets hardened. Baseline Configuration (03.04.01) establishes the documented specification of a system, and Configuration Settings (03.04.02) requires that the specific security-relevant settings within that system reflect the most restrictive mode consistent with operational requirements. It has two (2) parts: establish, document, and implement the configuration settings that represent that most restrictive mode, and identify, document, and approve any deviations from those settings. Per the NIST discussion, configuration settings are the parameters in hardware, software, or firmware that affect the security posture or functionality of the system, and common secure configurations, also known as hardening guides, security reference guides, and security technical implementation guides, provide recognized benchmarks for specific platforms.
A common difficulty with this requirement is running default settings and calling them a baseline. R3 expects a defined, documented set of hardened settings and a controlled process for approving exceptions. Undocumented deviations are the most common finding, because real environments always need some exceptions, and those exceptions have to be identified, documented, and approved rather than made silently. For Department of Defense (DoD) contractors, the settings parameter is specified and points to a recognized source.
Where things stand for companies facing the transition from NIST 800-171 R2 to R3:
The following is reproduced verbatim from NIST 800-171 R3, requirement 03.04.02 Configuration Settings. Only the formatting has been adjusted for readability. This requirement has two (2) lettered parts:
The source control is CM-06 from NIST 800-53. The bracketed assignment in part a is the Organization-Defined Parameter (ODP): the configuration settings. Per the NIST discussion, security parameters include registry settings, account, file, and directory permission settings, and settings for functions, ports, protocols, and remote connections, and organizations establish organization-wide settings and then derive specific settings for the system, which become part of the configuration baseline. You can read the requirement directly at NIST 800-171 R3, 03.04.02 (p. 27).
One (1) value sits inside this requirement. Depending on your contract, your organization may be permitted to define it. Organizations in the DIB subject to CMMC are not, because the DoD has defined it as policy.
The value below comes from Attachment A of the DoD Chief Information Officer (CIO) memorandum dated 10 April 2025 (signed David W. McKeown). The memo identifies each parameter by requirement sub-part, while NIST 800-171A R3 identifies the same parameter by ODP number. Both identifiers appear below so you can match your System Security Plan (SSP) language to either document.
The assigned value for 03.04.02.a, quoted from the memo:
Apply the appropriate use of common security configurations available from the National Institute of Standards and Technology’s National Checklist Program (NCP) website (https://ncp.nist.gov/repository) and prevent remote devices from simultaneously establishing non-remote connections with organizational systems and communicating via some other unauthorized connection to resources in external networks. Document any deviations from the published standard or source document.
The memo states that its values "will be updated as necessary," so confirm against the current version before writing them into policy.
NIST 800-171A R3 breaks 03.04.02 into five (5) assessment objectives: one (1) Organization-Defined Parameter (ODP) and four (4) determination statements. These AOs are:
Part a splits into establishing and documenting the settings (a[01]) and implementing them (a[02]), and part b splits into identifying and documenting deviations (b[01]) and approving them (b[02]). If you are a DoD contractor, the ODP is specified. Per the DoD-specified ODP value in ComplianceForge's NIST 800-171 R3 Transition Guide, the configuration settings apply the appropriate common security configurations available from the National Institute of Standards and Technology National Checklist Program (NCP) repository, prevent remote devices from simultaneously establishing a non-remote connection to organizational systems while communicating through another unauthorized connection to external networks (that is, prevent split tunneling), and document any deviations from the published standard or source. The full guidance on assessment methods and objects, is in NIST 800-171A R3, 03.04.02 (p. 33).
Examine: configuration management policy and procedures; procedures for system configuration settings; configuration management plan; system design documentation; system configuration settings; common secure configuration checklists; system component inventory; evidence supporting approved deviations from established configuration settings; change control records; system data processing and retention permissions; system audit records; system security plan.
Interview: personnel with security configuration management responsibilities; personnel with information security responsibilities; system administrators.
Test: processes for managing configuration settings; mechanisms that implement, monitor, or control system configuration settings; mechanisms that identify or document deviations from established configuration settings.
03.04.02 maps from NIST 800-171 R2 requirement 3.4.2 (establish and enforce security configuration settings for information technology products employed in organizational systems), and it draws on elements of R2 requirement 3.4.6 (employ the principle of least functionality):
Mapped against the five (5) AOs, two (2) are direct (minimal effort) and three (3) are indirect (moderate effort), with no net-new AOs and none with no mapping. The establish-and-enforce concept carries forward, but R3 reframes enforcement as a deviation-management process. If you satisfied 3.4.2, confirm your settings still reflect the most restrictive mode and that you actually identify, document, and approve exceptions rather than allow them informally.
Source Control in NIST 800-53 R5:
Secure Controls Framework (SCF) Crosswalk
Organizations running a single control set across multiple frameworks can satisfy 03.04.02 through the following SCF controls:
The crosswalks from NIST 800-171 R3 and NIST 800-171A R3 to the SCF are available at no cost through the SCF Set Theory Relationship Mapping (STRM): https://securecontrolsframework.com/start-here/set-theory-relationship-mapping-strm. The STRM also carries the relationship type for each mapping (Equal, Subset Of, Intersects With), which tells you whether an SCF control fully satisfies the requirement or only part of it. Mapping above taken from SCF 2026.3.
The following are issues teams may encounter rather than certainties. They are about deviation control and the settings source, each of which needs documented evidence of due diligence and due care such as policies, standards, procedures, and configuration screenshots:
Reasonable objective evidence for an assessment is often subjective. The following examples of evidence to address NIST 800-171 R3 03.04.02 are sourced from the SCF Evidence Request List (ERL), available at https://securecontrolsframework.com/free-content/scf-download. These ERL artifacts are mapped to NIST 800-171 R3 03.04.02 through SCF controls. They establish a starting point for discussions on what an organization needs to have for evidence of due diligence and due care to withstand external scrutiny by an assessor or regulator.
Alongside these, keep the System Security Plan (SSP) narrative for 03.04.02 recording the ODP values you adopted.
With two (2) AOs mapping directly and three indirectly, 03.04.02 is a moderate lift focused on hardening and exception control. A realistic sequence:
What value does the DoD require for the organization-defined parameter in NIST 800-171 R3 03.04.02? R3 leaves the value to the organization. For the DIB, the DoD set it in the 10 April 2025 memorandum under ODP identifier 03.04.02.a: Apply the appropriate use of common security configurations available from the National Institute of Standards and Technology’s National Checklist Program (NCP) website (https://ncp.nist.gov/repository) and prevent remote devices from simultaneously establishing non-remote connections with organizational systems and communicating via some other unauthorized connection to resources in external networks. Document any deviations from the published standard or source document.
How many assessment objectives does NIST 800-171 R3 03.04.02 have? NIST 800-171A R3 breaks 03.04.02 into five (5) assessment objectives: one (1) Organization-Defined Parameters (ODPs) and four (4) determination statements. An assessor works through each one separately, so each needs its own evidence.
Which NIST 800-53 R5 control does NIST 800-171 R3 03.04.02 come from? CM-06.
Where does NIST 800-171 R3 03.04.02 sit in the NIST 800-171 R3 Kill Chain? Phase 12, Secure Baseline Configurations (SBC). The Kill Chain is a phased model for sequencing R3 implementation, and it assigns this requirement to that phase.
03.04.02 Configuration Settings establishes, documents, and implements hardened settings that reflect the most restrictive mode consistent with operations, and controls deviations through identification, documentation, and approval. It maps from R2 3.4.2 with the establish objectives transitioning directly and the enforcement objectives indirectly, reframed as deviation management. The recurring problem is running defaults and allowing silent exceptions. Define your settings (for DoD, from the NIST National Checklist Program and with split-tunneling prevention), implement them, and approve every deviation.
Authoritative sources:
Authoritative sources:
This guide reproduces U.S. Government text from NIST 800-171 R3 and NIST 800-171A R3 and references the DoD ODP memorandum of 10 April 2025. It is educational, not legal or assessment advice. Last reviewed: 2026-09-22.
