What the heck is NIST 800-171 revision 3?

Government contractors handling technical or mission-related information during the performance of their contracts need to be cognizant of the National Institute of Standards and Technology (NIST) Special Publication 800-171. NIST 800-171 establishes a cybersecurity standard for the protection of Controlled Unclassified Information (CUI) when handled — stored, processed, or transmitted — in non-Federal information systems. In May 2024, NIST released 800-171 revision 3, which is significantly different than 800-171 revision 2. While for the time being under the Department of War’s (DoW) Cybersecurity Maturity Model Certification (CMMC) the Defense Industrial Base (DIB) members are only beholden to revision 2, the rest of the Federal contracting supply chain must abide revision 3, and eventually the DIB will have to as well. This post explores the differences between revision 3 and revision 2, and describes the most challenging aspects for small businesses implementing revision 3.

Overview of the 800-171 standard

NIST sets Federal government technology standards. As part of this role, it is in charge of establishing cybersecurity standards for Federal government information. When properly implemented, these standards help ensure the confidentiality (secrecy), integrity (immutability), and availability (there when you need it) of sensitive information.

The NIST 800-171 standard establishes a set of requirements that Federal government contractors must meet to ensure adequate protection of Controlled Unclassified Information (CUI). 800-171 is a “tailored” set of requirements, distilled specifically for CUI protection from NIST’s much larger 800-53 source requirements catalog. Federal government-owned IT systems must implement much larger subsets of the 800-53 requirements; 800-171 is a more approachable set tailored just for non-Federal (e.g. private sector) IT systems.

NIST periodically updates all its standards documents. According to its press release, NIST released 800-171 revision 3 to more closely “match the language of the source catalogs [800-53]”, and to remove “ambiguity in the security requirements and uncertainty in security requirement assessments”. We’ll explore the ramifications of these changes below. By the way, you may see revision 3 referred to as “800-171 rev 3” or even concatenated as “800-171r3”.

CUI is unclassified (so not TOP SECRET, SECRET, or CONFIDENTIAL) information of a technical or mission-related nature and is more sensitive than your run-of-the-mill Federal Contract Information (FCI). You can learn more specifics on how to identify CUI here. Since CUI is sensitive it requires significant protective safeguards. The specific safeguards are referred to in the 800-171 standard as “controls”. These controls range in a spectrum between physical security — e.g. locking doors and windows on the facilities in which CUI is handled — to logical or digital security — e.g. installing endpoint protection (antivirus) on workstations, servers, and mobile devices. There are around 100 or so controls in the 800-171 standard, depending on the revision.

Federal government contractors that handle CUI will be held contractually accountable for implementing the 800-171 standard, e.g. by the DoW CMMC. In fact, the DoW estimates about 35% or so of its supply chain — the DIB — handles CUI and therefore needs to implement 800-171.

Whereas the controls describe what must be done to protect the CUI, NIST also publishes the companion 800-171A document which lists a set of assessment objectives for each control, which allows us to verify that the control was implemented effectively. There are several hundred assessment objectives in 800-171. It is crucial for Federal contractors to understand the differences between controls and assessment objectives, and to note the number of assessment objectives in the standard. While the controls are useful to understand what the requirement is, ultimately businesses need to meet each of the assessment objectives. The devil of cybersecurity compliance is in the details, and the assessment objectives are the details.

While we won’t explore all of the 800-171 controls or assessment objectives in this post, we will explore the major differences between 800-171 revision 2 and revision 3. If you and your team are interested in a deep dive into the controls and how small businesses can implement them practically, we suggest you explore our CMMC Readiness Training options.

Major differences between 800-171 revisions 2 and 3

If you’ve been working on a NIST 800-171 revision 2 implementation for a while, you may be shocked by the differences in revision 3. With revision 3, NIST has more closely aligned the format and structure of 800-171 with its “parent” 800-53 publication. The major formatting changes include:

Changes to numbering structure

