How long must CMMC patch evidence be retained?

Artifacts used as CMMC assessment evidence must be retained six years from the CMMC Status Date under 32 CFR 170.15 through 170.17. Level 2 C3PAO evidence must also be hashed with a NIST-approved algorithm.

CMMC Compliance

CMMC Patch Management Requirements: What to Patch, How Fast, and How to Prove It

Q: Can a NOT MET SI.L2-3.14.1 go on a Conditional-status POA&M?

No. It is a 5-point requirement, and 32 CFR 170.21 generally restricts Level 2 POA&M items to 1-point requirements, with a narrow encryption exception and six expressly prohibited 1-point requirements. It cannot be deferred to reach Conditional status.

Q: Does CMMC patch-management software need FedRAMP?

Only when the service is a cloud service provider that processes, stores, or transmits CUI, in which case the offering must be FedRAMP Moderate Authorized or meet DoD equivalency requirements. A service that handles Security Protection Data but no CUI is assessed as a Security Protection Asset and does not automatically require FedRAMP.

By The Defense Compliance Report Editorial Team · Regulatory facts last verified: July 10, 2026· Editorial research — not formally reviewed by a CMMC Subject Matter Advisor.

This is educational research, not legal, contractual, or compliance advice. The Defense Compliance Report is an independent trade publication on CMMC 2.0 and DIB compliance. We are not affiliated with the Cyber AB, the Department of Defense, DCMA DIBCAC, NIST, or any U.S. government agency. Confirm scope and applicability with a CMMC Registered Practitioner (RP/RPO) or a qualified federal-contracts attorney — your contract clause and CUI handling set your level, not a checklist.

Bottom line up front

CMMC patch management requirements apply at both Level 1 and Level 2, and they demand more than a patched-endpoint dashboard. You must define your own timeframes to identify, report, and correctsoftware and firmware flaws — then prove, with operational records, that you actually met them. CMMC does not set a universal 30-day patch deadline. At Level 2, the core flaw-remediation control (SI.L2-3.14.1) is worth 5 points, and under the CMMC scoring and POA&M rules a NOT MET flaw-remediation finding cannot be carried on a Plan of Action and Milestones to reach even Conditional Level 2 status.

The recurring error this page corrects: contractors treat one patch deadline as the CMMC rule. The requirement isn’t testing whether you patch. It’s testing whether you decided how fast to patch, wrote it down, and can show you hit your own clock. Miss that distinction and a well-patched network can still be assessed NOT MET.

Quick answer: CMMC patch management at a glance

Your question	The direct answer
Is patch management required at Level 1?	Yes. SI.L1-b.1.xii (Flaw Remediation), from FAR 52.204-21, applies to systems that handle Federal Contract Information (FCI).
Is it required at Level 2?	Yes. SI.L2-3.14.1 applies flaw remediation to your Controlled Unclassified Information (CUI) scope, plus related scanning and remediation controls.
Does CMMC mandate patching within 30 days?	No. There is no universal deadline. Your timeframes must be defined, risk-informed, followed, and evidenced.
How many things must you prove?	Six. Specify and then meet an identify clock, a report clock, and a correct clock.
Is a specific patch tool required?	No. No product is prescribed. The process and evidence are what get assessed.
Does a cloud patch tool automatically need FedRAMP?	No. It depends on whether it’s a cloud service handling CUI, versus a service handling only security-protection data, versus neither.
Can a NOT MET SI.L2-3.14.1 go on a POA&M for Conditional status?	No. It’s a 5-point control, and only 1-point items generally qualify for a Level 2 POA&M.
How long do you keep the evidence?	Six years from the CMMC Status Date; C3PAO assessment artifacts must also be hashed.

The Defense Compliance Report is the independent CMMC decision layer

Who this guide is for:the person who owns — or just inherited — patching and vulnerability management inside a defense contractor or subcontractor. IT manager, sysadmin, security lead, fractional CISO, FSO, or the owner who’s realized “our MSP handles updates” is not an answer they can defend. Your immediate question isn’t which tool — it’s can our current process survive an assessment, and if not, what exactly has to change? That’s the question this page ends.

Who it’s not for:if you want a ranked list of the “best” patch-management vendors, this isn’t that page — and no honest page should pretend a product purchase satisfies a control. If you’re still figuring out whether you’re even Level 1 or Level 2, start with our CMMC Level 1 vs Level 2 guide, because your required level changes which of these controls apply.

The right CMMC provider isn’t the same for every contractor. Use The Defense Compliance Report’s Find My CMMC Path tool to map your situation to the right provider category before you request quotes. Do not submit CUI, drawings, credentials, or sensitive contract details. The CMMC Path Framework routes to a provider category, not a named provider.

What are the CMMC patch management requirements?

Answer: CMMC requires you to define measurable timeframes for identifying, internally reporting, and correcting applicable information-system flaws — including software and firmware flaws — meet those timeframes, and back the result with final operational evidence. The core control is SI.L2-3.14.1 at Level 2 and SI.L1-b.1.xii at Level 1, both titled “Flaw Remediation.” Each is assessed against six objectives.

The phrase “patch management” never actually appears as a CMMC control. What exists is a small cluster of requirements that together form what everyone informally calls patch management. Here’s that cluster in one place — drawn from FAR 52.204-21, NIST SP 800-171 Rev. 2, and the CMMC scoring methodology at 32 CFR § 170.24.

Core and directly adjacent CMMC patch-management controls

“Point value” is the deduction if the requirement is scored NOT MET under 32 CFR § 170.24. POA&M eligibility depends on the overall score and the § 170.21 conditions, not on point value alone.

