NIST SP 800-171 Rev. 3: what changed from Rev. 2

NIST SP 800-171 Rev. 2 is the baseline publication and is documented with full bibliographic identity plus an explicit withdrawal notice that it is superseded in its entirety by Rev. 3. NIST SP 800-171 Rev. 3 is documented as the successor revision that incorporates changes from the February 2020/January 28, 2021 edition and provides a change log, but the provided material does not show a conflicting publication identity or supersession rule relative to the baseline.

What changed

"NIST SP 800-171 Rev. 2" says the requirements are "recommended security requirements" for protecting the confidentiality of CUI in nonfederal systems and organizations, are applicable only when mandated by a federal agency agreement, derive from FIPS 200 and the SP 800-53 moderate baseline, and are organized into "basic security requirements" and "derived security requirements" across "fourteen requirement families." "NIST SP 800-171 Rev. 3" says the requirements are also "recommended security requirements" for federal agencies to use to protect the confidentiality of CUI in nonfederal systems and organizations, are organized into "17 requirement families," and introduce "organization-defined parameters" that must be set by the agency or nonfederal organization if not specified. Rev. 3 also states that it does not apply to organizations collecting or maintaining information on behalf of a federal agency or using/operating a system on behalf of an agency, which must comply with FISMA instead; that explicit exclusion is not stated in the Rev. 2 evidence provided.

What changed

The baseline says the model is organized into "fourteen families"; Rev. 3 says it is organized into "17 families." The baseline says the model has "two parts: basic security requirements and derived security requirements" and is tailored from the "FIPS 200 requirements and the SP 800-53 moderate baseline"; Rev. 3 says the requirements are developed by starting with the "SP 800-53B moderate baseline" and tailoring SP 800-53 controls. The baseline does not describe organization-defined parameters as part of the model; Rev. 3 explicitly does. The baseline's assumptions are three-fold; Rev. 3 states five assumptions, including external service providers and same value in federal and nonfederal systems. The family set also differs: Rev. 2 omits Planning, System and Services Acquisition, and Supply Chain Risk Management as standalone families; Rev. 3 includes Planning, System and Services Acquisition, and Supply Chain Risk Management, and also includes Security Assessment and Monitoring instead of Security Assessment.

What changed

Baseline says the CUI requirements are developed from “basic security requirements come from FIPS 200” plus “derived security requirements ... from the NIST SP 800-53 moderate security control baseline,” with “three tailoring criteria” and “Appendix E” mappings, while Rev. 3 says requirements are developed from “the SP 800-53B moderate baseline,” uses “Appendix C” tailoring criteria, adds “FED, NCO, ORC, N/A, and CUI,” and “eliminated the distinction between basic and derived security requirements.”

What changed

Baseline Rev. 2 says access is limited to authorized users, processes, and devices, with limits on transaction types/functions, and treats account management, identifier management, authenticator management, session controls, remote/wireless access, and audit/accountability as separate requirements. Rev. 3 changes and adds obligations: it requires organizations to define allowed and prohibited account types; create, enable, modify, disable, and remove accounts; monitor account use; disable accounts when expired, inactive, unassociated, policy-violating, or risky; notify personnel on account changes; require logout after inactivity; require device lock after inactivity or before leaving unattended; explicitly require access enforcement and separate information flow enforcement; and expands audit requirements to specify event types, review/update frequencies, record content, preservation, timestamps, correlation, and protection of audit tools. Rev. 2’s wording on identifier/authenticator/password management is less explicit than Rev. 3’s lifecycle controls, prohibited-password list, default authenticator change at first use, and richer audit-record requirements.

What changed