In revision 2, control identifiers made reference to document section, control family, and then the control number. Since all controls were listed in Section 3, they all started with “3”. Then the family number came next, and finally the control number within the family. A “family” is a group of similar controls. For example 3.1.1 is the first control in the first family of controls, namely the Access Control (AC) family. Access Control had 22 total controls, so the IDs range from 3.1.1 to 3.1.22.

Different families have different numbers of controls. There were 14 families of controls, so, for instance, you had 3.5.3 (the requirement for multifactor authentication, which is the third control in the fifth family: Identification and Authentication, or IA), 3.8.9 (secure backups, which is the ninth control in the eighth family: Media Protection, or MP), all the way up to 3.14.7 (identifying unauthorized system use, which is the seventh and last control in the fourteenth and last family: System and Information Integrity, or SI).

With revision 3, the structure, or “schema”, is similar (e.g. all the controls are still listed in Section 3), but NIST prefaced each identifier segment with a zero if it was a single digit. So 3.1.1 becomes 03.01.01, while 3.1.22 becomes 03.01.22. Likewise we now have 03.08.09 and 03.14.07. (Actually, there no longer is a 03.14.07, just a 03.14.06 and a new 03.14.08. Confused? Yeah…we didn’t say these changes make things better, now did we? See the “Control consolidation” section below for more information on numbering sequencing.) An image below shows the difference in the numbering schema.

Control name addition

In addition to a control description, each control has a simple name in 800-171 rev 3. So, for instance, in rev 2, control 3.6.3 in the Incident Response family had the description “Test the organizational incident response capability.” In rev 3 that same control (now numbered, you guessed it: 03.06.03) has the new name “Incident Response Testing” with the description of “Test the effectiveness of the incident response capability [Assignment: organizationally-defined frequency].” You can see a side by side comparison in the screenshot below.

BTW, the “[Assignment: organizationally-defined frequency]” part of the 03.06.03 description is a placeholder for an organizationally defined parameter, or ODP. See the next toggle section for more info on ODP.

Inclusion of Organizationally Defined Parameters (ODP)

There are a lot of variable parameters in a typical cybersecurity policy. For instance, how frequently should your organization require users to change passwords? How long should the passwords be? How complex should those passwords be?

Or, sticking with the example given in the previous section, how frequently should your organization test its incident response plan (IRP)?

In past revisions, there was no clear guidance on when a policy required parameter selection, nor on what those selections should be. NIST 800-171 revision 3 introduced organizationally defined parameters or “ODP”, which alleviates some of that confusion. ODP are one of the major new additions to 800-171 revision 3.

ODP under a control indicate where an organization must define a policy parameter, such as task frequency, task responsibility, policy strictness, and so on. In the case of Federal government contractors, the “organization” that sets these parameters is not us, but is instead our customer, the Federal agency. And kindly enough, shortly after NIST published rev 3, the DoW (DoD) published its corresponding ODP definitions. This takes the guess work out of determining what policies will be acceptable in a CMMC assessment.

A screen shot below shows how the new ODPs look for the 03.06.03 control for testing the incident response capability. Some controls have a lot of ODP, some a few or one, and some none. Just depends on the control. Our Totem™ CCM tool shows exactly which controls contain ODP and populates the DoD/DoW ODP text for you. There are a total of 88 ODP in rev 3.

In addition to changes in format, 800-171 revision 3 also as significant changes in content when compared to revision 2. While there was some consolidation and even elimination of controls, major new control families were added that significantly increase the work required to implement 800-171 revision 3. Let’s explore those changes:

Control consolidation

Overall, 800-171 revision 3 only has 97 controls compared to the 110 controls in rev 2. NIST “withdrew” or consolidated several controls to whittle down the overall number of controls, even though there are three new control families.

A great example of control consolidation can be found in the System & Communications Protection family (family 13). Revision 2 control 3.13.5, “Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks” (for network admins this is the requirement to operate a DMZ) was incorporated into control 03.13.01 in revision 3. Control 03.13.01 is now named (see above for an explanation of control names) “Boundary Protection” and includes the 800-171A revision 3 assessment objective “Subnetworks are implemented for publicly accessible system components that are physically or logically separated from internal networks.” Sounds familiar huh?

