Defence contractors are still assessed against NIST SP 800-171 Revision 2 while Revision 3 has been the current NIST publication since May 2024, and the gap between the two is wider than a renumbering. Revision 3 replaces fixed wording with organisation-defined parameters (ODPs), withdraws or folds 33 requirement identifiers into others, and adds three families that Revision 2 never had: Planning, System and Services Acquisition, and Supply Chain Risk Management. This guide is for compliance leads, system owners and CMMC programme managers who must keep a Revision 2 assessment clean today while preparing for the switch. It covers what ODPs are and how to set them, what the three new families ask for in practice, how to run a dual-track crosswalk, and how to measure readiness. For the DFARS, CMMC and SPRS background, see the NIST SP 800-171 and CMMC 2.0 Guide; for assessment procedures, see the NIST SP 800-171A Rev 3 Assessment Guide.
Key takeaways
- Revision 2 still governs DoD work. On 9 November 2026 the DoD CIO "About CMMC" page stated that DoD will enforce compliance with "NIST 800-171 Rev 2" and that CMMC is paused in Phase 1; it does not mention a move to Revision 3.
- ODPs are the biggest practical change. NIST's OSCAL catalogue for Revision 3 carries 88 parameter entries across the 97 active requirements, each one a value (a frequency, a threshold, a list) that someone must choose, document and evidence.
- DoD has already chosen its values. A DoD memo dated 15 April 2025, "DoD Organization-Defined Parameters for NIST SP 800-171 Revision 3", sets the values DoD expects, in preparation for a future switch; law firm summaries describe them as not yet in force.
- The three new families are mostly paperwork that must become practice. Planning (03.15), System and Services Acquisition (03.16) and Supply Chain Risk Management (03.17) add nine requirements covering policy, the system security plan, rules of behaviour, engineering principles, unsupported components, external services and supply chain risk.
- Run one evidence library, tagged twice. Document controls to Revision 2 numbering for today's assessment, with a Revision 3 column and the DoD ODP value beside each, so the switch is a documentation change rather than a rebuild.
Why the transition is a live problem
NIST published SP 800-171 Revision 3 as final on 14 May 2024, superseding Revision 2 (January 2021). NIST's announcement lists the significant changes: requirements restructured to show direct alignment with SP 800-53 Revision 5, the introduction of ODPs, new tailoring criteria, recategorised controls, outcome-oriented guidance, and a CUI Overlay showing the SP 800-53 control tailoring behind each requirement. The companion SP 800-171A Revision 3 adds ODP determination statements to the assessment procedures.
DoD contracts did not follow. DFARS 252.204-7012 points to the version "in effect at the time the solicitation is issued", but DoD class deviation 2024-O0013 (May 2024) keeps contractors on Revision 2, and the CMMC rule at 32 CFR 170 incorporates Revision 2 and the June 2018 SP 800-171A by reference. The result is two live baselines: Revision 2 for DoD, Revision 3 for civilian agency contracts that cite the current publication and for anyone planning ahead. Contractors serving both, and those who expect DoD to move after its CMMC review, need a plan that does not break today's SPRS score.
| Question | Revision 2 answer | Revision 3 answer |
|---|---|---|
| Which DoD contracts use it now? | DFARS 252.204-7012 and CMMC Level 2 (via class deviation 2024-O0013 and 32 CFR 170) | None as of 9 November 2026, per the DoD CIO page |
| Who sets the values (frequencies, thresholds)? | Mostly fixed in the requirement wording or left implicit | The organisation or the federal agency, through ODPs; DoD published its values in April 2025 |
| Active requirements | 110 | 97 (33 identifiers withdrawn in the OSCAL catalogue) |
| Families | 14 | 17 (adds 03.15 Planning, 03.16 System and Services Acquisition, 03.17 Supply Chain Risk Management) |
| Assessment objectives | SP 800-171A (June 2018) | SP 800-171A Revision 3 (May 2024), with ODP determination statements |
Organisation-defined parameters: what they are and how to set them
An ODP is a placeholder inside a requirement that must be filled with a specific value. In NIST's OSCAL catalogue each ODP has an identifier such as A.03.01.08.ODP[01] and a determination statement, for example "the number of consecutive invalid logon attempts by a user allowed during a time period is defined." Under Revision 2 an assessor checked that you had a lockout; under Revision 3 the assessor first checks that the value is defined, then that the system enforces that value.
Counting the parameters in the official Revision 3 OSCAL dataset gives 88 entries. They cluster in Access Control (18), Configuration Management (12), Identification and Authentication (8), Awareness and Training (8), Incident Response (7) and Audit and Accountability (6). Maintenance has none.
| Requirement | What the ODP asks you to define | Where to evidence it |
|---|---|---|
| 03.01.08 Unsuccessful Logon Attempts | Number of consecutive invalid attempts, the time window, the action taken (lock or delay) and the lock period | IdP and directory lockout policy exports, matched to the SSP value |
| 03.03.01 Event Logging | Event types selected for logging and how often that list is reviewed | Logging standard, SIEM source list, review record |
| 03.05.01 User Identification and Authentication | Circumstances that require re-authentication | Conditional access and session policies |
| 03.05.07 Password Management | How often the compromised-password list is updated, and the composition rules | Password policy, breached-password screening configuration |
| 03.13.11 Cryptographic Protection | The types of cryptography used to protect CUI confidentiality | Crypto standard and module certificates; Revision 2 3.13.11 named FIPS-validated cryptography directly |
| 03.15.01, 03.15.02, 03.15.03 | Review frequency for policies, the SSP and rules of behaviour | Document control metadata and review sign-offs |
| 03.16.03 External System Services | The security requirements external service providers must meet | Contracts, provider attestations, shared responsibility matrix |
| 03.17.03 Supply Chain Requirements and Processes | Security requirements that protect against supply chain risks | Supplier security requirements, purchase controls |
Using the DoD values
The DoD memo of 15 April 2025 is hosted by the DoD CIO. We could not retrieve the PDF itself when this guide was written, so the following comes from law firm summaries. Crowell & Moring reports that DoD's values include using FIPS-validated cryptography, requiring external service providers to meet SP 800-171 Revision 2, and integrating supply chain risk management into procurement policies. Holland & Knight and the Government Contracts Law blog both describe the memo as preparation for Revision 3 and say Revision 2 remains the standard under DFARS 7012 and CMMC for now. Read the memo yourself before adopting any value.
- DoD contractors: adopt the DoD value wherever it is at least as strict as your current practice. Where it is stricter (inactive account timers are a common example), log the gap on a readiness tracker, not on your Revision 2 POA&M, because it is not yet a Revision 2 finding.
- Civilian agency contractors: check the contract and any agency guidance first. Where the agency is silent, our recommendation is to use the DoD values as a defensible default and record the rationale in the SSP.
- Everyone: one value per ODP, recorded once (in the SSP or a parameter register it references), and enforced by configuration that can be exported. A value that lives only in a policy document will fail the "test" assessment method.
The three new families in practice
Each new family maps to SP 800-53 Revision 5 controls, which is where to look for implementation detail. Several Revision 2 requirements moved into them: Revision 2 3.12.4 (system security plan) now sits at 03.15.02, and the OSCAL catalogue marks 03.12.04 as withdrawn and addressed by 03.15.02.
| Requirement | What it says (summarised) | SP 800-53 r5 source | Practical evidence |
|---|---|---|---|
| 03.15.01 Policy and Procedures | Develop, document and disseminate the policies and procedures needed to satisfy the requirements; review them at a defined frequency | The -1 policy controls across families | Policy set mapped to all 17 families, review dates |
| 03.15.02 System Security Plan | An SSP that defines components, information types, specific threats, the operating environment and connections, safeguards in place or planned, and people in system roles; reviewed and protected from unauthorised disclosure | PL-2 | SSP with threat section and component inventory, access-restricted |
| 03.15.03 Rules of Behavior | Rules for system use and protecting CUI, provided to users, with documented acknowledgement before access | PL-4 | Signed acknowledgements linked to account provisioning |
| 03.16.01 Security Engineering Principles | Apply defined security engineering principles when developing or modifying the system | SA-8 | Named principles (for example least privilege, defence in depth) in design and change templates |
| 03.16.02 Unsupported System Components | Replace components when support ends; provide mitigations or alternative support where replacement is not possible | SA-22 | End-of-support register, compensating controls, replacement plan |
| 03.16.03 External System Services | Require providers that process, store or transmit CUI to meet defined requirements, document shared responsibilities, and monitor provider compliance continuously | SA-9 | Shared responsibility matrix, provider attestations, monitoring record |
| 03.17.01 Supply Chain Risk Management Plan | A plan covering supply chain risk across the life cycle from R&D to disposal, reviewed at a defined frequency and protected | SR-2 | Approved SCRM plan with owner and review history |
| 03.17.02 Acquisition Strategies, Tools, and Methods | Use acquisition strategies, contract tools and procurement methods to identify and mitigate supply chain risk | SR-5 | Procurement checklist, contract clauses |
| 03.17.03 Supply Chain Requirements and Processes | A process for finding and fixing supply chain weaknesses, and defined requirements to limit supply chain harm | SR-3 | Supplier assessment records, SBOM or provenance checks where relevant |
Two requirements tend to surface real work. 03.16.02 needs an inventory that knows end-of-support dates, which most organisations only hold for operating systems; extend it to firmware, network devices and libraries. 03.16.03 asks for continuous monitoring of providers, not a one-off questionnaire: a cloud service holding CUI needs a named owner who reviews its attestation and incident notices on a schedule. For depth on supply chain programmes, see the NIST SP 800-161 Cyber Supply Chain Risk Management Guide and the SBOM Guide.
Withdrawn and consolidated requirements
Revision 3 does not drop the substance of most withdrawn identifiers; it moves it. The OSCAL catalogue records where each went. Examples worth knowing when you build the crosswalk:
- Remote access: 03.01.14 and 03.01.15 (managed access control points, privileged remote commands) are addressed by 03.01.12 Remote Access.
- Passwords: 03.05.10 is addressed by 03.05.07 Password Management, which now also requires a maintained list of commonly used, expected or compromised passwords, a check against it at creation and change, and a new password on first use after account recovery. See the Password Policy Guide (NIST-aligned).
- Boundary protection: 03.13.05 is addressed by 03.13.01, and 03.13.07 (split tunnelling) by 03.01.12, 03.04.02 and 03.04.06.
- Least functionality and user-installed software: 03.04.09 is addressed across 03.01.05 to 03.01.07 and 03.04.08.
- Physical protection: 03.10.03 to 03.10.05 (escorts, audit logs, physical access devices) are addressed by 03.10.07.
- Malicious code: 03.14.04 and 03.14.05 are addressed by 03.14.02.
Some withdrawn identifiers (for example 03.05.08, 03.05.09 and 03.13.14) carry no pointer in the catalogue. NIST's Revision 2 to Revision 3 change analysis spreadsheet, linked from the publication page, gives the reason for each; use it rather than guessing.
A dual-track transition plan
- Freeze the Revision 2 baseline. Confirm your SPRS score and POA&M are current. Nothing in the transition should touch the Revision 2 evidence that supports today's score.
- Build the crosswalk. One row per Revision 3 requirement, with columns for the Revision 2 source requirement(s), the SP 800-53 control, the ODP identifiers, the DoD value, your current value and the evidence reference. Start from NIST's change analysis and the official OSCAL dataset rather than retyping.
- Set and record every ODP. Use a parameter register owned by the system owner. Where your current value is looser than the DoD value, record a dated decision: tighten now, or tighten on a trigger (contract change or DFARS update).
- Stand up the three new families. Most organisations already have an SSP and some supplier checks. Close the gaps in this order: rules of behaviour acknowledgements tied to provisioning (03.15.03), end-of-support register (03.16.02), external service provider monitoring (03.16.03), then the SCRM plan (03.17.01).
- Test against SP 800-171A Revision 3. Run an internal assessment of a sample of requirements using the Revision 3 objectives, including the ODP determination statements, and compare findings with the Revision 2 view.
- Prepare the switch package. Keep a ready-to-issue SSP section for Revision 3 numbering and a readiness tracker of open items. When DoD changes the class deviation or the CMMC rule, re-baseline on that date.
Rollback is simple if you keep the tracks separate: the Revision 2 SSP and POA&M remain the documents of record until the contract says otherwise. Small organisations can hold the crosswalk in one spreadsheet and set ODPs in a single workshop; large organisations with several CUI enclaves should hold one parameter register per system and an enterprise default set that systems inherit unless they record an exception. For enclave design, see the CMMC Scoping Guide.
Where identity fits
Identity requirements carry many of the ODPs: logon attempt limits, device lock and session termination timers, re-authentication triggers, authenticator refresh and inactive account handling. Non-human identities are easy to miss. 03.05.01 requires users to be uniquely identified and associated with "processes acting on behalf of those users", and 03.05.12 Authenticator Management covers the keys, tokens and certificates that service accounts and automation use. A tight inactive account rule, such as any short value DoD sets in its memo, needs a clear definition of "inactive" for service accounts, or it will either disable production integrations or be quietly excepted. Decide that definition before you adopt the value. See the Secrets Management Guide for credential rotation evidence.
Detection and measurement
- ODP coverage: percentage of ODPs with a recorded value, owner and evidence reference (target 100 per cent before any Revision 3 assessment).
- Value drift: number of ODPs where the configured system value differs from the recorded value, checked by configuration export each quarter.
- DoD gap count: ODPs where your value is looser than the DoD value, trending down.
- Unsupported components: count of in-scope components past end of support without a recorded mitigation (03.16.02).
- Provider monitoring: percentage of external services handling CUI with a review completed in the last cycle (03.16.03).
- Rules of behaviour: percentage of active accounts with a current acknowledgement (03.15.03).
Common failure patterns
- Treating ODPs as a policy exercise. A value written in a policy but not enforced in configuration fails the test method. Export the setting.
- Mixing baselines in the SSP. Rewriting the live SSP in Revision 3 numbering before DoD switches confuses assessors and can disrupt a Revision 2 score. Keep separate tracks.
- Losing requirements in consolidation. Teams delete a withdrawn Revision 2 control from their tracker and forget that its substance moved elsewhere. Map every withdrawn identifier to its destination.
- A shallow SCRM plan. A one-page statement does not cover the life cycle 03.17.01 describes, from research and development to disposal.
- Forgetting service accounts. Aggressive inactivity and authenticator values applied to human accounts only, leaving service accounts and API keys outside the rule.
Framework mapping
| Revision 3 area | NIST SP 800-53 Rev. 5 | Related NHI Mgmt Group guide |
|---|---|---|
| 03.15 Planning | PL-2, PL-4 | NIST SP 800-171A Rev 3 Assessment Guide |
| 03.16 System and Services Acquisition | SA-8, SA-9, SA-22 | NIST SP 800-128 Security-Focused Configuration Management Guide |
| 03.17 Supply Chain Risk Management | SR-2, SR-3, SR-5 | NIST SP 800-161 Cyber Supply Chain Risk Management Guide |
| Identity ODPs (03.01.08, 03.05.01, 03.05.07, 03.05.12) | AC-7, IA-2, IA-5 | Password Policy Guide (NIST-aligned) |
Practitioner checklist
- Confirm which revision each contract cites, and record the DoD CIO page status on the date you check.
- Download the Revision 3 OSCAL or CPRT dataset and NIST's change analysis; build the crosswalk from them.
- Obtain and read the DoD ODP memo of 15 April 2025 directly from the DoD CIO site.
- Create a parameter register: one value, owner and evidence reference per ODP.
- Define "inactive" for service accounts and automation before adopting strict inactivity values.
- Collect rules of behaviour acknowledgements as part of account provisioning.
- Build an end-of-support register covering hardware, firmware and software in scope.
- Name an owner for each external service that handles CUI and schedule provider reviews.
- Write and approve a life-cycle SCRM plan with a defined review frequency.
- Run a sample internal assessment against SP 800-171A Revision 3 objectives each year until the switch.
Standards and references
- NIST: SP 800-171 Rev. 3, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations
- NIST: SP 800-171A Rev. 3, Assessing Security Requirements for Controlled Unclassified Information
- NIST: Updated Security Requirements for Protecting CUI
- NIST: SP 800-53 Rev. 5
- DoD CIO: About CMMC
- Crowell & Moring: DoD Specifies Implementation Requirements for NIST 800-171 Cyber Standard
- Holland & Knight: DoD Publishes Organization-Defined Parameters for NIST SP 800-171 Rev. 3
- Government Contracts Law: DoD Unveils NIST SP 800-171 Revision 3 Organizationally Defined Parameters
Related NHI Mgmt Group resources: NIST SP 800-171 and CMMC 2.0 Guide · NIST SP 800-171A Rev 3 Assessment Guide · CMMC Level 2 Readiness Checklist · CMMC Scoping Guide