Compared with Rev. 2, Rev. 3 adds or makes explicit several obligations that are not stated the same way in the baseline text: Rev. 2 says baseline configurations are maintained by creating new baselines and reviewing/updating them when changes are made based on security risks and deviations; Rev. 3 adds that organizations must review/update the baseline at an organization-defined frequency and when components are installed or modified, and that the baseline includes connectivity, operation, communications, system components, operational procedures, network topology, and component placement. Rev. 2 requires establishing and enforcing security configuration settings and recognizes secure configuration checklists; Rev. 3 requires establishing, documenting, and implementing organization-defined configuration settings in the most restrictive mode consistent with operational requirements, and identifying, documenting, and approving deviations. Rev. 2’s change control covers tracking/reviewing/approving/logging changes and security impact analysis before implementation; Rev. 3 adds explicit requirements to define which changes are configuration-controlled and to monitor/review the activities associated with them, plus post-implementation verification that security requirements continue to be satisfied. Rev. 2’s least-functionality language is framed as essential capabilities, with related restriction/disable requirements and optional blacklisting or whitelisting; Rev. 3 requires mission-essential capabilities, review at an organization-defined frequency, and a deny-all/allow-by-exception authorized-software model with review/update of the authorized list and version/source constraints. Rev. 2 covers inventories and may include location information for components; Rev. 3 adds explicit requirements to identify and document where CUI is processed and stored and to document changes to those locations, plus special configurations and post-return requirements for high-risk travel. In maintenance, Rev. 2 requires controlled tools, media checks, sanitization of off-site equipment, multifactor authentication for nonlocal maintenance, and supervision of unauthorized maintenance personnel; Rev. 3 adds approval and monitoring of maintenance activities, verification that no CUI remains by sanitizing or destroying equipment or retaining it in facility, replay resistance for nonlocal maintenance/diagnostic sessions, authorization lists for maintenance personnel, and explicit distinction between local and nonlocal maintenance.

What changed

Rev. 3 changes all three families. Media protection: 3.8.6 is withdrawn (addressed by 03.13.08), 3.8.8 is folded into 03.08.07, 03.08.07 now restricts or prohibits organization-defined types of system media, and 03.08.09 requires cryptographic protection of backups. Physical protection: 3.10.3, 3.10.4 and 3.10.5 are merged into 03.10.07 Physical Access Control, 03.10.08 Access Control for Transmission is new, and access authorizations, physical access monitoring and alternate work sites now carry organization-defined frequencies, events and security requirements. Personnel security: 03.09.01 adds organization-defined conditions that require rescreening, and 03.09.02 an organization-defined time period for termination and transfer actions.

What changed

Baseline Rev. 2 says incident response is an operational "incident-handling capability" with preparation, detection, analysis, containment, recovery, user response, tracking/reporting, training, testing, and assistance; Rev. 3 keeps that core but also adds explicit "Risk Assessment," "Security Assessment and Monitoring," and "Planning" families, including "risk response," "security assessment reports," "plan of action and milestones," "continuous monitoring strategy," "System Security and Privacy Plans," and a required "incident response plan" that "provide[s] a roadmap" and is updated/distributed/protected. The substantive delta is that Rev. 3 makes several supporting controls and artifacts explicit that Rev. 2 either does not state in this material or only mentions more generally.

What changed

Rev. 3 consolidates and withdraws several requirements. System and communications protection: 3.13.2 is recategorized as not a CUI requirement, 3.13.3 is addressed by the access control family, 3.13.5 is merged into 03.13.01 Boundary Protection, 3.13.7 is addressed by 03.01.12, 03.04.02 and 03.04.06, 3.13.14 (VoIP) is withdrawn as technology-specific, and 3.13.16 is merged into 03.13.08 Transmission and Storage Confidentiality, which also takes over 3.8.6. Network disconnect, key management, cryptographic protection and collaborative devices now use organization-defined parameters. System and information integrity: 3.14.4 and 3.14.5 fold into 03.14.02 Malicious Code Protection, 3.14.7 folds into 03.14.06 System Monitoring, and 03.14.08 Information Management and Retention is new.

What changed