NIST’s withdrawal and consolidation of controls leaves gaps in the control number sequence, as shown in a screen shot below. So looking at the control sequence in 800-171 revision 3 can leave folks scratching their heads. But once you understand the mechanism behind those gaps you get used to it.

Speaking of assessment objectives, we should talk a bit about how, despite rev 3 containing fewer controls than rev 2, it actually has many more assessment objectives. If we include ODP as assessment objectives (we do here at Totem Tech), then the number jumps from 320 to 509. That means revision 3 represents a 37% increase in the implementation and assessment burden. Many organizations, especially small businesses, are not prepared for the increase in compliance burden represented by 800-171 revision 3. Many of those new assessment objectives are introduced by the new controls in the new control families in rev 3, so let’s take a look at those.

Additional control families

800-171 revision 3 introduces three new control families:

Planning (family 15),
System and Services Acquisition (family 16), and
Supply Chain Risk Management (family 17)

Adding these families now fully aligns the number of security control families in the 800-171 standard to the “parent” 800-53 standard.

Some controls have been shuffled from other families into one of these new families. For instance, 3.12.4, the requirement to maintain a System Security Plan (SSP) moved from the Security Assessment family (12) to the new Planning family (15). But there are new controls as well. In fact, of the 97 total controls in 800-171 revision 3, seven (7%) of them are introduced with these new families, and account for 43 (8%) of the new assessment objectives.

Some of these new families and controls will be pretty simple to meet, for example, control 03.15.03 “Rules of Behavior”, which requires an organization to establish, publish, review, and receive acknowledgement of “rules that describe the responsibilities and expected behavior for system usage.” This may be a new business process for some orgs, but it’s not hard to do.

Other families and controls will be much more challenging, e.g., the Supply Chain Risk Management (SCRM) requirements. More on that in the “Challenges” section below.

New controls and new control requirements

Several control families extant in 800-171 revision 2 now have additional controls in revision 3. For example, even though two controls in the Configuration Management family (family 4) were consolidated, NIST added three new controls to the family:

03.04.10 “System Component Inventory”
03.04.11 “Information Location”
03.04.12 “System and Component Configuration for High-Risk Areas”

Of these, in 03.04.10, NIST just broke apart a previous control into two parts, 03.04.11 is (in Totem’s opinion) rather redundant with other existing controls (03.04.01, 03.04.03, 03.04.10), and really only 03.04.12 represents anything novel in revision 3.

And there are some controls that, even though not new, have been modified. For instance (still in the Configuration Management family), control 03.04.08 has changed to only accept allow-by-exception (“allow- or white-listing”) software execution polices. Previously in rev 2, deny-by-exception (“deny- or black-listing”) was an acceptable approach. Allowlisting is a challenging technology to implement, especially for small businesses.

You can sense a theme to this post, eh? Even though there are fewer overall controls in revision 3, the new controls make things more complicated and more challenging to implement.

The table below summarizes some statistical differences between NIST 800-171 rev 2 and rev 3.

800-171 Revision	Publication Date	Applicability	# of control families	# of controls	# of assessment objectives	# of ODP
Revision 2	February 2020	DoW contracts only	14	110	320	none
Revision 3	May 2024	All Federal contracts	17	97	509	88

Major small business challenges with 800-171 rev 3

In addition to some of the challenges explored above (e.g. allowlisting), we’ll briefly explore some of the most difficult aspects of implementing 800-171 revision 3, with a focus on how rev 3 will affect small businesses. We’ll list these by control family and number:

Identification and Authentication family (05)

03.05.02 “Device Identification and Authentication”: rev 3 removes language about device verification and now requires device authentication, e.g. 802.1x, RADIUS, Kerberos. Looks like filtering by MAC will not be sufficient for this control any longer.

Physical Protection family (10)