Control	What it requires (plain terms)	Points if NOT MET	POA&M-eligible at Level 2?	Applies at Level 1?
SI.L2-3.14.1 — Flaw Remediation	Identify, report, and correct system flaws in a timely manner	5	No	Yes (as SI.L1-b.1.xii)
RA.L2-3.11.2 — Vulnerability Scanning	Scan for vulnerabilities periodically and when new ones are identified	5	No	No
RA.L2-3.11.3 — Vulnerability Remediation	Remediate vulnerabilities in line with risk assessments	1	Potentially — subject to the 88/110 score floor and § 170.21 exclusions	No
SI.L2-3.14.4 — Update Malicious Code Protection	Update anti-malware engines/signatures when new releases ship	5	No	Yes (SI.L1-b.1.xiv)
SI.L2-3.14.5 — System & File Scanning	Periodic scans + real-time scans of externally sourced files	3	No	Yes (SI.L1-b.1.xv)
SI.L2-3.14.3 — Security Alerts & Advisories	Monitor advisories and act on them	5	No	No
CM.L2-3.4.1 — Baseline & Inventory	Maintain baseline configs and a hardware/software/firmware inventory	5	No	No
CM.L2-3.4.3 — Change Management	Track, review, approve, and log changes (patches are changes)	1	Potentially — subject to the 88/110 score floor and § 170.21 exclusions	No

Sources: FAR 52.204-21 · NIST SP 800-171 Rev. 2 · 32 CFR § 170.24 (scoring)

You cannot POA&M your way past patch management. Because SI.L2-3.14.1 and RA.L2-3.11.2 are 5-point controls, and a Level 2 POA&M generally may not include any requirement worth more than 1 point, a NOT MET flaw-remediation or vulnerability-scanning control cannot be carried on a Conditional Level 2 POA&M. If either control is NOT MET when the assessor finalizes the finding, you cannot reach even Conditional Level 2 status.

The exact source stack (so you can verify us)

Level 1: SI.L1-b.1.xii, "Flaw Remediation," is one of the 15 basic safeguarding requirements. Its source text is FAR 52.204-21(b)(1)(xii): "Identify, report, and correct information and information system flaws in a timely manner." The DoD’s current CMMC Level 1 Assessment Guide (Version 2.13) labels the requirement SI.L1-b.1.xii. Older vendor pages call it "SI.L1-3.14.1" after the retired v2.0 numbering; the current identifier references FAR paragraph b.1.xii, not the NIST control number.
Level 2: SI.L2-3.14.1 applies flaw remediation to your CUI scope, drawn from NIST SP 800-171 Rev. 2, requirement 3.14.1. Level 1 addresses "information and information system flaws"; Level 2 addresses "system flaws." Both are assessed through the same six identify/report/correct objectives.
The version question: CMMC Level 2 is pinned to NIST SP 800-171 Revision 2, not Revision 3. That pin is set by 32 CFR § 170.14 (which incorporates Rev. 2 by reference), and DoD resolved the DFARS "most current version" mismatch through a May 2024 class deviation. Rev. 3 will require future rulemaking before it changes anything for CMMC.

What “report system flaws” actually means

In this control, “report” means notifying designated internal personnel with information-security responsibilitiesthat an applicable flaw exists — a ticket assigned, an alert acknowledged, an escalation logged. It is not, by itself, the DFARS 252.204-7012 report required within 72 hours when that clause applies. Those are two different obligations. Your policy needs both a designated recipient (a role, not just “IT”) and a defined period.

What counts as a “security-relevant update”: Security-relevant updates include patches, service packs, hot fixes, and anti-virus signatures. But correction isn’t limited to installing a vendor patch — a configuration change, a documented workaround, or isolating an asset can also correct or mitigate a flaw, as long as the underlying objective is genuinely satisfied.

Does CMMC require patch management at both Level 1 and Level 2?

Answer: Yes — at both levels, but the surrounding requirements differ. Level 1 applies flaw remediation (SI.L1-b.1.xii) to systems that process, store, or transmit FCI, as a pass/fail self-assessment with no POA&M allowed. Level 2 applies SI.L2-3.14.1 to your CUI scope and layers on vulnerability scanning (RA.L2-3.11.2), risk-based remediation (RA.L2-3.11.3), configuration and change controls, security alerting, and continuous monitoring.

Level 1 — FCI, pass/fail bar

SI.L1-b.1.xii: same identify/report/correct discipline
Annual self-assessment; every requirement must be MET
No POA&M permitted at any time
No partial credit, no deferral
RA.L2-3.11.2 and RA.L2-3.11.3 are Level 2 controls — don’t let a consultant sell you the full Level 2 stack to satisfy Level 1
DIBCAC historical data (117 assessments, 2019–2022): 3.14.1 was the only Level 1 requirement in the Top 10 “Other Than Satisfied” list

Level 2 — CUI, real ecosystem

SI.L2-3.14.1: flaw remediation with organization-defined timeframes
RA.L2-3.11.2: periodic + event-driven vulnerability scanning
RA.L2-3.11.3: risk-based remediation
CM.L2-3.4.1 / 3.4.3 / 3.4.4: inventory, change management, impact analysis
Assessment path set by your contract, not this checklist
For self-assessment vs C3PAO differences, see our → scoping guide

Level 3 — briefly: Level 3 builds on a Final Level 2 (C3PAO) status and adds 24 selected enhanced requirements from NIST SP 800-172. See our CMMC Level 3 guide rather than treating this page as a Level 3 resource.

Level 1 vs Level 2 patch requirements, side by side

