CVE Remediation Evidence Requirements Under CMMC 2.0

CMMC 2.0 turned vulnerability patching from a security hygiene habit into a paperwork obligation with legal teeth. The final rule took effect December 16, 2024, and the companion DFARS rule (48 CFR), published September 10, 2025, went live November 10, 2025. That second rule is the one that matters most in practice, because it writes CMMC requirements directly into contract language and ties award eligibility to a contractor's score in SPRS, the government's supplier scoring database. A company with no score on file in SPRS is a company that cannot bid, full stop.

Enforcement rolls out in four phases. Level 1 and Level 2 self-assessments are required under Phase 1. Third-party certification through an accredited assessment organization becomes mandatory under Phase 2 for any contract touching sensitive-but-unclassified controlled information at Level 2. Phase 3 brings in DIBCAC assessments for Level 3. Phase 4 was supposed to extend full implementation across all applicable DoD and DoW contracts and option periods, but it got paused on July 13, 2026, pending review by the CMMC Reform Task Force, a stall that leaves the rule's endpoint undefined. That pause changes timing, not direction. The rule's core logic hasn't moved: if a control isn't documented, tested, and demonstrable at the moment of assessment, an auditor treats it as though it doesn't exist. Claim a control is in place when it isn't, and you're not just risking a failed audit. You're inviting a False Claims Act case.

That risk stopped being theoretical in December 2025, when federal prosecutors indicted Danielle Hillmer, a former senior manager at a Virginia-based government contractor, on charges including major government fraud, wire fraud, and obstruction of a federal audit. The allegation: she misrepresented the state of security controls on contracts worth more than $250 million. Hillmer has pleaded not guilty, and the case is pending. But the indictment itself sends a signal the industry can't unhear. Overstating compliance posture on a federal contract is something federal prosecutors will now pursue as fraud.

The scale and urgency problem facing organizations right now

The math doesn't work yet, and everyone running the numbers knows it. One federal agency estimates roughly 80,000 organizations in its contractor base will need Level 2 certification. Fewer than 100 C3PAOs are currently authorized to perform those assessments, and a good number of them are booked solid through 2026. That's a bottleneck with a fixed capacity and a waitlist that keeps growing.

Separately, DoD projects that around 8,350 medium and large entities will need to complete the full third-party C3PAO assessment as a condition of contract award, rather than leaning on self-assessment. For those organizations, certification prep typically eats six to twelve months of dedicated work: gap analysis, control implementation, evidence collection, mock assessments, remediation of findings, then the actual audit itself. Anyone who hasn't started that clock is already running short on time, given that Phase 2 certification requirements are in motion regardless of where the Phase 4 pause leaves the rule's endpoint.

A recent analysis found that 62% of defense contractors lack the governance controls needed to pass certification on the first attempt. Most of the industrial base is walking into an assessment window with no documentation trail to survive it. It's the default state of the sector.

The three controls that govern CVE remediation evidence at Level 2

Level 2 requires full implementation of all 110 security controls drawn from NIST SP 800-171, spread across 14 domains covering everything from access control to system integrity. Buried inside that framework, three controls do the specific work of proving an organization found a vulnerability, decided what to do about it, and actually did it.

SI.L2-3.14.1, Flaw Remediation, requires identifying, reporting, and correcting system flaws in a timely manner. It carries a 5-point value in the CMMC scoring model and, critically, cannot be deferred to a Plan of Action and Milestones. RA.L2-3.11.2, Vulnerability Scanning, requires periodic scanning of systems and applications, plus scanning whenever new vulnerabilities are identified elsewhere. Documenting the tools used and keeping the scan output isn't spelled out word for word in the control language, but it's the evidence standard every assessor expects to see in practice. RA.L2-3.11.3, Vulnerability Remediation, requires fixing vulnerabilities according to risk assessments, not according to whatever order they happen to land on a dashboard.

Assessors don't read these three controls one at a time. They read them as a single chain: detection feeds prioritization, prioritization feeds correction. A scan log with no remediation record behind it is a red flag. A patch record with no scan behind it raises the obvious question of how the vulnerability was found. Organizations remediating flaws are also pointed toward standard references like the Common Weakness Enumeration (CWE) and the Common Vulnerabilities and Exposures (CVE) databases under SI.L2-3.14.1, which gives assessors a shared vocabulary to check claims against.

SI.L2-3.14.1 evidence requirements and no-deferral status

Most of the 110 controls carry some built-in flexibility. If a control isn't fully met, an organization can often log the gap on a POA&M, commit to a fix date, and still pass conditionally. SI.L2-3.14.1 gets none of that grace. Flaw remediation has to be real and demonstrable on the day of the assessment, not scheduled. The control requires flaw remediation to be real and demonstrable on the day of the assessment. A POA&M entry for this control records an open gap but does not excuse the unmet requirement.

What auditors actually want to see is a specific set of records: an updated vulnerability register showing which flaws closed and when, patch deployment records and patch management reports, screenshots or system logs confirming a fix actually landed, and POA&M entries for anything still open, with the understanding that the POA&M tracks residual risk rather than excusing the control itself. Where a flaw led to a real security event, incident response records showing the mitigation steps taken count too.