03.10.01 “Physical Access Authorizations”: organizations are required to have staff use “authorization credentials” (identification badges, identification cards, and smart cards) for physical access to systems, at least systems that handle CUI. This means you will have to issue badges, etc. to staff.
03.10.02 “Monitoring Physical Access”: explicitly requires monitoring of the facility, especially publicly accessible areas. We are also required to periodically review the physical access logs (required to be generated by 03.10.07), not just generate them.
03.10.07 “Physical Access Control”: we are required to control facility egress, although we are still allowed to log only access to entry or egress. Food for thought: how do you “control egress” in a fire evacuation scenario?
03.10.08 “Access Control for Transmission”: we are required to control physical access to “output devices” e.g. “monitors, printers, scanners, audio devices, facsimile machines, and copiers.” Taken together, 03.10.01, 03.10.07, and 03.10.08 strongly suggest we will need badge readers / keypads and differentiated access control for areas where CUI is present. If CUI is present in your whole facility–access to your whole facility will require more sophisticated access control than keyed locks, and you’ll not be able to leave doors unlocked.

Security Assessment and Monitoring family (12)

03.12.05 “Information Exchange”: organizations must establish Service Level Agreements (SLA), Memoranda of Understanding (MOU), Interconnection Security Agreements (ISA), including Interface Control Descriptions (ICD) prior to exchanging CUI with any other organization. However, the ODP text suggests a simple NDA may suffice to meet this control, depends on the contract.

System and Communications Protection family (13)

03.13.11 “Cryptographic Protection”: for those of you hoping 800-171 revision 3 would do away with the FIPS-validated crypto requirement…sorry but nope!

System and Services Acquisition family (16)

03.16.03 “External System Services”: requires us, in addition to ensure cloud services used to handle CUI are FedRAMP’d, that we document and monitored shared responsibilities with all our external service providers, including our IT MSPs.

Supply Chain Risk Management family (17)

This may end up being the single most burdensome requirement family in all of NIST 800-171. Any business with more than a a few suppliers supporting their Federal government work may realize the need to hire additional staff just to manage this capability. This family requires:

03.17.01 “Supply Chain Risk Management Plan”: we are explicitly required to maintain a Supply Chain Risk Management (SCRM) plan. This has been a stated emphasis of the entire Federal gov’t, especially the DoW, so this is no surprise, but this is going to be a large undertaking for the average small business. A Totem™ subscription includes access to our SCRM Plan template.
03.17.02 “Acquisition Strategies, Tools, and Methods”: we must identify and implement Acquisition Strategies, Tools, and Methods for SCRM. Redundant control, as this would already be done in an SCRM Plan, although this control is a little more specific in risk mitigation techniques, such as requiring tamper-evident packaging, counterfeit product inspection, etc.
03.17.03 “Supply Chain Requirements and Processes”: we must identify and implement Supply Chain Controls and Processes for SCRM. Redundant control, as this would already be done in an SCRM plan.

Totem Technologies' approach to 800-171 revision 3

As shown throughout this post, Totem Technologies has covered many aspects of 800-171 implementation through previous blog posts and tool provisioning. This approach will continue with revision 3. Rev 3 will be a major undertaking, however, especially for small businesses, so there is no time to waste. We estimate implementing rev 3 to be at least a 35% more effort than for rev 2.

The Totem™ tool includes the 800-171 revision 3 control set natively, so if you’re planning on doing business with the Federal government, you can get to planning your company’s rev 3 implementation with a subscription. Most Federal agencies aside from the DoW explicitly require the implementation of rev 3, e.g. the GSA.

Totem™ tool subscribers with an existing 800-171 rev 2 System Security Plan (SSP) will have their SSP migrated and mapped to revision 3 when the time is right. Tool subscribers also get access to our monthly Subscribers’ Forum, which is a great place to ask questions about rev 2 –> rev 3 mapping and transitions.

If you and your team are interested in learning more about the 800-171 revision 3 controls and how small businesses can implement them practically, we suggest you explore our CMMC Readiness Training options.

Good Hunting!

–Adam