Factor	Level 1 (FCI)	Level 2 (CUI)
Protected information	Federal Contract Information	Controlled Unclassified Information
Core flaw-remediation control	SI.L1-b.1.xii	SI.L2-3.14.1
Objectives to prove	6	6
Assessment path	Annual self-assessment	Self or C3PAO, per the contract
Vulnerability scanning control	Not a separate Level 1 requirement	RA.L2-3.11.2
Risk-based remediation control	Not a separate Level 1 requirement	RA.L2-3.11.3
POA&M available?	No	Limited; not for a NOT MET 5-point SI.L2-3.14.1
Assessment-artifact retention	6 years from Status Date	6 years; hashing required for C3PAO evidence

Not sure whether patching alone puts you in scope, or whether your MSP’s tooling counts as part of your boundary? Use Find My CMMC Path — answer a few scope questions and it maps you to the provider category that fits, before you spend a dollar on quotes. Do not submit CUI, drawings, credentials, or sensitive contract details.

How fast do patches have to be installed for CMMC?

Answer: CMMC does not set one universal number of days for every patch. Your organization defines its own identification, reporting, and correction periods, applies them consistently, and makes them credible in light of severity, exploitability, exposure, operational impact, available mitigations, and any testing needed. The Level 2 assessment guide is explicit that these periods are organization-defined and may vary based on factors including the criticality of the update.

CMMC will not hand you a safe patch deadline to copy. Anyone who tells you “the CMMC-required window is 30 days” is describing a rule that doesn’t exist. A 30-day policy is not automatically compliant. A 90-day policy is not automatically non-compliant. There is no government safe-harbor number for you to paste into a template and call it done.

Words like “regularly,” “promptly,” and “as soon as practical” do not, by themselves, prove that a timeframe has been specified. Pair them with a measurable trigger and period; otherwise objectives [a], [c], or [e] (the ones that require you to specify a period) can be assessed NOT MET. And a period you consistently blow past produces evidence against objectives [b], [d], and [f] (the ones that require you to meet it). You need numbers, triggers, and records.

The three-clock model: turn six objectives into a process you can run

DCR editorial framework — not a government deadline, not a CMMC score, and not a guarantee of any assessment outcome. It maps one-to-one onto what the assessor scores.

Clock	Define the start trigger in your policy	The clock stops when…	Proof artifact
Identify clock (objectives [a], [b])	An authoritative advisory publishes, a scan detects, a vendor notifies, or an assessment surfaces a flaw	You’ve determined whether it affects an in-scope asset and recorded the result	Advisory timestamp + asset-applicability record
Report clock (objectives [c], [d])	An applicable flaw is identified or crosses your reporting threshold	A designated owner receives and accepts it for action	Ticket assignment / alert acknowledgement / escalation record
Correct clock (objectives [e], [f])	Your defined event — usually applicability confirmed or risk classified	Correction or documented mitigation is deployed and verified	Deployment/change record + rescan/verification + closure note

What should change your correction deadline

Factor	Why it moves the deadline
Known active exploitation (e.g., listed in CISA’s Known Exploited Vulnerabilities Catalog)	Raises real-world likelihood; usually forces emergency handling
Internet exposure	Larger reachable attack surface
CUI proximity	Changes the consequence if exploited
Privilege level / remote-code potential	Changes exploit impact
Asset and mission criticality	Changes operational and security stakes
Patch availability	Determines whether normal correction is even possible
Workaround availability	May allow immediate risk reduction while you schedule the fix
Testing requirement	May justify staged deployment — documented, not silent
Vendor support / end-of-life status	Changes the feasible remediation path
Contract or program deadline	May override your normal internal period entirely

Testing is not permission to make the flaw invisible. Some remediation needs testing before it hits production, and the assessment guide recognizes safe implementation. But the delay has to be visible in the record— a test result, a mitigation in place, an owner, a defined correction date. “We were testing” with nothing written down reads as “we missed the clock.”

Which deadline actually applies? CMMC Rev. 2 vs Rev. 3 ODPs vs FedRAMP 2026

Answer: As of July 10, 2026, the only patch timeframe that binds your current CMMC Level 2 assessment is the one youdefine under NIST SP 800-171 Rev. 2. The familiar 30/90/180-day numbers are real — but they come from FedRAMP and from DoD’s Revision 3 organization-defined parameters, neither of which currently controls SI.L2-3.14.1.

Source / baseline	Published patch timeframe	Controls current CMMC Level 2?	Current status (July 2026)
CMMC Level 2 (NIST SP 800-171 Rev. 2)	None specified — organization-defined; no universal 30/90/180	Yes — this is the governing baseline	Pinned to Rev. 2 via 32 CFR § 170.14 and a May 2024 class deviation
DoD Rev. 3 ODP values (April 10, 2025 memo)	30 days high-risk, 90 days moderate, 180 days low, from date of discovery	No — not the current CMMC assessment baseline	Preparation guidance; not the requirement until DoD changes the rule and deviation
FedRAMP (Consolidated Rules for 2026)	Traditional 30/90/180 CSP parameters, moving to Vulnerability Detection & Response model	No — matters only in the applicable CSP/FedRAMP scenario	Vulnerability Detection & Response becomes mandatory for cloud offerings on Dec. 7, 2026, with a corrective-action grace period through March 7, 2027
CISA Binding Operational Directive	Directive-specific	No — binds covered federal agencies	Controls a contractor only where the directive is made applicable to that contractor or system

Sources: DoD ODP memorandum, April 10, 2025 · FedRAMP 2026 Vulnerability Detection and Response

Which controls make up a complete CMMC patch-management program?

