3.14.1Find and fix flaws on a clock in Rev. 3
Reworded: 03.14.01 Flaw Remediation. Gains organization-defined parameters.
Status as of 2026-09-08
Rev. 2 is what a contract requires today. DFARS 252.204-7012 and the CMMC rule at 32 CFR 170 point at NIST SP 800-171 Rev. 2, and a standing DoD class deviation keeps it there. NIST has published Rev. 3, but publishing a revision does not change an obligation. A move to Rev. 3 would arrive through the Department's reform process and formal rulemaking, a change to that deviation or an amendment to the rule, not through publication. The Department has published its organization-defined parameter values for Rev. 3 in preparation; that is groundwork, not adoption.
Side by side
Rev. 2 · in force 3.14.1 Flaw Remediation
Assessment objectives · 800-171A
- [a] the time within which to identify system flaws is specified
- [b] system flaws are identified within the specified time frame
- [c] the time within which to report system flaws is specified
- [d] system flaws are reported within the specified time frame
- [e] the time within which to correct system flaws is specified
- [f] system flaws are corrected within the specified time frame
Rev. 3 · not adopted 03.14.01 Flaw Remediation
a. Identify, report, and correct system flaws.
b. Install security-relevant software and firmware updates within [Assignment: organization-defined time period] of the release of the updates.
Determination statements · 800-171A Rev. 3
- 03.14.01.a[01] system flaws are identified.
- 03.14.01.a[02] system flaws are reported.
- 03.14.01.a[03] system flaws are corrected.
- 03.14.01.b[01] security-relevant software updates are installed within <A.03.14.01.ODP[01]: time period> of the release of the updates.
- 03.14.01.b[02] security-relevant firmware updates are installed within <A.03.14.01.ODP[02]: time period> of the release of the updates.
Organization-defined parameters
- 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.
- 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.
Draws on Rev. 2 3.14.1.
Left: NIST SP 800-171 Rev. 2 and 800-171A, verbatim. Right: NIST SP 800-171 Rev. 3 and 800-171A Rev. 3, verbatim, with organization-defined blanks highlighted.
Word by word
The Rev. 2 requirement compared with its Rev. 3 successor. A mechanical comparison of the two verbatim texts, not an interpretation.
removed in Rev. 3 added in Rev. 3
Rev. 2 3.14.1 → Rev. 3 03.14.01 Flaw Remediation
6 words kept, 4 removed, 17 added. Rev. 3 statement labels omitted for the comparison.
What NIST says changed
- New security requirement title
- Aligned with SP 800-53, Rev 5 to provide more comprehensive detail on and foundational tasks for flaw remediation
- Added new ODP: time period to install security-relevant software and firmware updates
NIST, SP 800-171 Rev. 2 to Rev. 3 change analysis, class “Significant change”. At adoption, Bedrock files this under “Rework”.
NIST's Rev. 3 discussion for 03.14.01
Organizations identify systems that are affected by announced software and firmware flaws, including potential vulnerabilities that result from those flaws, and report this information to designated personnel with information security responsibilities. Security-relevant updates include patches, service packs, hot fixes, and anti-virus signatures. Organizations address the flaws discovered during security assessments, continuous monitoring, incident response activities, and system error handling. Organizations can take advantage of available resources (e.g., CWE or CVE databases) when remediating system flaws. Organization-defined time periods for updating security-relevant software and firmware may vary based on a variety of factors, including the criticality of the update (i.e., severity of the vulnerability related to the discovered flaw). Some types of flaw remediation may require more testing than other types.
What this means for you now
Nothing changes in what you are assessed against until a class deviation or a published rule adopts Rev. 3. Keep meeting 3.14.1 as written in Rev. 2, and if you already choose a value for the parameters above in practice, write it down where your system security plan can find it.
Bedrock CMMC shows this same comparison against your own package, with your current status on the Rev. 2 side, so the day adoption lands the migration is a review, not a rewrite.
Where this page's facts come from
- Rev. 2 text and objectives
- bedrock-cmmc-api@89b8e8e:migrations/004_reference_requirements.sql#Requirement.basicRequirement@rev2; bedrock-cmmc-api@89b8e8e:migrations/005_reference_objectives.sql#AssessmentObjective.description@rev2
- Mapping and change class
- bedrock-cmmc-api@89b8e8e:docs/reference/nist-800-171-rev3/normalized/r2_r3_transition_map.json#r2_to_r3
- Rev. 3 03.14.01
- bedrock-cmmc-api@89b8e8e:docs/reference/nist-800-171-rev3/normalized/rev3.json#requirements[]