This blog provides a detailed crosswalk between NIST SP 800-171 Revision 2 and Revision 3 to help government contractors prepare for the updated requirements for protecting Controlled Unclassified Information (CUI). It also explains the regulatory requirements behind the transition and the methodology used to map the two revisions.
Key Takeaways
✅ NIST SP 800-171 Revision 3 includes 97 requirements, down from 110, but increases the number of assessment objectives from 320 to 422.
✅ See how assessment objectives in Revision 2 and Revision 3 relate using the Set Theory mapping method from NIST IR 8477.
✅ Identify the 30 CMMC Level 2 assessment objectives that align with DoD-defined organization-defined parameter values in Revision 3.
Who Should Read This?
This guide is ideal for government contractors pursuing CMMC Level 2 certification and preparing to adopt NIST SP 800-171 Revision 3. It is especially useful for organizations transitioning from Revision 2 or managing requirements from both revisions at the same time.
NIST SP 800-171 Rev 3 Timeline
NIST released Revision 3 of Special Publication 800-171 Protecting Controlled Unclassified Information (CUI) in Nonfederal Systems and Organizations in May of 2024. In the same month, the Department of Defense (DoD) released a class deviation linking NIST SP 800-171 Revision 2 to Defense Federal Acquisition Regulation Supplement (DFARS) clause 252.204-7012. In October of 2024, DoD published the CMMC Program Final Rule, maintaining NIST SP 800-171 Revision 2 as the benchmark requirements for CMMC Level 2 self assessments and third-party assessments.
FAR CUI Rule Updates
In January of 2025, the FAR Council, which includes DoD, GSA, and NASA, published a proposed FAR CUI Rule, which would have required all Federal contractors handling controlled unclassified information to implement the requirements of NIST SP 800-171 Revision 2. The FAR Council anticipated that future rulemaking would update requirements to include NIST SP 800-171 Revision 3, stating they were assessing where to standardize Organization Defined Parameter (ODP) values on a governmentwide basis. In April of 2025, DoD published ODP values for NIST SP 800-171 Revision 3.
Revolutionary FAR Overhaul (RFO) Part 40
In June of 2026, the FAR Council published four cases within their Revolutionary FAR Overhaul (RFO) that included revisions to 20 parts. Proposed changes to part 40 included updates to the proposed FAR CUI Rule that would standardize NIST SP 800-171 Rev 3 as the baseline for protecting CUI within nonfederal systems and apply the ODP values provided by DoD. The Government intends to harmonize cybersecurity requirements to ensure contractors can follow one standardized approach for protecting CUI across agencies. Consequently, the FAR CUI Rule will align to the values codified in 32 CFR part 170 via DoD rulemaking.
FAR CUI Rule vs CMMC
There are some key differences between CMMC Level 2 and the proposed FAR CUI Rule:
As of June 2026, the DoD class deviation is still in effect and CMMC Level 2 is still based on NIST SP 800-171 Revision 2. The FAR CUI Rule would require contractors to implement NIST SP 800-171 Revision 3 using the ODP values provided by DoD.
CMMC Level 2 does allow for self-attestation for some contracts involving CUI, but DoD estimates 95% of defense contractors handling CUI will need a third party assessment. The FAR CUI Rule has no third party verification requirements; however, contractors must make the system security plan and any associated plans of action available to the Government upon request.
DoD expects less than 2% of contractors handling CUI to implement CMMC Level 3, which includes 24 controls selected from NIST SP 800-172 and involves a third party assessment conducted by the Defense Industrial Base Cybersecurity Assessment Center (DIBCAC). The FAR CUI Rule proposes that specific requirements from NIST SP 800-172 will apply when identified by the agency for a critical program or high-value asset and the ODP values will align with the ODP values at 32 CFR 170.14.
CMMC has a four-phase implementation plan, with Phase 1 requiring self-attestation for all applicable DoD solicitations and contracts as a condition of contract award. Phase 2 will begin in November 2026 and require third party assessments for applicable CMMC Level 2 solicitations and contracts as a condition of contract award. DoD may, at its discretion, delay the inclusion of third party assessment requirements for CMMC Level 2 to an option period instead of as a condition of contract award.
The RFO has two phases. In the first phase, the FAR Council issued model class deviations to replace each part in the FAR until such time as formal rulemaking occurred. The second phase includes 12 FAR Cases. The first four released on June 23rd have a comment period ending on July 23, 2026. The RFO will allow agencies to adopt and apply each part upon issuance via class deviation, rather than waiting to complete the lengthy rulemaking process that will revise the entire FAR. The FAR Council will issue rewritten FAR parts as model deviation text and agencies will adopt it by issuing their own FAR deviations. After rewriting all FAR parts as model deviation text, the FAR Council will begin formal notice and comment rulemaking to codify the streamlined FAR with public input.
It's worth mentioning that for organizations navigating both DoD and civilian agency requirements, understanding how CMMC and FedRAMP interact is equally important. See our breakdown of CMMC vs. FedRAMP: Key Differences and Which Applies to You.
NIST SP 800-171 Revision 2 VS Revision 3
When NIST first published SP 800-171 in June of 2015 it contained 109 requirements derived from FIPS 200 (basic requirements) and NIST SP 800-53 Revision 4 (derived requirements). NIST organized these requirements into 14 families or domains. In December of 2016, NIST published Revision 1 which added the 110th requirement for nonfederal organizations to document the implementation of security requirements into a system security plan (SSP). In June of 2018 NIST published the first assessment guide for SP 800-171 called SP 800-171A which included 320 determination statements aligned to the 110 security requirements. At the time, the SP 800-171 publication only contained high level statements describing the 110 requirements, so in February of 2020 NIST published Revision 2, which added a narrative discussion for each requirement.
In May of 2024, NIST published Revision 3, which reduced the number of requirements down to 97 but expanded into 17 domains by adding the Planning, System and Services Acquisition, and Supply Chain Risk Management families. NIST SP 800-171A Rev 3 was also released in May of 2024 and contained 422 determination statements with 88 ODPs. As described in NIST SP 800-53 Revision 5, a control ODP allows organizations to define specific values associated with controls.
In the proposed 2025 FAR CUI Rule, the Government estimated that 29,614 defense contractors also do business with civilian agencies. Once civilian agencies adopt the FAR CUI Rule and before CMMC rescinds their NIST SP 800-171r2 class deviation, these contractors handling CUI on behalf of DoD and civilian agencies may find themselves managing two versions of the same standard.
Following best practices, defense contractors should write their System Security Plan (SSP) at the assessment objective level of SP 800-171A. With CMMC planning to adopt NIST SP 800-171r3 and the FAR Council proposing a government-wide CUI rule requiring the same standard, creating a crosswalk at the assessment objective level provides practitioners with a faster way to understand their gaps and update their documentation.
NIST SP 800-53r5 Derived Relationship Mapping
NIST published a Change analysis (Rev. 2 to Rev. 3)(xlsx) that summarizes the changes at a high level; however, we took a different approach. Building on the work we’ve done previously by mapping NIST SP 800-171A to SP 800-53 control parts, we leveraged the mapping table within Appendix C of NIST SP 800-171 Revision 3 to create a derived relationship map between the two versions of NIST SP 800-171 using NIST SP 800-53 Revision 5 as the focal document. Following guidance from NIST IR 8477, we used the Set Theory mapping style and trained Google’s Gemini on categorizing the nature of the relationships and assessing their strength.
(Incorporating DoD ODP Values)
We also incorporated DoD assigned ODP values into the crosswalk. Of the 88 ODPs, DoD assigned values for 79 ODPs. Some of the ODP values provided by DoD fall short of actually defining the parameter. For example, the definition provided for 03.01.06.a “only defined and authorized personnel or administrative roles” is a vague assignment from an assessment standpoint. Organizations should define those authorized personnel or administrative roles relative to privileged accounts within their system.
Some ODP values provided by DoD include the phrase “Guidance”. For example 03.01.20.b, 03.04.06.b, 03.13.10, and 03.16.01. This guidance should shape the values defined by the organization implementing these controls.
Let’s look at the first example from the completed crosswalk. 03.01.01 System Account Management has changed significantly from AC.L2-3.1.1 Authorized Access Control. Revision 3 includes 6 ODPs and DoD has defined all of them. There are 21 assessment objectives within 03.01.01, of which 16 we traced back to CMMC Level 2 assessment objectives. Part of the reason this and several other basic requirements are so different is that NIST originally sourced basic security requirements from FIPS 200 instead of NIST SP 800-53r4. NIST decided to derive all requirements from SP 800-53r5 for this new version of SP 800-171r3.
AC.L2-3.1.1.a and AC.L2-3.1.1.b require identifying authorized users and processes acting on behalf of authorized users. These objectives intersect A.03.01.01.c[01] which requires specifying authorized users of the system.
AC.L2-3.1.1.d and AC.L2-3.1.1.e require limiting system access to authorized users and processes acting on behalf of authorized users. These objectives are a superset of or intersect the following 03.01.01 assessment objectives:
A.03.01.01.b[01] system accounts are created in accordance with organizational policy, procedures, prerequisites, and criteria.
A.03.01.01.b[02] system accounts are enabled in accordance with organizational policy, procedures, prerequisites, and criteria.
A.03.01.01.b[03] system accounts are modified in accordance with organizational policy, procedures, prerequisites, and criteria.
A.03.01.01.b[04] system accounts are disabled in accordance with organizational policy, procedures, prerequisites, and criteria.
A.03.01.01.b[05] system accounts are removed in accordance with organizational policy, procedures, prerequisites, and criteria.
A.03.01.01.d[01] access to the system is authorized based on a valid access authorization.
A.03.01.01.e the use of accounts is monitored.
A.03.01.01.f[01] system accounts are disabled when the accounts have expired.
A.03.01.01.f[03] system accounts are disabled when the accounts are no longer associated with a user or individual.
A.03.01.01.f[04] system accounts are disabled when the accounts violate organizational policy.
A.03.01.01.f[05] system accounts are disabled when significant risks associated with individuals are discovered.
AC.L2-3.1.2.a Requires defining the types of transactions and functions that authorized users are permitted to execute. This objective intersects A.03.01.01.d[02] which requires basing authorization of system access on intended system usage.
AC.L2-3.1.2.b requires limiting system access to the defined types of transactions and functions for authorized users. This objective intersects A.03.01.01.c[02] which requires specifying group and role membership.
IA.L2-3.5.3.a requires identifying privileged accounts. This objective intersects A.03.01.01.c[03] which requires specifying access authorizations (i.e., privileges) for each account.
IA.L2-3.5.6.a requires defining a period of inactivity after which an identifier is disabled. This objective is equal to A.03.01.01.ODP[01] which requires defining the time period for account inactivity before disabling. DoD has defined this ODP with a value of “at most 90 days”.
IA.L2-3.5.6.b requires disabling identifiers after the defined period of inactivity. This objective is equal to A.03.01.01.f[02] which requires disabling system accounts when the accounts have been inactive for <A.03.01.01.ODP[01] time period>, which was defined above as “at most 90 days”.
SC.L2-3.13.3.a requires identifying user functionality. This objective is a subset of A.03.01.01.d[02] which requires basing authorized access to the system on intended system usage. NIST SP 800-171r3 03.13.03 was withdrawn as NIST identifying it was addressed by 03.01.01 and 6 other security requirements.
The remaining 6 assessment objectives within 03.01.01 were not mapped to any CMMC Level 2 assessment objectives. The full table below shows the full mapping of this single requirement:
Rev 3 Assessment Objective
Rev 3 Determination Statement
Rev 3 Determination Statement (with ODP Values)
CMMC Level 2 Assessment Objective
CMMC Level 2 Determination Statement
A.03.01.01.ODP[01]
The time period for account inactivity before disabling is defined.
At most 90 days
IA.L2-3.5.6.a.
A period of inactivity after which an identifier is disabled is defined.
A.03.01.01.ODP[02]
The time period within which to notify account managers and designated personnel or roles when accounts are no longer required is defined.
24 hours
N/A
—
A.03.01.01.ODP[03]
The time period within which to notify account managers and designated personnel or roles when users are terminated or transferred is defined.
24 hours
N/A
—
A.03.01.01.ODP[04]
The time period within which to notify account managers and designated personnel or roles when system usage or the need-to-know changes for an individual is defined.
24 hours
N/A
—
A.03.01.01.ODP[05]
The time period of expected inactivity requiring users to log out of the system is defined.
At most 24 hours
N/A
—
A.03.01.01.ODP[06]
Circumstances requiring users to log out of the system are defined.
The work period ends, for privileged users at a minimum
N/A
—
A.03.01.01.a[01]
System account types allowed are defined.
System account types allowed are defined.
N/A
—
A.03.01.01.a[02]
System account types prohibited are defined.
System account types prohibited are defined.
N/A
—
A.03.01.01.b[01]
System accounts are created in accordance with organizational policy, procedures, prerequisites, and criteria.
System accounts are created in accordance with organizational policy, procedures, prerequisites, and criteria.
AC.L2-3.1.1.d. AC.L2-3.1.1.e.
System access is limited to authorized users; system access is limited to processes acting on behalf of authorized users.
A.03.01.01.b[02]
System accounts are enabled in accordance with organizational policy, procedures, prerequisites, and criteria.
System accounts are enabled in accordance with organizational policy, procedures, prerequisites, and criteria.
AC.L2-3.1.1.d. AC.L2-3.1.1.e.
System access is limited to authorized users; system access is limited to processes acting on behalf of authorized users.
A.03.01.01.b[03]
System accounts are modified in accordance with organizational policy, procedures, prerequisites, and criteria.
System accounts are modified in accordance with organizational policy, procedures, prerequisites, and criteria.
AC.L2-3.1.1.d. AC.L2-3.1.1.e.
System access is limited to authorized users; system access is limited to processes acting on behalf of authorized users.
A.03.01.01.b[04]
System accounts are disabled in accordance with organizational policy, procedures, prerequisites, and criteria.
System accounts are disabled in accordance with organizational policy, procedures, prerequisites, and criteria.
AC.L2-3.1.1.d. AC.L2-3.1.1.e.
System access is limited to authorized users; system access is limited to processes acting on behalf of authorized users.
A.03.01.01.b[05]
System accounts are removed in accordance with organizational policy, procedures, prerequisites, and criteria.
System accounts are removed in accordance with organizational policy, procedures, prerequisites, and criteria.
AC.L2-3.1.1.d. AC.L2-3.1.1.e.
System access is limited to authorized users; system access is limited to processes acting on behalf of authorized users.
A.03.01.01.c[01]
Authorized users of the system are specified.
Authorized users of the system are specified.
AC.L2-3.1.1.a.
Authorized users are identified; processes acting on behalf of authorized users are identified.
A.03.01.01.c[02]
Group and role membership are specified.
Group and role membership are specified.
AC.L2-3.1.2.b.
System access is limited to the defined types of transactions and functions for authorized users.
A.03.01.01.c[03]
Access authorizations (i.e., privileges) for each account are specified.
Access authorizations (i.e., privileges) for each account are specified.
IA.L2-3.5.3.a.
Privileged accounts are identified.
A.03.01.01.d[01]
Access to the system is authorized based on a valid access authorization.
Access to the system is authorized based on a valid access authorization.
AC.L2-3.1.1.d. AC.L2-3.1.1.e.
System access is limited to authorized users; system access is limited to processes acting on behalf of authorized users.
A.03.01.01.d[02]
Access to the system is authorized based on intended system usage.
Access to the system is authorized based on intended system usage.
SC.L2-3.13.3.a. AC.L2-3.1.2.a.
User functionality is identified; the types of transactions and functions that authorized users are permitted to execute are defined.
A.03.01.01.e
The use of accounts is monitored.
The use of accounts is monitored.
AC.L2-3.1.1.d. AC.L2-3.1.1.e.
System access is limited to authorized users; system access is limited to processes acting on behalf of authorized users.
A.03.01.01.f[01]
System accounts are disabled when the accounts have expired.
System accounts are disabled when the accounts have expired.
AC.L2-3.1.1.d. AC.L2-3.1.1.e.
System access is limited to authorized users; system access is limited to processes acting on behalf of authorized users.
A.03.01.01.f[02]
System accounts are disabled when the accounts have been inactive for the defined time period.
System accounts are disabled when the accounts have been inactive for at most 90 days.
IA.L2-3.5.6.b.
Identifiers are disabled after the defined period of inactivity.
A.03.01.01.f[03]
System accounts are disabled when the accounts are no longer associated with a user or individual.
System accounts are disabled when the accounts are no longer associated with a user or individual.
AC.L2-3.1.1.d.
System access is limited to authorized users.
A.03.01.01.f[04]
System accounts are disabled when the accounts violate organizational policy.
System accounts are disabled when the accounts violate organizational policy.
AC.L2-3.1.1.d.
System access is limited to authorized users.
A.03.01.01.f[05]
System accounts are disabled when significant risks associated with individuals are discovered.
System accounts are disabled when significant risks associated with individuals are discovered.
AC.L2-3.1.1.d.
System access is limited to authorized users.
A.03.01.01.g[01]
Account managers and designated personnel or roles are notified within the defined time period when accounts are no longer required.
Account managers and designated personnel or roles are notified within 24 hours when accounts are no longer required.
N/A
—
A.03.01.01.g[02]
Account managers and designated personnel or roles are notified within the defined time period when users are terminated or transferred.
Account managers and designated personnel or roles are notified within 24 hours when users are terminated or transferred.
N/A
—
A.03.01.01.g[03]
Account managers and designated personnel or roles are notified within the defined time period when system usage or the need-to-know changes for an individual.
Account managers and designated personnel or roles are notified within 24 hours when system usage or the need-to-know changes for an individual.
N/A
—
Why You Need a NIST SP 800-171r2 to r3 Crosswalk for CMMC
There is no doubt that CMMC will migrate to NIST SP 800-171r3. However, there is value incorporating guidance from this crosswalk today into your implementation of SP 800-171r2. NIST doesn’t call any assessment objectives with CMMC ODPs today, but they are parameters and DoD has defined acceptable values for many of them today. Here are 30 CMMC assessment objectives aligned with NIST SP 800-171r3 ODP values assigned by DoD:
CMMC Level 2 Assessment Objective
CMMC Level 2 Determination Statement
Rev 3 Assessment Objective
Rev 3 Determination Statement
Rev 3 Determination Statement (with ODP Values)
AC.L2-3.1.5.c.
Security functions are identified; and
A.03.01.05.ODP[01]
Security functions for authorized access are defined.
At a minimum and if applicable: establishing system accounts and assigning privileges, configuring access authorizations, configuring settings for events to be audited, establishing vulnerability scanning parameters, establishing intrusion detection parameters, and managing audit information
AC.L2-3.1.8.a.
The means of limiting unsuccessful logon attempts is defined; and
A.03.01.08.ODP[01]
The number of consecutive invalid logon attempts by a user allowed during a time period is defined.
At most five (5)
AC.L2-3.1.8.a.
The means of limiting unsuccessful logon attempts is defined; and
A.03.01.08.ODP[02]
The time period to which the number of consecutive invalid logon attempts by a user is limited is defined.
Period of five (5) minutes
AC.L2-3.1.8.b.
The defined means of limiting unsuccessful logon attempts is implemented.
A.03.01.08.ODP[03]
One or more of the following parameter values are selected: the account or node is locked automatically for a defined time period; the account or node is locked automatically until released by an administrator; the next logon prompt is delayed automatically; the system administrator is notified automatically; other action is taken automatically.
Selection (one or more): lock the account or node for an at least 15-minute time period; lock the account or node until released by an administrator and notify a system administrator
AC.L2-3.1.8.b.
The defined means of limiting unsuccessful logon attempts is implemented.
A.03.01.08.ODP[04]
The time period for an account or node to be locked is defined (if selected).
An at least 15-minute time period
AC.L2-3.1.10.a.
The period of inactivity after which the system initiates a session lock is defined;
A.03.01.10.ODP[02]
The time period of inactivity after which a device lock is initiated is defined (if selected).
At most 15 minutes
AC.L2-3.1.11.a.
Conditions requiring a user session to terminate are defined; and
A.03.01.11.ODP[01]
Conditions or trigger events that require session disconnect are defined.
A specified duration (maximum of 24 hours) of inactivity, misbehavior (end the session due to an attempted policy violation), and maintenance (terminate sessions to prevent issues with an upgrade or service outage)
AC.L2-3.1.15.b.
Security-relevant information authorized to be accessed remotely is identified;
A.03.01.05.ODP[02]
Security-relevant information for authorized access is defined.
At a minimum and if applicable: threat and vulnerability information, filtering rules for routers or firewalls, configuration parameters for security services, cryptographic key management information, security architecture, access control lists, and audit information
AU.L2-3.3.1.a.
Audit logs needed (i.e., event types to be logged) to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity are specified;
A.03.03.01.ODP[01]
Event types selected for logging within the system are defined.
At a minimum and where applicable:
Authentication events:
Logons (Success/Failure)
Logoffs (Success)
Security relevant file and object events:
Create (Success/Failure)
Access (Success/Failure)
Delete (Success/Failure)
Modify (Success/Failure)
Permission Modification (Success/Failure)
Ownership Modification (Success/Failure)
Export/Writes/downloads to devices/digital media (e.g., CD/DVD, USB, SD) (Success/Failure)
Import/Uploads from devices/digital media (e.g., CD/DVD, USB, SD) (Success/Failure)
User and Group Management events:
User add, delete, modify, disable, lock (Success/Failure)
Group/Role add, delete, modify (Success/Failure)
Use of Privileged/Special Rights events:
Security or audit policy changes (Success/Failure)
Configuration changes (Success/Failure)
Admin or root-level access (Success/Failure)
Privilege/Role escalation (Success/Failure)
Audit and security relevant log data accesses (Success/Failure)
System reboot, restart, and shutdown (Success/Failure)
Print to a device (Success/Failure)
Print to a file (e.g., pdf format) (Success/Failure)
Application (e.g., Adobe, Firefox, MS Office Suite) initialization (Success/Failure)
For additional guidance: OMB21-31 ML 1
AU.L2-3.3.3.a.
A process for determining when to review logged events is defined;
A.03.03.01.ODP[02]
The frequency of event types selected for logging are reviewed and updated.
At least every 12 months and after any significant incidents or significant changes to risks
AU.L2-3.3.5.a.
Audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity are defined; and
A.03.03.05.ODP[01]
The frequency at which system audit records are reviewed and analyzed is defined.
At least weekly
CM.L2-3.4.1.c.
The baseline configuration is maintained (reviewed and updated) throughout the system development life cycle;
A.03.04.10.ODP[01]
The frequency at which to review and update the system component inventory is defined.
At least quarterly
CM.L2-3.4.2.a.
Security configuration settings for information technology products employed in the system are established and included in the baseline configuration; and
A.03.04.02.ODP[01]
Configuration settings for the system that reflect the most restrictive mode consistent with operational requirements are defined.
Apply the appropriate use of common security configurations available from the National Institute of Standards and Technology's National Checklist Program (NCP) website and prevent remote devices from simultaneously establishing nonremote connections with organizational systems and communicating via some other unauthorized connection to resources in external networks. Document any deviations from the published standard or source document.
IA.L2-3.5.5.a.
A period within which identifiers cannot be reused is defined.
A.03.05.05.ODP[01]
The time period for preventing the reuse of identifiers is defined.
At least ten (10) years
IA.L2-3.5.6.a.
A period of inactivity after which an identifier is disabled is defined.
A.03.01.01.ODP[01]
The time period for account inactivity before disabling is defined.
At most 90 days
IA.L2-3.5.7.a.
Password complexity requirements are defined.
A.03.05.07.ODP[02]
Password composition and complexity rules are defined.
Must have a minimum length of 16 characters.
Contains a string of characters that does not include the user's account name or full name.
IA.L2-3.5.7.b.
Password change of character requirements are defined.
A.03.05.07.ODP[02]
Password composition and complexity rules are defined.
Must have a minimum length of 16 characters.
Contains a string of characters that does not include the user's account name or full name.
IR.L2-3.6.1.g.
The operational incident-handling capability includes user response activities.
A.03.06.04.ODP[01]
The time period within which incident response training is to be provided to system users is defined.
Ten (10) days for privileged users, thirty (30) days for all other roles
IR.L2-3.6.2.c.
Authorities to whom incidents are to be reported are identified.
A.03.06.02.ODP[02]
Authorities to whom incident information is to be reported are defined.
All applicable personnel and entities as specified by the contract, and in accordance with any incident response plan notification procedures
IR.L2-3.6.3.a.
The incident response capability is tested.
A.03.06.03.ODP[01]
The frequency at which to test the effectiveness of the incident response capability for the system is defined.
At least every 12 months
PE.L2-3.10.1.a.
Authorized individuals allowed physical access are identified;
A.03.10.01.ODP[01]
The frequency at which to review the access list detailing authorized facility access by individuals is defined.
At least every 12 months, or when there are significant incidents or significant changes to risks
PE.L2-3.10.4.a.
Audit logs of physical access are maintained.
A.03.10.02.ODP[01]
The frequency at which to review physical access logs is defined.
At least every 45 days
PE.L2-3.10.6.a.
Safeguarding measures for CUI are defined for alternate work sites.
A.03.10.06.ODP[01]
Security requirements to be employed at alternate work sites are defined.
Adequate security, comparable to organizational security requirements at the primary work site where practical, documented in policy, and covered by training
RA.L2-3.11.1.a.
The frequency to assess risk to organizational operations, organizational assets, and individuals is defined.
A.03.11.01.ODP[01]
The frequency at which to update the risk assessment is defined.
At least every 12 months, or when there are significant incidents or significant changes to risks
RA.L2-3.11.2.a.
The frequency to scan for vulnerabilities in organizational systems and applications is defined.
A.03.11.02.ODP[02]
The frequency at which the system is scanned for vulnerabilities is defined.
At least monthly, or when there are significant incidents or significant changes to risks
CA.L2-3.12.1.a.
The frequency of security control assessments is defined.
A.03.12.01.ODP[01]
The frequency at which to assess the security requirements for the system and its environment of operation is defined.
At least every 12 months, or when there are significant incidents or significant changes to risks
CA.L2-3.12.4.g.
The frequency to update the system security plan is defined.
A.03.15.02.ODP[01]
The frequency at which the system security plan is reviewed and updated is defined.
At least every 12 months, or when there are significant incidents or significant changes to risks
SC.L2-3.13.3.b.
System management functionality is identified; and
A.03.01.05.ODP[01]
Security functions for authorized access are defined.
At a minimum and if applicable: establishing system accounts and assigning privileges, configuring access authorizations, configuring settings for events to be audited, establishing vulnerability scanning parameters, establishing intrusion detection parameters, and managing audit information
SC.L2-3.13.9.a.
A period of inactivity to terminate network connections associated with communications sessions is defined.
A.03.13.09.ODP[01]
The time period of inactivity after which the system terminates a network connection associated with a communications session is defined.
No longer than 15 minutes
SI.L2-3.14.1.e.
The time within which to correct system flaws is specified.
A.03.14.01.ODP[01]
The time period within which to install security-relevant software updates after the release of the updates is defined.
Thirty (30) days for high-risk flaws (including both critical and high), 90 days for moderate-risk flaws, and 180 days for low-risk flaws
SI.L2-3.14.1.e.
The time within which to correct system flaws is specified.
A.03.14.01.ODP[02]
The time period within which to install security-relevant firmware updates after the release of the updates is defined.
Thirty (30) days for high-risk flaws (including both critical and high), 90 days for moderate-risk flaws, and 180 days for low-risk flaws
SI.L2-3.14.5.a.
The frequency for malicious code scans is defined.
A.03.14.02.ODP[01]
The frequency at which malicious code protection mechanisms perform scans is defined.
At least weekly
Conclusion
Transitioning from NIST SP 800-171 Revision 2 to Revision 3 is more than a routine compliance update. While mapping these changes using a comprehensive crosswalk is a critical first step, true compliance lies in execution. Organizations should begin by analyzing their current control gaps and updating their Plans of Action and Milestones before modifying their System Security Plans (SSPs). Keep in mind that CMMC still requires compliance with Revision 2 but by embracing this evolution early, your organization will not only meet upcoming federal requirements but will also significantly harden its overall cybersecurity posture.
❓ Frequently Asked Questions About the NIST SP 800-171 Rev 2 to Rev 3 Crosswalk
What is a NIST SP 800-171 Rev 2 to Rev 3 crosswalk?
A NIST SP 800-171 Rev 2 to Rev 3 crosswalk maps Revision 2 requirements and assessment objectives to their corresponding Revision 3 requirements. It helps organizations identify changed, expanded, withdrawn, and newly introduced cybersecurity requirements.
What are the main differences between NIST SP 800-171 Revision 2 and Revision 3?
Revision 2 contains 110 security requirements across 14 families, while Revision 3 contains 97 requirements across 17 families. Revision 3 also expands the number of assessment objectives from 320 to 422 and introduces 88 organization-defined parameters.
Does CMMC Level 2 currently require NIST SP 800-171 Revision 3?
No. CMMC Level 2 currently uses NIST SP 800-171 Revision 2 as its cybersecurity requirements baseline. However, organizations can use a NIST SP 800-171 Rev 2 to Rev 3 crosswalk to prepare for an eventual transition to Revision 3.
How does the proposed FAR CUI Rule affect NIST SP 800-171 compliance?
The proposed FAR CUI Rule would establish NIST SP 800-171 Revision 3 as the baseline for protecting CUI in nonfederal systems across federal agencies. Contractors may therefore need to manage Revision 2 for CMMC while also preparing for Revision 3 requirements under civilian agency contracts.
What are organization-defined parameters in NIST SP 800-171 Revision 3?
Organization-defined parameters, or ODPs, are specific values that must be assigned to certain security requirements, such as password length, account inactivity periods, or vulnerability-scanning frequency. Revision 3 includes 88 ODPs, and the Department of Defense has assigned values to many of them.
How can a crosswalk help update a System Security Plan?
A NIST SP 800-171 Rev 2 to Rev 3 crosswalk shows which existing assessment objectives remain applicable and where new gaps may exist. Organizations can use the mapping to update their gap analysis, Plans of Action and Milestones, policies, procedures, and System Security Plan.
When should contractors begin preparing for NIST SP 800-171 Revision 3?
Contractors should begin preparing before Revision 3 becomes a contractual requirement. Early preparation allows organizations to identify unmapped assessment objectives, apply relevant DoD ODP values, and address implementation gaps without disrupting current CMMC compliance efforts.
Understand the key differences between NIST SP 800-171 Revision 2 and Revision 3 with this comprehensive migration guide and crosswalk. Learn how security requirements, assessment objectives, and DoD Organization-Defined Parameters (ODPs) align to help your organization prepare for future CMMC and FAR CUI compliance.
Explore practical risk register examples, including enterprise, operational, qualitative, and FAIR-based cybersecurity registers, to learn how organizations identify, prioritize, and manage risk more effectively.