Answer: SI.L2-3.14.1 is the core, but a defensible Level 2 program depends on knowing what assets exist, finding vulnerabilities, prioritizing by risk, controlling changes, monitoring advisories, managing deficiencies, and confirming the fix held. Treat patching as an isolated endpoint setting and your evidence chain has holes an assessor will find.

Control	Why it changes the patch workflow	Artifact that proves the connection
CM.L2-3.4.1 — Baseline & inventory	You can’t prove patch coverage without a complete hardware/software/firmware inventory	Current asset + software/firmware inventory
CM.L2-3.4.3 — Change management	Patches are changes; approvals, windows, and rollback live here	Change ticket with approval and rollback plan
CM.L2-3.4.4 — Security impact analysis	Pre-deployment testing and impact review before you push a patch	Impact analysis + test result
RA.L2-3.11.2 — Vulnerability scanning	Detects missing patches and weaknesses, including on printers, appliances, firmware	Scan result at your defined cadence
RA.L2-3.11.3 — Risk-based remediation	Determines treatment when severity alone isn’t the whole story	Remediation rationale tied to risk
CA.L2-3.12.2 — Operational plan of action	Documents temporary deficiencies after implementation	Operational plan entry (not a POA&M)
CA.L2-3.12.3 — Ongoing monitoring	Shows the process keeps working over time	Overdue/failed-deployment/exception-age metrics
SI.L2-3.14.3 — Security alerts & advisories	The advisory-to-action link (vendor notices, CISA alerts)	Advisory reviewed → action record

A 98% patch dashboard can still omit uninventoried assets; the percentage is only as complete as its asset population. That’s why CM.L2-3.4.1 sits underneath everything — the missing 2% is usually the switch, hypervisor, or firmware nobody inventoried.

Three “scanning” things people mix up

1Vulnerability scanning (RA.L2-3.11.2) finds weaknesses and missing patches.
2Malicious-code / file scanning (SI.L2-3.14.5) is anti-malware — periodic scans of the system plus real-time scanning of externally sourced files.
3Penetration testing is not a universal, named Level 2 requirement. Level 2 requires vulnerability scanning, risk-based remediation, and security-control assessments; you may use pen testing as a risk activity, but the rule doesn’t mandate it.

For the full control set and assessment objectives, see our NIST 800-171 requirements checklist and NIST 800-171A assessment objectives.

How often does CMMC require vulnerability scanning?

Answer: RA.L2-3.11.2 requires vulnerability scanning at an organization-defined periodic frequency andwhen new vulnerabilities affecting the system or applications are identified. In the current CMMC Level 2 Assessment Guide, “periodically” means a regular interval you choose that may not exceed one year — one year is the regulatory ceiling, not a recommended operating cadence.

Two triggers, not one: a scheduled scan at your defined interval, and an event-drivenscan when a new relevant vulnerability surfaces. Programs that only run the calendar scan and skip the “new vulnerability identified” trigger routinely miss this control. Pick a cadence you can actually sustain and evidence — and make sure your policy and your scan logs both show the event-driven trigger in action, not just the monthly or quarterly job.

What patch-management evidence will a CMMC assessor expect?

Answer: Expect an assessor to examine your documents and records, interview the people who run the process, and test whether your mechanisms actually identify, report, install, and verify updates. The strongest evidence is a single unbroken thread that follows one real flaw from authoritative notice → asset applicability → owner → deadline → testing → deployment or mitigation → verified closure.

Examine

Flaw-remediation and configuration-management procedures
System security plan
List of flaws potentially affecting the system
List of recent remediation actions (patches, service packs, hot fixes)
Test results from update installations
Installation/change-control records for security-relevant updates

Interview

System and network administrators
Security personnel
People who own patching and configuration management

Test

How a person maps to a role
How a changed duty triggers retraining
Processes and mechanisms used to identify, report, correct, install, and test updates

The evidence pack, mapped to the six objectives

Objective	Policy evidence	Operational evidence	What the assessor tests / asks
[a] Define identify period	Approved cadence + trigger	Source-monitoring schedule	“When does your identify clock start?”
[b] Identify on time	Applicability procedure	Advisory + scan + asset match	Reproduce a recent applicability decision
[c] Define report period	Reporting/escalation matrix	Designated role documented	“Who gets told, and by when?”
[d] Report on time	Ticket workflow	Assignment/acknowledgement timestamp	Trace one flaw to its owner
[e] Define correct period	SLA + exception procedure	Required-by date generated	Explain the severity/asset logic
[f] Correct on time	Deployment + verification procedure	Patch/workaround + rescan	Show status and how failed installs were handled

Build one “golden thread” before your assessment

Pick one real, recent flaw and document the whole arc: vendor publishes advisory → you review it → inventory shows the affected version → ticket created → security owner receives it → severity and exposure evaluated → required-by date generated → patch tested → change approved → patch deployed → failed endpoints separated and handled → rescan verifies correction → ticket closed → evidence indexed. One clean thread proves more than a thousand dashboard rows.

Policy alone is not proof.The scoring rule at 32 CFR § 170.24 treats evidence as something that must be in final form and reflect actual implementation, not intent. Draft policies, planned tools, and “we’re rolling this out next quarter” don’t count.

A 2019 DoD Office of Inspector General review (DODIG-2019-105) identified deficiencies that included identifying and mitigating network and system vulnerabilities in a timely manner according to the contractors’ own individual policies — from a nonstatistical sample of nine contractors, not a representative DIB-wide study. The signal is clear: if your policy creates a measurable clock, your records need to show you met it.

Staring at your ticket system wondering whether you need help — and what kind? Use Find My CMMC Path to map your level, scope, environment, and timeline to the right provider category. Want a self-serve checklist first? Our CMMC readiness checklist lets you mark exactly where your patch evidence breaks before you talk to anyone.