Findings repeat the same handful of failures over and over. Vulnerabilities get flagged and then sit unaddressed past whatever timeframe the organization claims to follow. There's no formal system tracking remediation, so patching happens whenever someone gets around to it. There's no real prioritization logic behind the scanning tool's output. Critical flaws slip through the cracks as a result. And in some cases, the patching genuinely happened, but nobody wrote any of it down, so there's nothing left for an assessor to check against. That last failure stings the most, since the organization did the actual work and still fails the control purely on paperwork.

The fix isn't complicated in concept, even if it's tedious in execution: remediation timeframes need to exist as written policy before a flaw is ever found, not after. Assessors check whether patch records show compliance with a defined standard. They are not checking whether the organization eventually got around to fixing things.

Building the vulnerability scanning evidence layer that feeds RA.L2-3.11.2

RA.L2-3.11.2 sets the scope wide. Scanning has to cover every networked device inside the CMMC assessment boundary: servers, desktops, laptops, virtual machines, containers, firewalls, switches, and yes, printers. That last category trips up more organizations than it should. A printer sitting on the same network segment as a workstation handling sensitive data sits inside the boundary whether anyone thinks of it as a "system" or not.

Scans run on a set schedule, both internal and external, with a consistent, documented interval being what assessors expect to see. What matters to an assessor isn't just that a scan happened, but that there's a record of which tool ran it and what the output showed. A scan with no saved results is functionally the same as no scan at all, from an evidence standpoint. If you skip that step, you've done the work and lost the credit for it anyway.

Organizations commonly use scanning tools that score findings with the Common Vulnerability Scoring System (CVSS), which provides a consistent severity baseline that can support the risk-based prioritization work RA.L2-3.11.3 requires next. Without a consistent scoring baseline, there's no defensible way to show that "critical" meant the same thing in January that it meant in October.

Scan configuration matters as much as scan frequency. A scan that isn't properly set up to inspect the relevant parts of a system may return results that look clean while leaving meaningful exposure undetected, a blind spot with a passing grade stapled to it.

How RA.L2-3.11.3 requires risk-based prioritization, not just CVSS sorting

RA.L2-3.11.3 asks for something a spreadsheet sort can't deliver on its own: prioritization based on an "informed" risk assessment. That word choice is deliberate. Assessors want to see how an organization weighed actual risk to CUI.

Sorting by CVSS alone gets this backwards. A high CVSS score on a system with no path to CUI can legitimately sit behind a medium-severity finding on a system that touches CUI directly, as long as the organization writes down its reasoning. If you skip the documentation, the same decision that looked like sound judgment now reads as negligence.

One defensible model ties remediation windows to risk score bands: critical findings (score of 9 or above) get fixed or mitigated within 7 days, high (7 to 8.9) within 14 days, medium (4 to 6.9) within 30 days, and low (below 4) get tracked and remediated as capacity allows. Other organizations run a looser version of the same idea: critical at 7 days, high at 30, medium at 90, low tracked through the POA&M. Neither timeline is mandated by the control language itself. What's mandated is that whichever timeline an organization picks gets written down as policy and then actually followed, scan after scan, quarter after quarter.

The configuration management and change documentation layer auditors check alongside patching records

Patch records don't stand alone in an assessment. Auditors read them against configuration management documentation: change management procedures, current system configurations, approved baseline configurations, and patch tracking logs that tie back to those baselines. A patch that changes a system's configuration with no corresponding change management record raises an obvious question: was that change authorized, and did anyone check for new risk on the way in?

Continuous monitoring plan records matter here too, and they're a different artifact from scan output. A scan result shows a single point in time. A monitoring plan shows that scanning, review, and remediation run as an ongoing operational rhythm.

The POA&M tracker deserves specific attention, because it does something no other document does: it turns an open vulnerability from a liability into a managed risk. A vulnerability sitting open with nothing tracking it looks like negligence. That same vulnerability sitting on an active POA&M, with a planned corrective action and a completion date attached, looks like a program working as designed. The tracker is what turns a finding into a footnote instead of a failure.

SBOMs and software provenance as the emerging fourth layer of CVE remediation evidence

CISA, the NSA, the FBI, and international partners released joint guidance on the 2026 Minimum Elements for a Software Bill of Materials, replacing the older NTIA 2021 framework. The update reflects how SBOM tooling has matured since 2021, along with broader feedback on how SBOM tooling has evolved since the original framework.

The most notable change is conceptual. The old framework had a category called "Known Unknowns." The 2026 version replaces it with "Explicitly Identifying Unknown Information," which draws a sharper line between information that's known internally but withheld, and information that genuinely isn't known to anyone yet. That shift pushes unknown-component identification from a one-time checkbox into an ongoing lifecycle discipline, revisited every time the software changes rather than filled in once and forgotten.

For CMMC purposes, SBOMs are becoming the mechanism that satisfies supply chain controls requiring organizations to identify, assess, and mitigate risk from third-party components and suppliers. An SBOM is a machine-readable inventory: it names components, versions, suppliers, and, increasingly, the known CVEs tied to each piece. That's exactly the data an assessor needs to confirm an organization actually knows what's running inside its own software supply chain, instead of assuming everything's fine because nothing has broken yet.

DoD's own procurement machinery is pushing in the same direction. DoD procurement expectations are moving in the same direction, turning SBOM generation from a nice-to-have into something close to a procurement requirement. Treating SBOM generation as optional today builds a gap you'll have to close under deadline pressure later, because the direction of travel here isn't in question. SBOM generation is becoming contractual, not discretionary.