NIST SP 800-171 Rev 3, What Changed and What It Means for Your CMMC Timeline

Someone on your team downloads the current version of NIST SP 800-171 from the NIST website, opens it, and finds 97 requirements instead of the 110 you have been working with.

There are domains that you have never documented: Planning, System and Services Acquisition, and Supply Chain Risk Management.

Next, they find brackets associated with an Organizationally Defined Parameter (ODP) sitting inside the requirements themselves, waiting for someone to fill in a value.

This is Revision 3, which has been published since May 2024. Unfortunately, it is not what your current assessment is based on.

Here is what actually changed, what it will require, and why the answer is less urgent than that download makes it look.

What is NIST SP 800-171 Rev 3

NIST SP 800-171 Revision 3 is the current published version of the standard, released in May 2024. It replaces Revision 2 as the NIST standard for protecting Controlled Unclassified Information in nonfederal systems.

Published is not the same as required. NIST writes the standard. The agency buying from you decides when a standard applies to its contracts, and that decision happens through rulemaking, not through a publication date. Rev 3 has been sitting in that gap for over two years.

So you can download Rev 3 today, read every requirement in it, and still be assessed against Rev 2 tomorrow.

That gap is closing unevenly, which is the part most contractors miss. Defense contracts still run on Rev 2. Civilian and GSA work is a different answer (we will get to that below).

How Many Requirements are in NIST SP 800-171 Rev 3

Rev 3 has 97 security requirements across 17 families. Rev 2 has 110 across 14.

That reads like a reduction of 13. It is not.

NIST withdrew requirements that were redundant or not directly tied to protecting the confidentiality of CUI. Several Rev 3 requirements merge what Rev 2 treated as separate items. At the same time NIST added new requirements and introduced parameters that the organization defines. On the surface, that may seem like the Organization Seeking Assessment, but for Department of War (DoW) customers, they have been mostly defined for you. GSA has its own ODP list as well.

The count is a function of how the material was grouped. It is not a measure of how much work it represents.

This is the most common misreading we see. If your leadership hears 97 instead of 110 and concludes that Rev 3 is lighter, correct that early. The count is smaller. The scope is broader.

NIST SP 800-171 Rev 2 vs Rev 3, What Actually Changed

Three of those rows carry most of the practical weight.

The basic and derived split is gone. Rev 2 divided each family into basic requirements and derived requirements. Rev 3 drops that structure entirely. Most SSPs list all the controls rather than organizing around that split, so for most contractors this changes the structure of the standard more than it changes the document.

Identifiers now map to NIST SP 800-53. If your organization also works with FedRAMP or FISMA standards, this reduces translation work between frameworks. If NIST SP 800-171 is the only standard you touch, it mostly means many of your requirement numbers stop matching and every cross-reference in your documentation needs rework.

Parameters are now defined, and often not by you. Under Rev 2 the parameters were genuinely individual and organization defined. Under Rev 3 they are organization-defined parameters, and for DoW and GSA customers the organization is the department. That one deserves its own section.

The 17 NIST SP 800-171 Rev 3 Control Families

Fourteen families carry over from Rev 2. Three are new. One was renamed.

Organization-Defined Parameters in NIST SP 800-171 Rev 3

Rev 2 requirements are prescriptive. The requirement exists or it does not, and you implement it. Rev 3 builds flexibility into many requirements by leaving a bracketed value to be chosen.

Instead of stating a fixed account lockout rule, a Rev 3 requirement reads more like this.

Enforce a limit of [ODP: number of consecutive invalid logon attempts] consecutive invalid logon attempts by a user during a [ODP: time period] time period.

You (or the government agency or department) pick the number and period, then both become part of your documented security program. Appendix D of NIST SP 800-171A Rev 3 lists all of the ODPs in one consolidated place.

Three obligations follow

Your System Security Plan has to record the specific value that applies, not just confirm the requirement is implemented. Your systems have to enforce that value exactly, so if the SSP says five failed attempts, the configuration says five. And an assessor working from NIST SP 800-171A Rev 3 checks both sides, comparing what you wrote against what your systems actually do.

A mismatch between the two is a finding, even when the implemented value is perfectly reasonable on its own.

Where the parameters cluster

The number that may apply to you depends on your environment and your scope. Treating these requirements as a fill-in-the-blank exercise is the fastest way to fail those objectives.

Keep a single parameter register. One table listing every value your organization has chosen, referenced from the SSP rather than buried in prose across forty documents. When a value changes, you update one row and you know exactly which configurations have to follow. The Kieri Compliance Documentation is built this way for exactly that reason.

The New Rev 3 Control Families: Planning, System and Services Acquisition, and Supply Chain Risk Management

Planning, System and Services Acquisition, and Supply Chain Risk Management have no Rev 2 equivalent. This could mean creating new documents instead of editing existing documentation.

Planning (PL)

PL makes security planning an explicit, auditable requirement rather than an assumed precondition. It covers the SSP, your policy documents, and rules of behavior, each as its own requirement:

• A formally structured SSP documenting your security architecture decisions, reviewed at defined intervals, with a defined process for updating it when your environment changes.
• Policy documents, updated under a requirement separate from the one covering the SSP.
• Rules of behavior your users have acknowledged, also a separate requirement.

Most organizations with a well maintained SSP already satisfy the intent. Rev 3 asks you to prove it.

System and Services Acquisition (SA)