Can an unpatched vulnerability go on a CMMC POA&M?

Answer: Not the way most people think. A NOT MET Level 2 flaw-remediation requirement is a 5-point item, and under 32 CFR § 170.21 it cannot be carried on a POA&M to reach Conditional CMMC Status. But a properly implemented program can carry an operational plan for a temporary deficiency, or an SSP-documented enduring exception, and those are assessed differently.

Three documents people all call “the POA&M”

The implementation project plan: Your internal “we’re building this” roadmap. It does not make an unimplemented objective MET.

The operational plan of action: An ongoing record for temporary deficiencies that arise after implementation. Per 32 CFR § 170.4, this does not identify a timeline for remediation and is not the same as a POA&M, which is associated with an assessment and must be completed within 180 days.

The assessment POA&M: The limited, formal route to Conditional CMMC Status for eligible NOT MET requirements, closed within 180 days.

Why SI.L2-3.14.1 can’t be deferred

Under 32 CFR § 170.21, to achieve Conditional Level 2 status your assessment score divided by the total number of Level 2 requirements must be at least 0.8 (88 out of 110), and none of the requirements on the POA&M may have a point value greater than 1 (with a narrow exception for the encryption control SC.L2-3.13.11). Six specific 1-point requirements are also expressly prohibited. Flaw remediation is a 5-point control with no exception. If SI.L2-3.14.1 is NOT MET, it has to be MET before the assessor finalizes the finding.

One nuance: under 32 CFR § 170.17 an assessor may re-evaluate NOT MET objectives during the assessment and for up to ten business days afterward when additional evidence becomes available. Do not treat that narrow evidence-re-evaluation window as permission to buildan absent patch process after the assessment starts. It’s for evidence you already had, not work you haven’t done.

For the full mechanics of Conditional vs Final status and the 180-day closeout, see our CMMC POA&M template guide.

CMMC patching POA&M decision table

Situation	Likely treatment	Why
Flaw-remediation process is absent, unfinished, or merely planned	NOT MET	One or more objectives aren’t satisfied; drafts don’t count
SI.L2-3.14.1 is NOT MET at a Level 2 assessment	Not eligible for a Conditional-status POA&M	It’s a 5-point control; § 170.21 generally allows only 1-point items
Level 1 flaw remediation is NOT MET	No POA&M permitted	Level 1 allows no POA&M at any time
Implemented process hits an isolated temporary deficiency after implementation	May be assessed MET when handled in an operational plan	§ 170.24 permits properly addressed temporary deficiencies to score as implemented
A genuine enduring exception is documented with mitigations in the SSP	May be assessed MET where facts support it	The rule expressly recognizes enduring exceptions
“We intend to deploy a patch tool next quarter”	NOT MET	Evidence must be final and demonstrate actual implementation

Does CMMC patch-management software need FedRAMP?

Answer: Not automatically. It depends on whether the external service is a Cloud Service Provider (CSP), whether its systems process, store, or transmit CUI or Security Protection Data (SPD), and what security function it provides. The definition of Security Protection Data at 32 CFR § 170.4 includes data about the security posture of in-scope assets — which means the vulnerability status and configuration information your patch tool collects can itself be SPD, even if no CUI ever touches it.

Before classifying a patch tool, answer these:

Does it receive CUI?
Can support staff view CUI through remote access?
Does it store screenshots, files, or transferred data?
Does it hold vulnerability status, configurations, logs, credentials, or device details?
Is it a Cloud Service Provider?
Is there a Customer Responsibility Matrix?
Can any CUI-capable features be disabled — and can you evidence that?

The five-scenario patch-tool scope matrix

Conditional decision paths, not product-level determinations.

Patch-tool scenario	CMMC treatment	FedRAMP automatically applies?	What to document
Self-hosted patch server protecting CUI assets	Security function generally makes the component a Security Protection Asset in scope	No external CSP requirement just from hosting it yourself	Inventory, boundary, privileged access, config, data flow, control mapping
Cloud patch service that processes/stores/transmits CUI	If it’s a CSP handling CUI, the offering must be FedRAMP Moderate Authorized or meet DoD’s applicable FedRAMP Moderate-equivalency requirements	Yes — in that scenario	Authorization/equivalency evidence, SSP, CRM, CUI flow
Non-CSP external service that handles CUI	The relevant services are in your assessment scope and assessed against Level 2	Not via the CSP branch, but the service is assessed in scope	Service description, SSP relationship, CRM, controls
Cloud/external patch service handling SPD but no CUI	Assessed as a Security Protection Asset	No automatic FedRAMP trigger merely for handling SPD	Exact data fields, disabled CUI features, connections, SSP/CRM
Provider handling neither CUI nor SPD	Doesn’t meet the External Service Provider definition on that basis	No	Evidence for the no-CUI/no-SPD conclusion; the local agent may still be in scope

Source: 32 CFR § 170.4 (definitions) · 32 CFR § 170.19 (scoping). Never classify a named patch product from its homepage alone. Validate the actual deployment model, the enabled features, the data fields, and the real CUI/SPD flow. For the full External Service Provider, MSP, and CSP treatment, see our CMMC requirements for MSPs.

What if you can’t patch it? Legacy, OT, and the machine-shop problem

Answer: An asset doesn’t automatically fail CMMC because a vendor patch can’t be installed — and it isn’t automatically fine because it’s isolated. Treatment depends on the asset category, actual FCI/CUI capability, the technical limitation, your risk-based safeguards, and whether the situation is a temporary deficiency, an enduring exception, a specialized asset, or an unimplemented requirement dressed up as an exception.

When an enduring exception may apply

