NIST SP 800-171 protecting Controlled Unclassified Information

What it is

NIST SP 800-171 Revision 3 sets the security requirements for protecting the confidentiality of Controlled Unclassified Information (CUI) when that information is processed, stored, or transmitted on a nonfederal organization's own systems. NIST wrote it, in its own words, "for use by federal agencies in contractual vehicles or other agreements" with the nonfederal organizations they share CUI with. The publication does not bind anyone by existing; a federal agency's contract or agreement has to invoke it first. Revision 3 was approved in April 2024 and published in May 2024, superseding Revision 2 from February 2020.

The requirements are organized into 17 families, from access control and audit logging through physical protection and supply chain risk management, and every one of them is tailored down from the much larger control catalog in NIST SP 800-53. Three families that exist in that larger catalog are dropped here entirely: Contingency Planning, because it addresses availability rather than confidentiality; Program Management, because it is not tied to a specific system; and PII Processing and Transparency, because personally identifiable information is already treated as a category of CUI and needs no separate family. That is worth knowing if you are used to the fuller SP 800-53 baseline and expect to see them.

Who it addresses, and how it binds

The document names two roles directly. From what it calls the "Federal perspective," it addresses "the entity establishing and conveying the security requirements in contractual vehicles or other types of agreements." From the "Nonfederal perspective," it addresses "the entity responding to and complying with the security requirements set forth in contracts or agreements." Underneath those two roles sit individuals with system development, acquisition, risk management, and security assessment responsibilities.

Nothing in the document makes it binding on its own. It becomes real for a nonfederal organization the moment a federal contract or agreement names it, and only to the extent that contract says. The requirements apply to "components of nonfederal systems that process, store, or transmit CUI or that provide protection for such components," with no restriction to a particular sector or technology: a covered system can be anything from a conventional IT network to "operational technology (OT)... Internet of Things (IoT) devices, Industrial IoT (IIoT) devices, specialized systems, cyber-physical systems, embedded systems, and sensors."

Where the scoping decision pays off early

The document itself flags where the cost of this work actually sits. Section 1.1 notes that an organization can limit the scope of the security requirements "by isolating the system components" that handle CUI "in a separate security domain," which avoids "increasing the organization's security posture beyond what it requires for protecting its missions, operations, and assets." Decided before a system is built, that is an architecture choice. Decided after a contract naming this document has already been signed, it usually means separating CUI-handling components out of a system that was never built with that boundary in mind. Before any of the 97 requirements can be assessed, requirement 03.11.01 states plainly that "establishing the system boundary is a prerequisite to assessing the risk of the unauthorized disclosure of CUI" - so the first real question is not which requirement to start with, but where CUI actually lives.

What the 17 families cover

Access Control requires defined and managed account types, least privilege enforcement (including a rule that privileged users use non-privileged accounts for everyday, non-security work), lockout after repeated failed logons, and remote and wireless access routed through managed control points. Mobile devices need full-device or container-based encryption before they can hold CUI, and any external system, personally owned or otherwise, "is prohibited unless specifically authorized."

Awareness and Training, Audit and Accountability, and Configuration Management ask for security literacy and role-based training tied to actual roles, a defined and reviewed set of logged events with protected audit records, and a documented baseline configuration with formal change control. Software execution is deny-by-default: only software on an approved list may run.

Identification and Authentication is where Revision 3 changes what an auditor used to older guidance will expect. Multi-factor authentication now applies to non-privileged accounts as well as privileged ones, not privileged accounts alone. Password management moves away from mandatory periodic rotation and toward checking new passwords against a maintained list of "commonly-used, expected, or compromised passwords" before they are accepted.

Incident Response, Maintenance, Media Protection, and Personnel Security cover a documented incident response plan tested on its own schedule (not just written and filed), approved and malware-checked maintenance tools with multi-factor authentication for remote maintenance sessions, sanitization of media before disposal or reuse, and screening plus a defined process for disabling access the moment employment ends or changes.

Physical Protection, Risk Assessment, and Security Assessment and Monitoring require a maintained facility access list with monitored and logged entry points, a risk assessment that explicitly includes supply chain risk, and a requirement that the organization assess, on its own defined schedule, whether it is actually meeting these requirements, tracking anything unresolved in a plan of action and milestones (POAM).

System and Communications Protection and System and Information Integrity require boundary protection separating public-facing components from internal ones, a deny-by-default network traffic policy, cryptographic protection for CUI both in transit and at rest, and malicious code protection with a defined patching timeframe for security-relevant updates.

Planning, System and Services Acquisition, and Supply Chain Risk Management close the set: documented policies and procedures behind every other family, a system security plan describing the system's boundary and how each requirement is met, security engineering principles applied to new development, a plan for replacing unsupported components, and a supply chain risk management plan covering the system from research and development through disposal.

How you are evaluated

There is no certification against NIST SP 800-171. The document names no accredited certification body and describes no scheme for certifying an organization or a product against it. What it requires instead is self-assessment: the organization must "assess the security requirements for the system and its environment of operation... to determine if the requirements have been satisfied," on a frequency it defines itself, and document any gap in a plan of action and milestones. NIST's companion publication, SP 800-171A, sets out procedures for running that assessment, but the document leaves the decision about what evidence is enough to whoever is party to the contract: a federal agency "may consider system security plans and POAMs as inputs to risk-based decisions on whether to process, store, or transmit CUI on a system hosted by a nonfederal organization." In practice, what an assessor or a contracting officer asks to see is the system security plan, the POAM, audit records, and the training, screening, and maintenance records the individual requirements call for, not a certificate.

Standards it references

NIST SP 800-171's requirements are tailored from the full control catalog in NIST SP 800-53, Rev. 5, using the moderate baseline in SP 800-53B. Its companion, NIST SP 800-171A, Rev. 3, provides the procedures for assessing the requirements described here. The underlying CUI protection scheme traces to FIPS 199 and FIPS 200, which set the confidentiality impact value the requirements are built to, and to Executive Order 13556 and the CUI federal regulation at 32 CFR Part 2002. Individual requirements point to FIPS 140-3 for cryptographic modules and to roughly forty further NIST Special Publications and Interagency Reports as supporting, non-normative guidance, none of which are held separately in our catalogue.