The suspension of CMMC Phase 2 may sound like a reduction in urgency for the Defense Industrial Base. In practice, it may raise the stakes. Cybersecurity requirements rarely remain static: threats evolve, government expectations mature, and the standards used to protect Controlled Unclassified Information must change with them.
That is the context behind NIST Special Publication 800-171 Revision 3 and the current pause in CMMC implementation. The pause changes the timing of certification expansion; it does not change the need to protect federal data or the direction of the technical baseline.
Published in May 2024, NIST SP 800-171 Rev. 3 superseded Revision 2 as NIST’s current security requirements for protecting Controlled Unclassified Information, or CUI, in nonfederal systems and organizations. NIST subsequently withdrew Rev. 2 because Rev. 3 replaced it. Rev. 3 is accompanied by NIST SP 800-171A Rev. 3, which provides the corresponding assessment procedures.
For defense contractors preparing for Cybersecurity Maturity Model Certification, however, an important distinction remains:
NIST has published Revision 3, but the Current CMMC Level 2 Regulatory Baseline Remains NIST SP 800-171 Revision 2.
That means organizations should not abandon their current Revision 2 implementation or CMMC assessment preparation. Phase 1 self-assessment requirements remain in place, and DFARS 252.204-7012 continues to require protection of covered defense information. At the same time, waiting until Revision 3 appears in a contract may leave too little time to evaluate new requirements, update policies and technology, collect evidence, and address implementation gaps.
The appropriate strategy is therefore not to choose between Revision 2 and Revision 3. It is to maintain current CMMC readiness while beginning a structured transition analysis. The pause is not a retreat from protecting CUI; it is a window to prepare for a broader and more explicit standard before that standard is incorporated into CMMC and DFARS requirements.
Is NIST SP 800-171 Rev. 3 Required for CMMC Today?
As of this writing, CMMC Level 2 continues to incorporate the 110 security requirements from NIST SP 800-171 Rev. 2. The CMMC regulation at 32 CFR Part 170 identifies Revision 2 as the Level 2 standard, and CMMC Level 2 assessments continue to use the associated Revision 2 assessment methodology.
DoD has paused the transition to CMMC Phase 2, but it has not eliminated Phase 1 self-assessment obligations or the contractual duty to safeguard covered defense information. Contractors should therefore separate the certification timetable from the underlying security obligation: one is under review, while the other remains active.
DoD has also begun preparing for future use of Rev. 3 organization-defined parameters, or ODPs. That preparation does not establish a new effective date, but it is a meaningful signal that the future implementation model is being worked through now. For primes and subcontractors handling CUI, the likely direction is broader governance, clearer implementation decisions, and stronger proof that controls operate as intended.
This is an important point for organizations currently pursuing CMMC readiness:
- Existing contractual obligations should still be evaluated against the requirements identified in the applicable contract.
- Current CMMC Level 2 preparation should remain aligned to Revision 2.
- Existing System Security Plans, Plans of Action and Milestones, evidence repositories, control mappings, and assessment activities should not simply be converted to Revision 3 without considering the governing contractual requirements.
Revision 3 nevertheless represents NIST’s current security model for protecting CUI. It is reasonable to expect federal contracting requirements to evolve over time, although the timing and implementation mechanism will be determined by the responsible agencies and acquisition regulations.
Organizations that begin evaluating the changes now will be better positioned to respond when those requirements are incorporated into solicitations, contracts, agency guidance, or future CMMC rulemaking.
Revision 3 Is More Than a Renumbering Exercise
Some framework updates primarily clarify language or reorganize existing material. Revision 3 goes considerably further.
NIST revised the structure and content of SP 800-171 to align it more closely with NIST SP 800-53 Revision 5 and the SP 800-53B moderate control baseline. NIST also sought to reduce ambiguity, improve implementation consistency, and give assessors more precise criteria for evaluating whether security requirements are satisfied.
The result is a standard that will feel familiar to experienced practitioners but materially different in several areas.
Taken together, these changes raise the operational burden beyond a simple control refresh. Organizations should expect greater emphasis on supply-chain oversight, defined logging and retention, configuration and drift monitoring, vulnerability management, security testing, accurate data identification, and structured evidence that can be produced during an assessment rather than reconstructed afterward.
1. Revision 3 Adds Three Security Requirement Families
Revision 2 organizes its requirements into 14 security families. Revision 3 expands that structure to 17 families by adding:
- Planning
- System and Services Acquisition
- Supply Chain Risk Management
The former Security Assessment family is also renamed Security Assessment and Monitoring.
These additions reflect a broader view of CUI protection.
Security is not limited to configuring access controls, retaining logs, encrypting information, or responding to incidents. Organizations must also consider how security is incorporated into planning, how systems and external services are acquired and developed, and how risks introduced through suppliers and the technology supply chain are managed.
For executives, this means the transition will not be owned solely by the security operations team. Procurement, legal, engineering, IT, compliance, risk management, and vendor-management functions may all have responsibilities under a future Revision 3 implementation.
2. Requirements Are More Specific
Revision 2 often states requirements at a relatively high level. That flexibility allowed organizations to implement safeguards in ways appropriate to their environments, but it also created uncertainty.
Different organizations could interpret the same requirement differently. Assessors could also reach different conclusions about what constituted sufficient implementation or evidence.
NIST addressed this issue in Revision 3 by increasing the specificity of many requirements. The intent is to reduce ambiguity, improve implementation effectiveness, and clarify the scope of assessments.
This added specificity may expose gaps that were less visible under Revision 2.
An organization may have considered a Revision 2 requirement fully implemented, for example, but discover that the Revision 3 successor requirement expects more clearly defined processes, system behaviors, review activities, documentation, or evidence.
This makes a direct crosswalk essential. Organizations should not assume that a passing or fully implemented Revision 2 requirement automatically maps to full Revision 3 readiness.
3. Organization-Defined Parameters Introduce New Decisions
Revision 3 introduces organization-defined parameters, commonly called ODPs, into selected security requirements.
ODPs allow certain values within a requirement to be established based on applicable laws, regulations, agency direction, mission needs, risk, or organizational circumstances. These values may include items such as frequencies, time periods, conditions, or defined actions.
A federal agency may establish the parameter, provide guidance for selecting it, or allow the nonfederal organization to assign the value. When the agency does not provide the value, the nonfederal organization may be responsible for defining it. Once selected, that value becomes part of the security requirement and can be assessed.
ODPs provide flexibility, but they also create governance responsibilities.
Because ODPs turn broad language into measurable values, they are especially important to transition planning. Once an agency or organization assigns a frequency, time period, threshold, or condition, that value becomes part of the requirement and must be reflected consistently in policy, configuration, operation, retention, and reporting.
Organizations will need to determine:
- Who has authority to establish each parameter?
- What risk analysis or external requirement supports the selected value?
- Where is that decision documented?
- How is the parameter translated into technical configuration and operating procedures?
- What evidence demonstrates that the selected value is consistently enforced?
This is an area where policy, implementation, and evidence must remain synchronized. A parameter documented in a policy but not reflected in system configuration is unlikely to withstand assessment scrutiny.
4. The Basic and Derived Requirement Distinction Is Removed
Revision 2 distinguishes between basic and derived security requirements. Revision 3 removes that distinction and uses NIST SP 800-53 as the primary authoritative source for the requirements.
NIST states that this change increases clarity and specificity while supporting closer alignment between SP 800-171 and the broader federal control framework.
For practitioners, this alignment may make it easier to coordinate SP 800-171 implementation with other NIST-based programs. It also means that existing documentation, control identifiers, mappings, dashboards, and evidence taxonomies may need to be revised.
A transition plan should therefore address more than technical gaps. It should also account for changes to governance, documentation, data structures, reporting, and control ownership.
5. Requirements Have Been Added, Removed, Combined, and Reorganized
A simple numerical comparison between revisions can be misleading.
Revision 3 removes some requirements, adds others, and incorporates portions of certain Revision 2 requirements into broader multipart requirements. NIST explains that closely related requirements were sometimes grouped to improve efficiency and consistency with SP 800-53.
Consequently, organizations should avoid treating the transition as a one-to-one control renumbering project.
A useful analysis must identify whether each Revision 2 requirement was:
- Retained with limited changes
- Modified or expanded
- Incorporated into another requirement
- Withdrawn
- Replaced by a new requirement
- Split across multiple Revision 3 requirements
- Affected by an organization-defined parameter
NIST has published a formal Revision 2-to-Revision 3 change analysis to support this work.
6. Assessment Procedures Have Changed Too
Security requirements are only half of the equation.
NIST also published SP 800-171A Rev. 3, which updates the procedures used to assess implementation of the Revision 3 requirements. The assessment syntax was restructured to align more closely with NIST SP 800-53A, references were added to source procedures, and additional guidance was included on conducting assessments.
This matters because compliance cannot be evaluated solely by reading the requirement text.
Organizations must understand:
- What an assessor may examine
- Which personnel may be interviewed
- What mechanisms or processes may be tested
- What documentation should be retained
- What auditor- and compliance-formatted reporting and evidence demonstrates that a control operates as intended
A transition effort that updates policies but fails to update evidence collection will remain incomplete.
Consider the practical assessment scenario: an assessor requests proof that a control operated during a specific date range. The organization should be able to retrieve the relevant records quickly, show how the control was enforced, provide the evidence in a usable compliance format, route it to the responsible compliance owner, and demonstrate that the records were retained for the required period.
That is a very different operating model from assembling screenshots, spreadsheets, ticket exports, and informal attestations after the request arrives. Rev. 3’s more explicit assessment model increases the value of evidence that is continuously generated, correlated, retained, and ready when needed.
What Should Organizations Do Now?
The most effective preparation strategy is a controlled, dual-track approach.
Continue meeting the current baseline
Organizations subject to CMMC Level 2 should continue implementing and assessing the 110 requirements in Revision 2 unless their contracts or responsible agencies specify otherwise.
Revision 3 planning should not distract from current contractual duties or delay CMMC readiness.
Build a Revision 2-to-Revision 3 crosswalk
Map each current requirement to its Revision 3 successor or successors. Document changes in scope, specificity, ownership, technical implementation, assessment expectations, and evidence.
Identify new organizational stakeholders
The addition of planning, acquisition, and supply-chain requirements may require participation from teams that were less involved in the original Revision 2 program.
Control ownership should be assigned before implementation work begins.
Evaluate ODP governance
Create a repeatable process for receiving, assigning, approving, documenting, implementing, and periodically reviewing organization-defined parameters.
Reassess the CUI environment
Verify which systems process, store, or transmit CUI and which systems provide protection for those components. NIST states that Revision 3 applies to both categories.
Accurate scoping can reduce unnecessary complexity while ensuring that security dependencies are not overlooked.
This begins with accurate data identification. Contractors that cannot consistently identify and control CUI, ITAR-controlled information, export-controlled technical data, and other regulated information will struggle to apply the correct protections, scope systems appropriately, produce audit-ready evidence, and demonstrate compliance across a complex environment.
Modernize evidence collection
Determine which requirements can be supported through automated, repeatable, independently verifiable, and auditor-ready evidence. The objective is not simply to collect more telemetry. It is to correlate security activity across systems, connect it to the applicable NIST requirement, retain it for the required period, and produce it in a format that security, compliance, and assessors can use.
Examples may include:
- User and privileged-access activity
- Authentication and authorization events
- Configuration changes
- Security-policy enforcement
- File and system integrity events
- Vulnerability and remediation records
- Data access and movement
- Incident activity
- Audit-log generation and retention
- Supplier and software-component information
Automation does not replace policies, accountable personnel, or operational processes. It can, however, reduce manual effort and improve the consistency, timeliness, and credibility of assessment evidence.
How Fortra Can Support the Transition
The transition from Revision 2 to Revision 3 will require organizations to connect several elements that are too often managed separately:
- The applicable security requirement
- The technology and process used to implement it
- The evidence used to demonstrate that it is operating effectively
- The regulated data, users, systems, suppliers, and workflows that establish the scope
- The correlated telemetry and reporting needed to understand control performance over time
Fortra’s cybersecurity portfolio can help organizations build a more connected security and compliance operating model across data discovery and classification, access visibility, data protection, secure file transfer, system integrity monitoring, vulnerability and configuration management, security testing, and compliance evidence. The value is not merely having products in several categories. It is reducing fragmented tooling and vendor sprawl while connecting regulated data, user activity, configurations, vulnerabilities, integrity events, testing results, and control evidence to the NIST requirements they support.
Our approach is not to suggest that purchasing a product makes an organization CMMC compliant. CMMC readiness depends on the organization’s environment, scope, policies, processes, personnel, configurations, contractual obligations, and implementation decisions.
Technology should instead make security controls easier to implement, operate, monitor, and verify.
An interconnected platform can also improve overall security posture. Correlating telemetry across data, identity, infrastructure, file activity, vulnerability, configuration, and testing sources can help teams identify gaps earlier, validate whether protections are functioning, and provide compliance leaders with a clearer view of risk and readiness.
When an assessor asks for evidence covering a particular control and date range, the goal should be straightforward: retrieve the retained records, demonstrate the control, and hand off auditor- and compliance-formatted evidence without launching a manual reconstruction effort.
As organizations prepare for an eventual transition to Revision 3, Fortra can help them:
- Evaluate where existing security capabilities support current and future requirements
- Identify gaps between documented controls and technical enforcement
- Improve visibility into CUI, systems, users, access, and data movement
- Produce stronger and more repeatable technical evidence
- Reduce manual compliance activities through automation
- Support phased remediation and transition planning
- Maintain security outcomes while requirements and assessment models evolve
Prepare for Revision 3 Without Losing Focus on Today
Revision 3 is not the current CMMC Level 2 assessment baseline, but the Phase 2 pause should not be mistaken for a reduction in the underlying security expectation. Rev. 2 was withdrawn because Rev. 3 became NIST’s current publication, and Rev. 3 reaches further into governance, acquisition, supply-chain risk, logging, monitoring, testing, and provable control operation.
The organizations best prepared for the next phase will be those that continue meeting current Revision 2 and DFARS obligations while deliberately evaluating the Revision 3 delta. That preparation should include governance, technical controls, assessment evidence, system and data scoping, supply-chain risk, acquisition practices, testing, retention, and documented organizational decisions.
The goal is not to predict the exact date on which every contract will change.
The goal is to avoid beginning the transition only after the deadline is visible.
By establishing a transition roadmap now, organizations can make measured investments, reduce tool and vendor sprawl, incorporate new requirements into planned technology and process improvements, and avoid a larger and more disruptive transition once Rev. 3 is formally incorporated into CMMC and DFARS.
Fortra can help organizations assess current security capabilities, improve visibility into CUI and other regulated data, connect technical controls to NIST requirements, strengthen auditor-ready evidence, and prepare a practical transition path from today’s CMMC requirements toward the broader protection model established by NIST SP 800-171 Revision 3.
This article provides general cybersecurity and compliance information and does not constitute legal advice, certification advice, or a representation that any product or service independently satisfies CMMC or NIST requirements. Organizations should evaluate their specific contracts, systems, CUI environments, and agency guidance.