An enduring exception may apply only where remediation and full compliance genuinely are not feasible and the circumstance is documented in the system security plan. Per 32 CFR § 170.4, an enduring exception is a special circumstance where remediation and full compliance with CMMC security requirements is not feasible — examples include systems required to replicate the configuration of “fielded” systems, medical devices, test equipment, OT, and IoT. No operational plan of action is required, but the circumstance must be documented within the SSP.

Specialized assets under 32 CFR § 170.19 must be documented in your asset inventory, SSP, and network diagram. For how these fit your boundary, see our CMMC scoping guide.

Edge-case handling table

Scenario	Immediate action	Evidence needed	What NOT to claim
Patch failed on a subset of endpoints	Separate failures, mitigate, retry, verify	Failure report, owner, mitigation, rescan	“The dashboard said 98%, so it’s met everywhere”
Vendor patch unavailable	Assess exposure, apply workaround, monitor vendor	Advisory, no-fix evidence, mitigation, review cadence	“No patch means no obligation”
End-of-life software	Escalate replacement or isolation	EOL notice, risk, segmentation, migration plan	“Air-gapped automatically means safe”
OT / IIoT / CNC controller	Confirm asset category, document treatment	Inventory, network diagram, SSP, safeguards	“All OT is excluded from CMMC”
Government-furnished equipment (GFE)	Determine who controls config and constraints	GFE status, responsibility, boundary	“Government-owned means out of scope”
Patch breaks validated production software	Preserve test result, mitigate, coordinate with vendor	Failed test, business impact, isolation, operational plan	“Production risk lets us ignore the correct clock”
SaaS app controlled by the vendor	Define customer/vendor responsibilities	CRM/SRM, service notices, update evidence	“SaaS means the vendor owns the whole control”
Offline asset	Define how it receives advisories and updates	Manual review + controlled update records	“Offline systems have no software flaws”

How long must CMMC patch evidence be kept?

Answer: Artifacts used as CMMC assessment evidence must be retained for six years from the CMMC Status Date, across Level 1 and both Level 2 paths. For a Level 2 C3PAO certification assessment, you must additionally hash the assessment artifacts with a NIST-approved hashing algorithm.

Assessment path	Artifact retention	Integrity requirement
Level 1 self-assessment	6 years from Status Date	No separate C3PAO hashing rule
Level 2 self-assessment	6 years from Status Date	Retain the artifacts used to support the self-assessment
Level 2 C3PAO assessment	6 years from Status Date	Hash artifacts with a NIST-approved algorithm; maintain the hash list

Sources: 32 CFR § 170.15 (Level 1) · § 170.16 (Level 2 Self) · § 170.17 (Level 2 C3PAO)

Before an assessment: freeze an evidence index, record each artifact’s source system and owner, export volatile cloud reports, preserve timestamps and context, hash the final C3PAO set, and protect the archive from routine ticket-deletion. The rule governs the artifacts used as assessment evidence— it doesn’t say every routine patch log must be kept six years. Set your operational log retention long enough to demonstrate the process over time, and separately freeze and preserve the exact evidence set used at assessment.

How to build a CMMC-ready patch-management process

Build it as a closed evidence loop:define scope → monitor authoritative sources → determine applicability → report and assign → prioritize by risk → test and analyze impact → approve and deploy → verify → manage exceptions → preserve evidence and monitor performance. A tool can automate several steps, but you still own the decisions, the records, and the proof.

Step	Official objective / control	Required decision	Minimum artifact	Failure signal
1. Define applicable scope	CM.L2-3.4.1; § 170.19	Which FCI/CUI, SPA, firmware, network, and external services are in scope	Scoped asset inventory	Inventory omits switches, firmware, appliances
2. Maintain software/firmware visibility	CM.L2-3.4.1	Tie products/versions to asset IDs and owners	Version-mapped inventory	No owner or version per asset
3. Select authoritative flaw sources	SI.L2-3.14.1[a]; SI.L2-3.14.3	Which advisories, CISA KEV, NVD, scanner feeds you monitor	Documented sources + schedule	Waiting on auto-update only
4. Define all three clocks	SI.L2-3.14.1[a][c][e]	Trigger, period, owner, exception route	Approved policy with periods	“Regularly” with no number
5. Determine applicability	SI.L2-3.14.1[b]	Whether the flaw hits an in-scope asset	Applicability record	No record of the evaluation
6. Report, acknowledge, assign	SI.L2-3.14.1[c][d]	Who owns it, by when	Ticket assignment/acknowledgement	Scanner finds it; no human owns it
7. Prioritize by risk	RA.L2-3.11.3	Exposure, exploitability, CUI proximity, mission effect	Risk rationale	CVSS alone drives everything
8. Test and analyze impact	CM.L2-3.4.4	Whether testing is needed before deployment	Test result + impact analysis	Delay with no documented reason
9. Approve and log the change	CM.L2-3.4.3	Routine vs emergency change path	Change record + rollback plan	No approval trail
10. Deploy or mitigate	SI.L2-3.14.1[f]	Patch, workaround, config change, or isolate	Deployment/mitigation record	Failed/offline assets excluded silently
11. Verify	SI.L2-3.14.1[f]	Confirm the fix took and held	Rescan/version check	Ticket closed on “install attempted”
12. Manage exceptions, metrics, retention	CA.L2-3.12.2; CA.L2-3.12.3	Temporary deficiency vs enduring exception; ongoing monitoring	Operational plan/SSP entry + metrics + evidence index	Every overdue patch called a “POA&M”

Quick consistency test: does your written policy actually match your SSP, your inventory, your tool configuration, your scanner cadence, your ticket fields, your change procedure, and your evidence archive? Any material contradiction becomes an evidence problem an assessor can act on.

