Updated September 29, 2026
Someone told you there's a new version of the security standard, and now you don't know which one your shop should build to. Build to Rev. 2. Your contracts, your score, and any future CMMC assessment all use Rev. 2's 110 requirements. Rev. 3 doesn't apply to you until DoD changes the rule or a contract names it.
A little background, because the names are doing most of the confusing. NIST, the federal standards agency, publishes SP 800-171: the list of security requirements for companies that hold CUI (controlled unclassified information: the drawings, specs, and technical data the government marks as sensitive). The cybersecurity clause in most defense contracts, DFARS 252.204-7012 ("7012" for short), requires you to meet that list. CMMC is DoD's program for checking that you actually do, and Level 2 is the tier for companies that handle CUI. The score you post in SPRS, DoD's supplier-risk website, counts against those same requirements, 110 points at most.
Getting the version wrong costs you in two ways. You can pay a consultant thousands of dollars to rebuild your documents around a standard nobody is scoring you on yet. Or your paperwork names one version while your score uses the other, and a prime (the larger contractor you work under) holds up a subcontract to ask which one you meant.
Why NIST says Rev. 3 and DoD says Rev. 2
NIST finalized Rev. 3 on May 14, 2024, and its website now shows Rev. 2 as "Withdrawn on May 14, 2024. Superseded by SP 800-171 Rev. 3" (NIST). That sounds final, but NIST writes standards. It doesn't write your contract. DoD decides which version you're held to, and it has picked Rev. 2 twice.
The CMMC rule says the Level 2 requirements "are identical to the requirements in NIST SP 800-171 R2" (32 CFR 170.14(c)(3)). And the September 3, 2026 class deviation, the instruction DoD sent its contracting officers to put the CMMC pause into effect, still requires "baseline compliance with NIST SP 800-171 Rev 2" under 7012 (deviation 2026-O0025, Revision 3, page 2). The "Revision 3" in that document's name is DoD counting its own drafts. It has nothing to do with NIST's Rev. 3. What the pause changed →
What Rev. 3 changed, if you're curious
The owner can skip this table. Your IT lead will want it the day DoD adopts Rev. 3.
| Rev. 2 | Rev. 3 | |
|---|---|---|
| Requirements | 110 | 97 |
| Families (groups of related requirements) | 14 | 17 (adds Planning, System and Services Acquisition, Supply Chain Risk Management) |
| Specific values, such as how many minutes before a screen locks | You choose them in your own policies | Written into the requirement as "organization-defined parameters" |
| Used for CMMC Level 2 and your SPRS score | Yes | No |
Fewer requirements doesn't mean less work. NIST merged requirements together; it didn't drop them. Thirty-three Rev. 3 identifiers are marked "Withdrawn," and most were folded into others. The three new families add real obligations around planning and suppliers. The full text is in the Rev. 3 publication and NIST's release announcement.
The change most likely to reach a small shop is those parameters. Rev. 2 says to lock idle screens "after a period of inactivity" and lets your policy pick the number. Rev. 3 leaves a blank in the requirement itself. Once the blank is filled in, by the agency or by you, the number is part of the requirement and an assessor holds you to it.
The mistake we see
A System Security Plan (the SSP, the document that describes your systems and how you meet each requirement) with "NIST SP 800-171 Rev. 3" on the cover, next to a self-assessment scored against Rev. 2. Someone updated the cover to look current. Now your plan says one thing and the score you affirmed to DoD says another, and the first person to notice is an assessor or a prime's compliance reviewer.
The fix takes an afternoon. Search your SSP, your policies, and the spreadsheet you scored from for "Rev. 3" and change each one to Rev. 2.
What to do about Rev. 3 now
Very little. Write down the specific numbers your policies already commit to: how many idle minutes before a screen locks, how many failed logins before an account locks, how often you review who has access, how many days you keep logs. Assessors check that you picked these numbers even under Rev. 2 (requirement 3.1.10, objective [a], for example, asks whether the inactivity period is defined, per NIST SP 800-171A). That one-page list becomes your first draft of Rev. 3 values whenever DoD adopts it.
A full Rev. 3 gap analysis today is a consultant billing you to aim at a target DoD hasn't set.
Garde1 runs its mock assessment against the Rev. 2 baseline and labels every document it writes the same way, so your SSP, your policies, and your score all name one version. How requirements, policies, and evidence connect →
