NIST SP 800-171 is what the federal government asks of companies that hold its controlled unclassified information (CUI) on their own systems. If you are a defense contractor, a subcontractor several tiers down, or a supplier that receives technical drawings from a prime, it is probably already in your contract.
The requirements read as plain sentences, and that is deceptive. "Employ FIPS-validated cryptography" is seven words and can take months. This article covers what the publication requires, which requirements take the most work in practice, and the contract obligations that travel with it. It uses Rev. 2 numbering, because DoD contracts and CMMC Level 2 currently reference Rev. 2. Check which revision your contract cites.
What 800-171 is and when it applies
800-171 sets security requirements for nonfederal systems that process, store, or transmit CUI. It was derived from the NIST SP 800-53 Moderate baseline, tailored to remove controls that are purely federal or that a contractor would be expected to have anyway.
The requirements apply to system components that process, store, or transmit CUI, and to components that provide security protection for those components. That second clause catches people out. Your identity provider, your log platform, and your endpoint management tool are in scope even if they never touch a CUI file.
800-171 does not apply itself. A contract or agreement does. For DoD, the usual vehicle is DFARS 252.204-7012. Other agencies use their own contract terms. Read your contract first, then the standard.
The 14 families in Rev. 2
Rev. 2 contains 110 requirements in 14 families: Access Control, Awareness and Training, Audit and Accountability, Configuration Management, Identification and Authentication, Incident Response, Maintenance, Media Protection, Personnel Security, Physical Protection, Risk Assessment, Security Assessment, System and Communications Protection, and System and Information Integrity.
Requirements are numbered by family. Family 3.1 is Access Control, so 3.1.1 is its first requirement. Rev. 2 also distinguishes basic requirements, taken from FIPS 200, from derived requirements, taken from 800-53 controls. The distinction matters less in practice than it looks. Both are mandatory.
Rev. 3, published in 2024, restructures all of this, with new families and new numbering. The differences are a topic of their own.
The requirements that take the most work
Most of the 110 requirements are ordinary security hygiene that a mature team already does. A handful account for most of the effort, either because they need new technology or because they reach every corner of the environment.
3.13.11: FIPS-validated cryptography
"Employ FIPS-validated cryptography when used to protect the confidentiality of CUI." Validated means the cryptographic module has a certificate from NIST's Cryptographic Module Validation Program. A product that uses strong algorithms is not the same as one running a validated module. Check the certificate, check that it covers the version you run, and check that the validated mode is switched on where the product requires it. This applies to CUI at rest and in transit, on servers, laptops, mobile devices, and removable media.
3.5.3: multi-factor authentication
"Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts." The phrase "local access to privileged accounts" is the part teams miss. An administrator logging in at a server console, or a local administrator account on a laptop, needs MFA too. Service accounts and break-glass accounts need a documented approach. Our article on enforcing MFA for every user covers the common gaps.
3.3.1 and 3.3.2: audit logging
Create and retain audit records sufficient to monitor, analyze, investigate, and report unauthorized activity, and make sure actions can be traced to individual users. That means shared accounts are a problem, log sources must cover every in-scope component, and retention must be long enough to support an investigation. The second requirement rules out generic administrator logins that several people share.
3.13.1 and 3.13.6: boundary protection
Monitor and control communications at external and key internal boundaries, and deny network traffic by default, permitting by exception. A flat network with permissive outbound rules fails both. Deny-by-default is straightforward to state and slow to implement on a network that grew without it.
3.8: media protection
Protect and control media containing CUI, sanitize it before disposal or reuse, control removable media, and encrypt CUI on digital media in transport unless other physical safeguards protect it. This family reaches printers, scanners, copier hard drives, backup tapes, and USB drives. It is often where scoping discovers CUI nobody knew about.
3.12.4 and 3.12.2: the plan and the gaps
Develop and maintain a system security plan, and develop and implement plans of action to correct deficiencies. These are documentation requirements, but everything else is assessed against them. Without a system security plan, a DoD assessment cannot be completed.
The DFARS obligations that travel with it
If your contract includes DFARS 252.204-7012, implementing 800-171 is one part of what it asks. The clause also requires you to:
Report cyber incidents affecting covered defense information to DoD within 72 hours of discovery, through DoD's reporting portal. Reporting requires a DoD-approved medium assurance certificate, so obtain one before you need it.
Preserve images of affected systems and relevant monitoring data for at least 90 days from the report, in case DoD asks for them.
Submit malicious software you discover to DoD as the clause directs.
Hold cloud providers to a standard. A cloud service used to store, process, or transmit covered defense information must meet security requirements equivalent to the FedRAMP Moderate baseline, among other conditions.
Flow the clause down to subcontractors whose work involves covered defense information.
DFARS 252.204-7019 and 252.204-7020 add assessment obligations: a current assessment score posted in DoD's Supplier Performance Risk System, and access for DoD to conduct deeper assessments. CMMC, defined in 32 CFR Part 170, adds a verification layer on top. See our CMMC framework page for its structure, and confirm the specific clauses in your contract.
A practical order of work
The order matters, because early decisions set the size of everything after.
Find the CUI. Identify what CUI you receive and create, and every place it goes.
Draw the boundary. Decide whether to protect the whole environment or an enclave built for CUI.
Assess the gap against all 110 requirements, inside that boundary.
Write the system security plan, describing what is implemented today.
Record the gaps in a plan of action with owners and dates.
Fix the heavy items first. Cryptography, MFA, logging, and boundary protection take the longest and carry high weights in DoD scoring.
Score honestly and post the result where your contract requires.
Common mistakes
"AES-256" taken as FIPS validation. Algorithm strength and module validation are different claims. Only the second satisfies 3.13.11.
Forgotten security tools. The systems that protect CUI assets are in scope. So is the managed service provider's remote access tool.
Assuming the cloud provider covers it. A provider with the right authorization covers its share. Your configuration, accounts, and endpoints remain yours.
Writing the plan to the target state. The system security plan describes today. The plan of action describes tomorrow.
Our NIST 800-171 framework page maps the families in more detail, and the 800-53 families overview shows where each requirement came from.
How TrustLynce helps
TrustLynce tracks the 110 requirements with owners, implementation status, and evidence collected on a schedule from connected systems, and its endpoint agent reports disk encryption and screen lock status for in-scope laptops. See evidence collection.