Who should own patch management, and which CMMC provider category helps?

Answer: You remain accountable for the requirement even when a service provider runs the tooling. Internal IT, an MSP or MSSP, an RP/RPO, a GRC platform, a CUI enclave provider, and a C3PAO each solve a different part of the problem — and the right category depends on whether your gap is operations, readiness, evidence workflow, architecture, or formal assessment.

Role in your patch program	Internal IT	MSP / MSSP	RP / RPO	GRC platform	CUI enclave	C3PAO
Operates patching day to day	✓	✓	–	–	(within enclave)	–
Writes/aligns the procedure & SSP	✓	sometimes	✓	–	–	–
Supplies/organizes evidence	✓	✓	✓	✓	–	–
Makes risk decisions	✓	with you	advises	–	–	–
Conducts the formal assessment	–	–	–	–	–	✓
Conflict/impartiality constraint applies	–	–	–	–	–	✓ (see below)
Stays your responsibility regardless	✓	✓	✓	✓	✓	✓

MSP / MSSPFor running the tooling, deployment, vulnerability workflows, and evidence exports day to day. Require a service description, a responsibility matrix, a data-flow explanation, and assessment support.

RP / RPOFor readiness analysis, SSP and procedure alignment, objective mapping, and remediation coordination. Verify current Cyber AB status where the designation is claimed.

GRC platformFor control mapping, evidence workflow, approvals, exceptions, and continuous documentation. It doesn’t install patches unless paired with operational tooling, and software alone never satisfies CMMC.

CUI enclaveFor shrinking or rebuilding the CUI scope so the operational patch burden gets smaller. It’s an architecture decision, not a substitute for patching the enclave itself.

C3PAOFor the formal Level 2 certification assessment, once you’re assessment-ready. Cyber AB CAP v2.0 requires the C3PAO to identify and manage impartiality and conflicts, and to decline the assessment when a conflict cannot be sufficiently mitigated. DCR recommends using separate readiness and assessment firms as a conservative conflict-control practice.

Map the provider category that fits your patch-management gap → — use The Defense Compliance Report’s Find My CMMC Path tool to map your level, FCI/CUI scope, assessment type, environment, and timeline to the right provider category. It doesn’t rank providers or determine compliance. Do not submit CUI, drawings, credentials, or sensitive contract details. For a fuller picture of the categories, see CMMC provider categories.

Disclosure: The Defense Compliance Report is an independent trade publication on CMMC 2.0 and DIB compliance. We may receive compensation for qualified introductions, sponsorships, or partner referrals when disclosed. Compensation does not control our regulatory analysis, provider-category recommendations, or Cyber AB status verification.

What The Defense Compliance Report actually verified for this guide

Source checked	What it supports	Verified
FAR 52.204-21	(b)(1)(xii) flaw-remediation requirement; (xiii)–(xv) malicious-code, update, and scanning safeguards	July 10, 2026
CMMC Assessment Guide, Level 1 (v2.13)	The SI.L1-b.1.xii label, the six objectives, evidence objects, MET/NOT MET findings	July 10, 2026
CMMC Assessment Guide, Level 2	SI.L2-3.14.1, six objectives, org-defined timing, scan-cadence ceiling, evidence	July 10, 2026
NIST SP 800-171 Rev. 2	3.14.1, scanning (3.11.2), risk remediation (3.11.3)	July 10, 2026
32 CFR § 170.4	Temporary deficiency, enduring exception, operational plan, SPD	July 10, 2026
32 CFR § 170.19	Scoping, specialized assets, CSP/SPD treatment	July 10, 2026
32 CFR § 170.21	POA&M eligibility, 0.8 / 88-of-110 threshold, 1-point rule	July 10, 2026
32 CFR § 170.24	Scoring, point values, final-evidence requirement	July 10, 2026
§§ 170.15–170.17	6-year retention, C3PAO artifact hashing, SPRS/eMASS posting	July 10, 2026
DoD Rev. 3 ODP memo (Apr. 10, 2025)	30/90/180 Rev. 3 flaw-remediation values (not current CMMC baseline)	July 10, 2026
FedRAMP 2026 Vulnerability Detection & Response	FedRAMP CR26 transition dates	July 10, 2026
DODIG-2019-105	Contractors missing their own remediation timeframes (non-representative sample)	July 10, 2026

See our editorial methodology, editorial standards, corrections policy, and editorial and advertising policy.

What to do next

Start by testing one real, recent flaw against all six objectives — not by buying another tool.

Use this one-flaw worksheet to run the test:

Field	Your entry
Advisory received / detected date	(fill in)
Applicability decision date (objective [b])	(fill in)
Internal report / assignment date (objective [d])	(fill in)
Correction due date (objective [e])	(fill in)
Action taken (patch / workaround / config / isolate)	(fill in)
Verification date (objective [f])	(fill in)
Exception classification (none / temporary deficiency / enduring exception)	(fill in)
Artifact filename(s)	(fill in)
Objectives proven [a]–[f]	(fill in)

Today: confirm your contract-required CMMC status; confirm FCI/CUI scope; pick one recently announced flaw; trace all six objectives; note where the trail breaks.

This week:approve measurable identify/report/correct periods; reconcile your asset and software/firmware inventories; separate successful/failed/offline/excepted assets; document your patch tool’s CUI/SPD data flow; assign evidence ownership.

Before an assessment: sample multiple severity levels and asset classes; validate your temporary deficiencies and enduring exceptions; confirm final (not draft) policies; export volatile cloud evidence; build the six-year archive; confirm C3PAO evidence-hashing procedures if applicable; keep readiness and formal-assessment roles separated.

