NIST SP 800-171 Rev. 2 vs Rev. 3 for CMMC in 2026

Rev. 3 is final, but final publication is not the same as contract adoption

In 2026, the answer can still be 'no' for CMMC work. The Department's current CMMC page continues to describe Level 2 against the 110 requirements in NIST SP 800-171 Rev. 2 while Phase I remains active. The practical risk is not ignorance of Rev. 3; it is mixing two baselines in one SSP, score, or evidence set and then losing track of what was actually assessed.

NIST published SP 800-171 Rev. 3 and SP 800-171A Rev. 3 on May 14, 2024. Rev. 3 reorganized the requirement set, aligned more directly with NIST SP 800-53 Rev. 5, introduced organization-defined parameters, and changed the way tailoring and requirements are expressed. Teams preparing for the future should read it as the current NIST standard, not as an experimental draft.

A NIST publication, however, does not rewrite an existing contract by itself. Defense acquisition clauses, class deviations, CMMC program materials, and the solicitation determine which baseline applies to a specific representation or assessment. Before changing an assessment workbook because 'Rev. 3 is newer,' identify the authority that makes Rev. 3 the required baseline for that work.

Why CMMC can still point to Rev. 2

For Phase I, the official program page still places Level 2 Self against the 110 NIST SP 800-171 Revision 2 requirements. That is a strong reason to keep a Rev. 2 CMMC evidence set intact when performing a current CMMC self-assessment. Replacing requirement IDs with Rev. 3 references could make the record diverge from the program being assessed.

This is not a claim that Rev. 2 is technically newer or preferable. It is a baseline-control issue. One document answers 'what does NIST currently publish?' and another answers 'what does this contract or CMMC assessment currently require?' Mature compliance programs keep both questions visible instead of forcing one answer to serve both.

The most dangerous mistake is silent mixing

A common transition error is to update policies to Rev. 3 language, keep a Rev. 2 score sheet, and attach evidence named with Rev. 3 control references. The files may look modern, but the assessment trail becomes hard to follow. An internal reviewer cannot tell whether a gap was truly closed or simply renumbered into a different structure.

Label every major artifact with the baseline it supports. The SSP title page, assessment workbook, POA&M, evidence index, control crosswalk, and management summary should state 'Rev. 2 CMMC baseline' or 'Rev. 3 transition work' where appropriate. A filename suffix is not enough if the document itself will be separated from the folder later.

Build a crosswalk instead of rewriting the live baseline

A practical migration project starts with a crosswalk. For each current Rev. 2 requirement, identify the Rev. 3 relationship, note new or materially changed expectations, record any organization-defined parameter that will require a decision, and identify which policies, configurations, or evidence will need work. Keep this in a transition workspace rather than editing the production assessment workbook in place.

The crosswalk should include implementation impact, not just control numbers. If a Rev. 3 requirement changes how the organization manages configuration, supply-chain risk, planning, or monitoring, name the system owner and the operational change. This keeps the transition from becoming a spreadsheet exercise detached from the environment.

Use one evidence repository with explicit baseline tags

You do not need duplicate copies of every screenshot. Many artifacts can support both revisions, but the index should say which requirement mapping is being claimed. For example, an identity configuration export can remain one file while the evidence index contains separate Rev. 2 and Rev. 3 mappings. This reduces storage clutter without blurring the assessment logic.

When evidence is truly revision-specific, keep it separate. A Rev. 3 organization-defined parameter decision, new policy language, or changed assessment object deserves its own record. Reviewers should never have to infer which version was in force from the date alone.

Transition only when the governing requirement says to

Before changing the formal CMMC or contract baseline, check the latest official CMMC page, the acquisition clauses in the solicitation or contract, any relevant class deviation or transition memorandum, and contracting-officer direction that applies to the procurement. Record the source and date of the decision in the SSP revision log.

Until then, prepare for Rev. 3 in parallel. Closing technical weaknesses that are sensible under both versions is rarely wasted effort, but representations and scores must remain tied to the baseline that actually governs them. Prepare for the transition without creating a hybrid record that accurately represents neither Rev. 2 nor Rev. 3.

A clean dual-baseline workflow for 2026

Use two controlled workspaces. The first is the active CMMC baseline: Rev. 2 requirement references, current SSP, current assessment workbook, current POA&M records, and evidence mappings used for Phase I. The second is the Rev. 3 transition workspace: crosswalk, gap analysis, planned policy changes, organization-defined parameter decisions, and future architecture work.

Only promote a Rev. 3 change into the active baseline when the governing requirement changes or when the technical improvement is independently useful and can be documented without corrupting the current assessment logic. For example, a stronger access-review process can improve security now, but the CMMC workbook should still map that process to the Rev. 2 requirement being assessed.

Keep migration work out of the live score

Name owners for both workspaces. One person should control assessment integrity; another may lead transition planning. Without ownership, the easiest document to find often becomes the unofficial source of truth, and teams begin quoting a Rev. 3 crosswalk during a Rev. 2 assessment or vice versa.

At every major review, ask two separate questions: 'Are we accurate against the baseline we must represent today?' and 'What do we need to change for the next baseline?' Keeping those questions separate allows the organization to modernize without making current compliance records internally contradictory.

A migration backlog should distinguish three kinds of work: changes required by the current contract baseline, improvements that make sense regardless of revision, and Rev. 3-specific changes being staged for future adoption. Without those labels, teams can spend scarce engineering time on a future-state item while an existing Rev. 2 gap remains open. The crosswalk is therefore more than a compliance document; it is a prioritization tool that lets leadership see why a technical change is being funded now rather than later.

Common questions

Official sources used for this guide

Open the primary source before making a contract-specific decision. Regulations and program implementation can change.