Rev. 2: "does not present an explicit organization-defined parameter catalog in the later NIST sense" and "does not establish a single consolidated catalog of organization-defined parameters, nor a general parameter framework that names assignment and selection operations as such." Rev. 3: "makes organization-defined parameters (ODPs) an explicit part of the security-requirement specification," "states that ODPs are included in certain security requirements and provide flexibility through assignment and selection operations," and "includes an explicit catalog of ODPs in Appendix D."

What changed

Rev. 2: the text says its explicit example is a Media Protection family example and illustrates requirement structure using requirement 3.8.3 and the Media Protection set; it does not present an explicit illustrative example whose sample requirement is the cryptographic protection requirement itself. Rev. 3: the text presents a sample requirement labeled "03.13.11 Cryptographic Protection" with the statement "Implement the following types of cryptography when used to protect the confidentiality of CUI: [Assignment: organization-defined types of cryptography]," and shows source/control metadata including SC-13 and Supporting Publication FIPS 140-3.

What changed

Compared to Rev. 2, Rev. 3 changes the family’s normative content: Rev. 2 says the family consists of two basic requirements and one derived requirement, with "Security Awareness Training (AT-2), the Insider Threat enhancement (AT-2(2)), and Role-Based Security Training (AT-3)" included, while "Security Awareness and Training Policy and Procedures (AT-1) and Security Training Records (AT-4)" are treated as expected to be routinely satisfied without specification; Rev. 3 instead includes "AT-01 Policy and Procedures, AT-02 Literacy Training and Awareness, AT-02(02) Insider Threat, AT-02(03) Social Engineering and Mining, and AT-03 Role-Based Training" as CUI-related requirements and states "AT-04 Training Records is excluded as not directly related to protecting the confidentiality of CUI." Rev. 2 requires awareness of security risks, policies, standards, procedures, basic information security, user actions, suspected incidents, and operations security, with examples of awareness techniques; Rev. 3 keeps those topics but adds explicit coverage of "social engineering" and "social mining," defines them, and requires reporting of those incidents as well. Rev. 2 says organizations determine the content and frequency of awareness training and role-based training based on their requirements and authorized access; Rev. 3 adds organization-defined recurring frequencies, triggering events, and content-update frequencies for literacy and role-based training, plus training before access or assigned duties. Rev. 2 frames insider-threat training as role-tailorable examples; Rev. 3 likewise allows tailoring but makes it an explicit literacy-training topic and adds reporting channels for social engineering and data-mining instances. Rev. 2 mentions incident response training only as adjacent content elsewhere in the publication; Rev. 3 similarly treats incident response as separate but explicitly notes it may be provided as part of role-based training.

What changed

Rev. 2: "does not include System and Services Acquisition as one of the fourteen Chapter Three security requirement families" and only retains SA-8, "Security Engineering Principles," by grouping it with System and Communications Protection; Rev. 3: "establishes system and services acquisition requirements as a distinct security-requirement family" with explicit requirements for systems security engineering principles, unsupported components, external system services, and acquisition-related supply chain controls. Rev. 2 treats most SA controls as "NFO" in Appendix E and not as separate CUI requirements, while Rev. 3 makes them directly normative requirements in the family.

What changed

Rev. 2: "does not define a distinct supply chain risk management requirement family" and is described as having only related practices; Rev. 3: "establishes supply chain risk management requirements as a distinct security requirement family". Rev. 2: "not established: a requirement to develop a dedicated supply chain risk management plan, a stated review and update cycle for a dedicated supply chain risk management plan, [or] a requirement to protect a dedicated supply chain risk management plan from unauthorized disclosure"; Rev. 3: requires an organization to "develop a supply chain risk management plan," "review and update that plan at an organization-defined frequency," and "protect the plan from unauthorized disclosure." Rev. 2 only references trusted procurement processes and SP 800-161; Rev. 3 explicitly requires "acquisition strategies, contract tools, and procurement methods" and maps to SR controls including "SR-02 supply chain risk management plan" and "SR-05 acquisition strategies, tools, and methods."