CMMC Phase 1 runs from November 10, 2025 through November 9, 2026 and centers on Level 1 and Level 2 self-assessments. Phase 2 begins November 10, 2026. Preparation time depends on scope, starting maturity, remediation work, and the date the required CMMC status must be current.

Need help choosing the right CMMC path?

Tell us your level, scope, and timeline, and we’ll match you with source-checked CMMC provider options. The CMMC Path Framework maps your required level, FCI/CUI handling, assessment type, IT environment, and timeline to a provider category— not a guaranteed provider, score, or compliance outcome.

Get matched by level, scope, and timeline →

Do not submit CUI, drawings, credentials, vulnerability scans, contract-controlled files, or sensitive system details.

CMMC patch management FAQ

Does CMMC Level 1 require patch management?

Yes. SI.L1-b.1.xii (Flaw Remediation) maps to FAR 52.204-21(b)(1)(xii) and requires FCI systems to identify, report, and correct flaws in a timely manner. Level 1 is a pass/fail self-assessment with no POA&M permitted.

Does CMMC Level 2 require patch management?

Yes. SI.L2-3.14.1 applies the flaw-remediation requirement to your CUI scope and is assessed against six objectives, alongside vulnerability scanning (RA.L2-3.11.2) and risk-based remediation (RA.L2-3.11.3).

Does CMMC require patches within 30 days?

No. There is no universal 30-day rule in SI.L2-3.14.1. Your organization defines periods that may vary by criticality and testing needs. A separate contract term, customer requirement, or applicable agency direction may impose a shorter deadline; a CISA Binding Operational Directive binds a contractor only where it’s made applicable to that contractor or system.

Are FedRAMP’s 30/90/180-day periods CMMC requirements?

No. Those come from FedRAMP’s cloud-provider vulnerability-remediation parameters, and the same 30/90/180 values also appear in DoD’s April 2025 Rev. 3 organization-defined parameters. Neither controls current CMMC Level 2, which is assessed against Rev. 2. You may use them as an internal benchmark.

How often does CMMC require vulnerability scanning?

RA.L2-3.11.2 requires scanning at an organization-defined periodic frequency and when new vulnerabilities are identified. The current Level 2 Assessment Guide caps “periodically” at no more than one year — a ceiling, not a recommended cadence. The guide’s example uses quarterly scanning.

What does “report system flaws” mean in CMMC?

It means notifying designated internal personnel with information-security responsibilities that an applicable flaw exists, within your defined period. It’s distinct from the DFARS 252.204-7012 cyber-incident report, which is required within 72 hours only when that clause applies and the event meets its criteria.

Does turning on automatic updates satisfy CMMC?

No. Automation may implement part of correction, but it does not by itself prove scope, identification, reporting, defined timeframes, failed-install handling, exceptions, or verification.

Is vulnerability scanning the same as patch management?

No. RA.L2-3.11.2 (scanning) finds vulnerabilities; SI.L2-3.14.1 governs the identify/report/correct process; RA.L2-3.11.3 ties remediation to risk. They overlap in tooling but are separate assessment objectives.

Is antivirus scanning the same as vulnerability scanning?

No. Malicious-code scanning (SI.L2-3.14.5) and vulnerability scanning (RA.L2-3.11.2) have different purposes and different assessment objectives, even when one platform does both.

Does CMMC require firmware patching?

Yes, where the firmware is applicable to the assessment scope. The Level 1 and Level 2 flaw-remediation guidance expressly covers software and firmware flaws, updates, testing, and change records — and vulnerability scanning shouldn’t overlook components like networked printers, switches, and firewalls.

Can an unpatched system still be assessed as MET?

Potentially — but not just because someone accepted the risk. The facts must support correction or mitigation, a properly documented temporary deficiency, an SSP-documented enduring exception, or the specialized-asset treatment for that system.

Can a NOT MET SI.L2-3.14.1 go on a Conditional-status POA&M?

No. It’s a 5-point requirement, and 32 CFR § 170.21 generally restricts Level 2 POA&M items to 1-point requirements (with a narrow encryption exception, plus six 1-point requirements that are expressly prohibited). It can’t be deferred to reach Conditional status.

Does patch-management software need FedRAMP?

Only in the cloud-service-handling-CUI scenario, where the offering must be FedRAMP Moderate Authorized or meet DoD’s applicable equivalency requirements. A service that handles Security Protection Data but no CUI is assessed as a Security Protection Asset and doesn’t automatically require FedRAMP just for handling SPD.

How long must patch evidence be retained?

Artifacts used as CMMC assessment evidence must be kept six years from the CMMC Status Date (§§ 170.15–170.17). Level 2 C3PAO evidence must also be hashed with a NIST-approved algorithm.

Does CMMC Level 2 use NIST SP 800-171 Revision 2 or Revision 3?

Revision 2. CMMC Level 2 assessments remain pinned to Rev. 2 via 32 CFR § 170.14; moving to Rev. 3 would require future rulemaking, even though DoD has already published Rev. 3 organization-defined parameters.

Does CMMC Level 2 require penetration testing?

Not as a universal, named requirement. Level 2 requires vulnerability scanning, risk-based remediation, and security-control assessments; you may use penetration testing as a risk activity, but the rule doesn’t mandate it across the board.

Can the company that helps us implement patching also run our C3PAO assessment?

Cyber AB CAP v2.0 requires a C3PAO to identify and manage impartiality and conflicts and to decline where a conflict can’t be sufficiently mitigated. As a conservative practice, DCR recommends keeping readiness/remediation and formal assessment with separate firms.