SA covers systems engineering principles, replacing legacy hardware, and making sure external service providers, rather than every vendor you work with, meet certain security requirements. For DoW that means FedRAMP Moderate or equivalent for cloud service providers and NIST SP 800-171 for everyone else. It is not really a change from Rev 2, it just has a control spelled out for it now. You need criteria for assessing a service before you adopt it, security requirements written into external service provider contracts, and a process for revisiting those assessments when a provider’s posture changes. If you have already worked through the external service provider requirements in the CMMC Program Rule, there is meaningful overlap here, which could indicate that the work has already been done.

Supply Chain Risk Management (SR)

SR covers the plan to manage, mitigate and identify supply chain risk:

• A plan to manage supply chain risk, developed, reviewed, updated, and protected from unauthorized disclosure.
• Risk mitigation through acquisition strategies, tools and methods that identify, protect against and mitigate supply chain risks.
• Risk identification through a process to identify and address weaknesses and deficiencies, and to enforce the ODP supply chain risks.

The ODPs here are integrating supply chain risk management into procurement and defining the processes that make suppliers disclose significant vulnerabilities and incidents.

SR is the domain that people underestimate. It is not a setting you configure once. It involves purchasing and legal in addition to IT. Those conversations take longer than a technical change. If you are mapping your Rev 3 gap, start here.

Does CMMC Use NIST SP 800-171 Rev 2 or Rev 3

As of August 2026, Revision 2 is still used by CMMC.

The 32 CFR Part 170 CMMC Program Rule is written against NIST SP 800-171 Revision 2. Moving to Revision 3 is not a memo. It requires a rulemaking update that formally adopts Rev 3, updated assessment guidance, retrained assessors, revised SPRS scoring, and a defined transition period during which organizations can actually implement the changes.

None of those steps has a published date.

On July 13, 2026 the Department of War suspended CMMC Phase 2. This included the third-party certification milestone scheduled for November 10, 2026, and opened a review of the program. Phase 2 is only about the requirement for a third-party assessment, and Phase 3 is about CMMC being fully integrated into the contracting process. Neither one is a Rev 3 track.

Two things about that review matter here.

The first is what did not change:

• Phase 1 self-assessment remains enforced.
• DFARS 252.204-7012 remains enforced.
• NIST SP 800-171 Revision 2 remains the enforced standard.

The Department paused a verification mechanism. It did not pause the obligation to protect CUI.

The second is easy to miss: The Request for Information issued alongside the suspension asks which requirements deliver the most measurable risk reduction and which impose the greatest burden for the least benefit. That question reaches the requirement set itself, not only the assessment process. This means that the review may not just be about who verifies your compliance, but potentially the standards themselves.

Read all of that as extra allotted time to align on Rev 3, not as a reason to stop.

Where NIST SP 800-171 Rev 3 Is Already Required

This is the part that gets lost in the CMMC conversation. Rev 3 is not waiting everywhere. It is waiting on the Department of War.

GSA has already moved. Since January 5, 2026, GSA contractors handling CUI work to NIST SP 800-171 Rev 3 plus selected controls from 800-172, under GSA’s IT security procedural guides. That requirement carries an independent third-party assessment rather than self-attestation, a set of controls that must be in place before award, and a one hour incident reporting window instead of the 72 hours DFARS allows.

The FAR CUI rule points the same direction. The FAR Council published a revised proposed rule on June 23, 2026 that would require Rev 3 for any system holding CUI, and it applies to civilian and defense contractors alike. The Council has signaled it expects to finalize before the end of 2026 with no phase-in period.

So, the honest answer to “When do I need Rev 3?” depends on who you sell to. If your work is entirely DoW, you may have time. If you hold a GSA schedule or do civilian agency work, Rev 3 is either your standard today or close to it.

Check your contracts before you decide this is a next-year problem.

Does NIST SP 800-171 Rev 3 Change Your SPRS Score

Not today. SPRS scoring runs on the DoD Assessment Methodology, which is built around the 110 Rev 2 requirements and their point weights. A 97 requirement standard with different identifiers cannot drop into that scoring model unchanged.

Revised scoring is one of the steps that has to happen before Rev 3 applies to defense contracts, and it has not been published. Keep scoring and posting against Rev 2.

What Defense Contractors Should Do About Rev 3 Right Now

The answer depends on where you are.

If you are not yet compliant with Rev 2, work on Rev 2 and nothing else. Your SPRS score, your SSP, your POA&M, and any assessment in the near term are all measured against 110 requirements. Building toward a requirement set nobody is assessing produces documentation that will not match what an assessment asks for.

If you are already compliant or certified, start with the three new families. PL, SA, and SR are where your documentation says nothing at all, so that is where a few hours of review returns the most information. After that, review your existing requirements. If you work under DoW contracts, the DoW has already set almost all of the ODPs, so go through the newly added and significantly changed controls that appear throughout and make sure you are following them.

If you are mid-implementation, build with Rev 3 in mind wherever the extra effort is small. Structure your SSP so parameter values have a place to live. Keep a list of the sources where your evidence comes from rather than the old evidence itself, because most Rev 3 requirements map back to something you already do.

If you sell to civilian agencies or hold a GSA schedule, treat Rev 3 as current work rather than planning work, and read your contract language first.

What Carries Forward From Your Rev 2 Program

One thing worth saying plainly: Most of a solid Rev 2 program carries into Rev 3.