NIST SP 800-172 Rev. 3 (enhanced security requirements for CUI), explained

NIST SP 800-172 Revision 3, "Enhanced Security Requirements for Protecting Controlled Unclassified Information," is NIST's supplement to SP 800-171 for the subset of Controlled Unclassified Information (CUI) that is tied to a "critical program" or a "high value asset (HVA)" — categories the publication treats as likely targets of the advanced persistent threat (APT). Per its own abstract, the publication is "designed as a supplement to NIST Special Publication (SP) 800-171 to protect against advanced persistent threats," and it explicitly does not replace SP 800-171's baseline: its requirements are "implemented in addition to security requirements in SP 800-171, since those requirements are not designed to address the APT." Revision 3 was approved by the NIST Editorial Review Board on 27 April 2026 and published in May 2026, authored by Victoria Pillitteri and Ron Ross, superseding the original 2 February 2021 edition.

17 families, 103 active requirements

Like SP 800-171, Rev. 3 organizes its content into 17 families (Table 1 in the publication): 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 and Monitoring, System and Communications Protection, System and Information Integrity, Planning, System and Services Acquisition, and Supply Chain Risk Management.

Appendix C's summary table assigns each requirement an identifier from 03.01.01E through 03.17.05E. Counting those identifiers directly in the final PDF gives 115 numbered slots; of those, 12 are explicitly marked "Withdrawn" in the table (each pointing to the replacement requirement(s) that cover it), leaving 103 enhanced security requirements currently in force. Enhanced requirements always carry a trailing "E" — the publication is explicit that the sequential numbering does not mean an enhanced requirement enhances the identically-numbered SP 800-171 requirement; that mapping, where one exists, is stated separately in each requirement's discussion section.

Three requirement types: E, T, S

Appendix C tags every requirement with one of three types:

• E — enhances an SP 800-171 requirement. The requirement sharpens or extends a named requirement already in SP 800-171. Example: 03.01.01E Dual Authorization ("Enforce dual authorization for [organization-defined privileged commands...]") enhances SP 800-171 requirement 03.01.02 and traces to SP 800-53 control AC-03(02).
• T — tailored back in from SP 800-53B. Sourced to a security control that SP 800-171 had tailored out of the SP 800-53B moderate baseline; SP 800-172 reinstates it for the APT-focused case.
• S — strengthens, without a direct SP 800-171 mapping. Sourced straight from an SP 800-53 control, included because it strengthens protection for CUI tied to a critical program or HVA even though it doesn't enhance any specific SP 800-171 requirement — e.g., 03.01.04E Concurrent Session Control, sourced to SP 800-53 control AC-10.

The protection strategy: PRA, DLO, CRS — and five adversary effects

Section 2.2 frames the whole requirement set as a multidimensional, defense-in-depth protection strategy built around three elements, each requirement tagged with the ones it supports:

• Penetration-Resistant Architecture (PRA) — technology, engineering and procedures that limit an adversary's opportunities to compromise a system and establish a persistent presence.
• Damage-Limiting Operations (DLO) — procedural and operational measures that help an organization detect successful compromises (detected and undetected) and limit their effects.
• Cyber Resiliency (CRS) — the capacity to anticipate, withstand, recover from and adapt to adverse conditions, cross-referenced to SP 800-160 Volume 2.

Each requirement's discussion also names which of five adversary effects it is meant to produce — preclude, expose, redirect, impede, limit — detailed further in Appendix D. The publication recommends selecting requirements that spread across all three protection-strategy elements rather than clustering in one, to avoid an unbalanced response to the APT.

How this fits with SP 800-171 and CMMC

SP 800-172 requirements are not mandatory by default: federal agencies select a subset based on mission need and risk, and convey that selection to a nonfederal organization through a contract, grant or agreement — there is "no expectation that all of the enhanced security requirements will be selected." Organizations can also scope which system components the requirements apply to, for example by isolating CUI processing into a separate security domain via network segmentation or zero-trust architecture, rather than applying SP 800-172 organization-wide.

A companion publication, SP 800-172A, revised to Rev. 3 alongside this document and titled "Assessing Enhanced Security Requirements for Controlled Unclassified Information," supplies the assessment procedures — built on the same methodology as SP 800-53A — for verifying these requirements have been implemented.

On the DoD contracting side, our SP 800-171 / CMMC 2.0 guide covers how CMMC Level 3 selects a defined subset of SP 800-172 requirements on top of the SP 800-171-based CMMC Level 2 baseline; that guide also covers why CMMC's own rule text currently points to SP 800-171 Revision 2 rather than the newer Revision 3, a distinction worth checking for SP 800-172 as well before assuming any particular CMMC assessment maps one-to-one onto this May 2026 edition.

What changed from the 2021 edition

Per the publication's own Appendix F change log, Rev. 3 is a substantive rewrite, not a light edit: it increases the specificity of requirements to "remove ambiguity" and clarify assessment scope, groups related requirements for efficiency, removes "outdated and redundant" requirements, adds new requirements based on current threat intelligence and empirical attack data plus an expanded integrity/availability scope (not confidentiality alone), adds requirement titles, restructures discussion sections, aligns language with current SP 800-53 control text, and adds the new Appendix C (requirement summary table) and Appendix E (organization-defined parameters). It also folds in a numbering-scheme change to stay consistent with SP 800-171 Rev. 3.

A workable starting point

1. Confirm the requirement actually applies before building to it. SP 800-172 only matters once a federal agency has designated specific CUI as tied to a critical program or HVA and conveyed a selected subset of requirements in a contract — it is not a general-purpose hardening baseline to adopt unprompted.
2. Treat the E/T/S tag as a planning signal. "E" requirements map cleanly onto existing SP 800-171 control work; "S" requirements are net-new APT-specific capabilities (decoys, concurrent session limits) that typically need separate budget and tooling.
3. Check the protection-strategy spread, not just the count. A requirement set that is all PRA and no DLO/CRS leaves an organization blind to compromises it couldn't prevent — the publication calls this out directly.
4. Scope aggressively with network segmentation. Isolating critical-program or HVA-related CUI into its own security domain is the publication's own recommended way to avoid applying 103 enhanced requirements across an entire environment.
5. Plan for SP 800-172A separately. Assessment procedures are a distinct publication and a distinct effort from implementing the requirements themselves.

SoftWSP's firmware and device security assessments produce the kind of penetration-resistance and resiliency evidence that SP 800-172's PRA/DLO/CRS strategy expects from critical-program and HVA-adjacent systems: see Device & Firmware Security.

This guide summarises NIST SP 800-172 Revision 3 (May 2026) and the related SP 800-171/800-172A publication pages; it is not a substitute for the full text and does not constitute compliance or legal advice.