Vulnerability Scanning for CMMC: What RA.L2-3.11.2 Actually Requires

The 60-second verdict

The Defense Compliance Report is an independent trade publication on CMMC 2.0 and DIB compliance — explaining the CMMC Final Rule with primary-source citation on every claim and mapping a contractor’s level, CUI scope, assessment type, and timeline to the right provider category, so DIB contractors choose the right CMMC path before they spend six figures. We are not affiliated with the Cyber AB, the Department of Defense, DCMA DIBCAC, NIST, or any U.S. government agency, and this is educational research — not legal, contractual, or compliance advice.

Is vulnerability scanning required for CMMC?

Yes. For CMMC Level 2, vulnerability scanning is required by RA.L2-3.11.2, which requires you to scan organizational systems and applications periodically and when new vulnerabilities affecting them are identified. It is the only requirement in NIST SP 800-171 Rev. 2 — and therefore in CMMC Level 2 — that directly mandates a recurring vulnerability-scanning capability. CMMC Level 1, which covers only Federal Contract Information (FCI), has no explicit scanning requirement.

Here is the quick map of how this fits together, because the acronyms pile up fast.

CMMC (Cybersecurity Maturity Model Certification) is the Department of Defense program that verifies a contractor has implemented required cybersecurity controls. It runs on two rules: the program rule at 32 CFR Part 170, effective December 16, 2024, and the acquisition rule that puts the requirement into contracts, effective November 10, 2025. CMMC Level 2 maps to the 110 security requirements in NIST SP 800-171 Rev. 2 (NIST’s standard for protecting Controlled Unclassified Information, or CUI), organized into 14 control families. Vulnerability scanning lives in the Risk Assessment family, as requirement 3.11.2 — written RA.L2-3.11.2in CMMC’s Level 2 notation. (NIST uses the identifier 3.11.2; the “RA.L2-” prefix is the CMMC labeling used in the DoD Assessment Guide.)

A note that saves you a panic later: NIST published SP 800-171 Revision 3in May 2024, and NIST’s catalog now marks Rev. 2 and its assessment guide (SP 800-171A, June 2018) as superseded for general NIST currency. That does not change your obligation. 32 CFR Part 170 currently incorporates Rev. 2 and SP 800-171A (June 2018) by reference for CMMC, so Rev. 2 is the controlling version for a CMMC assessment today. Do not build to Rev. 3 for CMMC unless and until DoD amends the rule. If a source cites Rev. 3 requirements as “what CMMC requires,” it is ahead of the regulation.

One more currency check on the control itself: the current identifier is RA.L2-3.11.2 (or NIST 3.11.2). If a page calls it “RM.2.142,” that is the 2020 CMMC 1.0 practice ID, retired when the model collapsed from five levels to three. If a source has not updated its control IDs since 2020, treat its other specifics with caution.

What the contract decides — and what it does not — matters here. The contract clause sets your required level and assessment type, not a checklist. If your contract requires CMMC Level 2, RA.L2-3.11.2 applies to you. If it requires only Level 1, scanning is not on your list (though it is still good hygiene). Confirm your applicable level and scope with a CMMC Registered Practitioner (RP/RPO) or a qualified federal-contracts attorney before you build a program around an assumption.

Primary source: NIST SP 800-171 Rev. 2, requirement 3.11.2; 32 CFR § 170.14 (CMMC Model); DoD CMMC Assessment Guide – Level 2.

What does RA.L2-3.11.2 actually require?

RA.L2-3.11.2 says: “Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified.” It is not “own a scanner.” NIST SP 800-171A — the official assessment companion — breaks the requirement into discrete determination statements: a defined scan frequency, systems scanned at that frequency, applications scanned at that frequency, systems scanned when new vulnerabilities are identified, and applications scanned when new vulnerabilities are identified. An assessor evaluates each one.

Read that again, because the structure is the whole game. The requirement names systems and applications, and it names two triggers: a recurring schedule andan event (“when new vulnerabilities affecting those systems and applications are identified”). NIST SP 800-171A turns those clauses into separate things you must prove. Miss any one of them and the requirement is scored NOT MET — there is no partial credit at the requirement level.

Here is the same requirement translated into what it means for your evidence:

Here’s the part scanner vendors won’t tell you

Buying a scanner will not make you CMMC-ready. That is genuinely annoying, because the marketing makes it sound like a purchase decision — pick a tool, run it, done. The assessment question is broader and more boring: can you prove the right assets and applications were scanned, at the cadence you defined, with current vulnerability data, and that what you found was handled according to risk? The tool is one mechanism. The operating process and its evidence are what get assessed.

The good news is that the requirement is completely achievable once you stop thinking “tool” and start thinking “process + proof.” Most of the contractors who fall short on this requirement do not fall short on technology. They fall short on a missing policy, a forgotten asset, or a scan with no dates.

Primary source: NIST SP 800-171A, Assessing Security Requirements for CUI.

Can you put vulnerability scanning on a POA&M?

No. RA.L2-3.11.2 is a 5-point requirement under the NIST SP 800-171 DoD Assessment Methodology, and 32 CFR § 170.21 limits a Conditional Level 2 POA&M to select requirements worth 1 point — with one narrow encryption exception. Anything worth more than 1 point cannot be deferred. That means a working vulnerability-scanning capability must be fully implemented, with evidence, at the time of your assessment. “We’ll stand up scanning after we pass” is a disqualifying gap, not a deferral.

This is the single most important — and most missed — fact about vulnerability scanning for CMMC, so let us walk it precisely, with the primary sources.

The DoD scores NIST SP 800-171 implementation on a scale from a maximum of 110 down to a low of −203. Every requirement carries a weight of 1, 3, or 5 points, and you subtract the weight of each requirement you have not fully met. There is no partial credit, except for two specific requirements. RA.L2-3.11.2 is one of the 5-point requirements — the same weight class as multi-factor authentication and boundary protection — because an environment you do not scan is an environment you cannot defend. (Its companion, the remediation requirement RA.L2-3.11.3, is weighted lower, at 1 point.)

Do the arithmetic and the conclusion is unavoidable: because RA.L2-3.11.2 is worth 5 points, it cannot go on a POA&M. If you have not implemented a recurring scanning process when your C3PAO (Certified Third-Party Assessment Organization) — or your own team, for a self-assessment — does the scoring, that is a finding that blocks certification, not a footnote you fix later. The rule says it plainly: a requirement not implemented, whether it is on a POA&M or not, is assessed as NOT MET. For Level 1, the point is moot in a different direction: POA&Ms are not permitted at all at Level 1.

There is one more clock worth knowing. If you do reach Conditional status on eligible (1-point) items, you have 180 days to close them out and pass a closeout assessment. Miss the window and the conditional status expires. None of that helps with scanning — because scanning never qualifies for the POA&M in the first place.

Why this matters right now: Phase 2 of the CMMC rollout begins November 10, 2026, the point at which contracting officers begin requiring Level 2 C3PAO assessments in applicable solicitations. Industry estimates commonly put Level 2 readiness at 6–12 months, depending on scope, starting maturity, evidence quality, and remediation backlog. If a Level 2 assessment is anywhere on your horizon, a non-deferrable 5-point requirement is not something to discover late.

If you just realized you have an assessment coming and scanning is not truly stood up — policy, cadence, coverage, evidence, remediation — this is the moment to get help, and the right help is a readiness or managed-compliance provider, not an assessor.

Primary sources: 32 CFR § 170.21 (POA&M); 32 CFR § 170.24 (CMMC Scoring Methodology); NIST SP 800-171 DoD Assessment Methodology.

What counts as “vulnerability scanning” for CMMC?

For CMMC, vulnerability scanning is an assessment-ready process — one that identifies vulnerabilities in your in-scope systems and applications, uses current vulnerability data, produces durable evidence, and feeds a remediation loop. A single PDF from one scan is useful evidence, but it is not the requirement. The requirement is a repeating cycle you can prove operated inside your CMMC assessment scope.

The cleanest way to see the gap between “I scanned” and “I can prove RA.L2-3.11.2” is to look at what each artifact actually demonstrates — and what it quietly fails to:

This is also where the difference between vulnerability scanning and vulnerability management matters. Scanning identifies. Management triages, remediates, accepts residual risk, verifies the fix, and reports. RA.L2-3.11.2 is the scanning half; RA.L2-3.11.3(“Remediate vulnerabilities in accordance with risk assessments”) is the remediation half. An assessor wants to see the loop close: find → rank by risk → fix or formally accept → re-scan to confirm. Tools like Tenable Nessus or Microsoft Defender will surface findings; closing them is a separate workflow you still have to own.

How often do you have to run CMMC vulnerability scans?

CMMC does not set a universal monthly or quarterly scan schedule — but it does cap the interval. 32 CFR Part 170 defines “periodically” as a regular interval determined by you (the OSA) that may not exceed one year. So you choose a risk-based cadence, document it, follow it, and add event-driven scans when new vulnerabilities affecting your systems are identified. Any page that tells you the rule mandatesmonthly or quarterly is stating a preference; any page that implies “whenever you want” is missing the one-year ceiling.

NIST’s own discussion leaves the number to you, driven by your risk assessment (RA.L2-3.11.1), and the first thing NIST SP 800-171A checks is simply that a frequency is defined.So the wrong first question is “monthly or quarterly?” The right first question is “what cadence can I justify by risk, document, and prove I followed — within the one-year cap?”

That said, you came here for a defensible answer, not a shrug. Here is our editorial recommendation — clearly labeled as editorial guidance, not a regulatory mandate — based on how the requirement is assessed and what holds up in practice:

The safest posture is the most boring one: a documented, risk-based cadence (commonly monthly for internal systems, monthly-or-tighter for external — and never longer than the one-year ceiling) plus an event trigger, written into your SSPso the “frequency is defined” objective is unambiguous. What you write in policy, you must then do — so do not commit to weekly scans you cannot sustain.

In your policy, define: frequency by asset class, who owns scans, how the scanner’s vulnerability content stays updated, what triggers an ad-hoc scan, how results are reviewed, how remediation is prioritized, and what exceptions require sign-off.

Primary source: 32 CFR § 170.4 (definition of “periodically”); NIST SP 800-171 Rev. 2 (requirement 3.11.2 discussion).

What systems and assets must be scanned?

Scan the assets inside your CMMC assessment scope. DoD guidance specifically calls out servers, desktops, laptops, virtual machines, containers, firewalls, switches, printers, and remote laptops when they are in scope — including assets, like traveling laptops, that don’t routinely sit on your network. Your scanner’s coverage should map one-to-one to your asset inventory and your defined scope.

Vulnerability scanning does not happen in a vacuum; it happens against a scope you define before assessment. 32 CFR § 170.19 requires the CMMC assessment scope to be specified up front, and at Level 2 it sorts your environment into asset categories. Your scanning obligation follows those categories:

The assets contractors forget are remarkably consistent. In order of how often they get missed: networked printers, copiers, and multifunction devices; switches and firewalls; remote and traveling laptops; virtual machines and containers; build servers and developer workstations; custom applications; and the scanner server itself. That last one surprises people — see the FedRAMP/scope section below.

For a full walkthrough of CMMC scoping — how to define your boundary, categorize assets, and document the treatment — see our scoping guide.

Primary source: 32 CFR § 170.19 (CMMC scoping); DoD CMMC Assessment Guide – Level 2.

Do applications and custom software need vulnerability scanning too?

Yes. RA.L2-3.11.2 explicitly covers “systems and applications.” For custom-developed software, DoD guidance says vulnerability analysis may require static, dynamic, binary, or hybrid analysis, source-code scanners, or even a penetration tester — because automated network scanners often aren’t thorough enough for custom code. If you build or run your own applications, endpoint scanning alone will not satisfy this requirement.

This is the coverage gap that quietly sinks software-heavy contractors. A network vulnerability scanner is excellent at finding a missing patch on a server. It is far weaker at finding an injection flaw in your own web app, a vulnerable dependency buried in a build, or an exposed API endpoint. The requirement’s wording — and the DoD’s own discussion of it — anticipates exactly that, which is why it points toward additional methods for custom software.

(DAST = Dynamic Application Security Testing; SAST = Static Application Security Testing — running code vs. reading code for flaws.)

So, is penetration testing required? Not as a universal CMMC mandate. RA.L2-3.11.2 does not name a penetration test. DoD guidance says a custom-made solution may require a penetration tester to properly validate findings — which means pen testing is a possible method for high-risk or custom systems, not a blanket requirement for every contractor.

Is penetration testing required for CMMC?

No — penetration testing is not required by NIST SP 800-171 Rev. 2 for CMMC Level 2. Vulnerability scanning (a non-intrusive check that identifies known weaknesses) is what RA.L2-3.11.2 mandates. Penetration testing simulates an attack and is a separate, optional activity. NIST mentions red-team exercises only as an additional source of vulnerabilities to feed back into scanning — not as a requirement you must satisfy.

People conflate three different things here, so here is the clean separation:

• Vulnerability scanning — automated, non-intrusive, finds known weaknesses (missing patches, misconfigurations, exposed services). This is what RA.L2-3.11.2 requires.
• Penetration testing — a human (or guided tool) actively exploits weaknesses to prove impact. Useful, sometimes appropriate for custom apps or high-risk systems, but not a CMMC Level 2 requirement.
• Continuous monitoring — ongoing observation of controls and posture. CMMC addresses this through other requirements (such as CA.L2-3.12.3), not 3.11.2.

If a vendor tells you that “CMMC requires a pen test,” ask them which requirement. There isn’t one at Level 2. Where penetration testing earns its place is for custom software, complex web applications, or as a deeper validation layer your risk assessment justifies — not as a box every DIB supplier must check.

Primary source: NIST SP 800-171 Rev. 2; DoD CMMC Assessment Guide – Level 2.

Do CMMC vulnerability scans have to be credentialed?

The rule doesn’t use the word “credentialed,” so the assessment question is whether your scan evidence satisfies the RA.L2-3.11.2 objectives — defined frequency, systems, applications, and new-vulnerability triggers — not the label itself. In practice, credentialed (authenticated) scans are the operationally safer choice where feasible, because the patch-level and configuration checks that scanning is expected to include generally require authenticated access. An uncredentialed scan of a workstation often surfaces a handful of findings where a credentialed scan of the same machine surfaces dozens.

Here’s the honest state of play, because this is a real and ongoing discussion among assessors. An uncredentialed (unauthenticated) scan pokes at a system from the outside — open ports, exposed services — and typically returns a thin list. A credentialed (authenticated) scan logs in with privileged access and inventories installed software, patch levels, and configuration from the inside, returning a far richer and more accurate picture. The practical tell that you set up a credentialed scan correctly: the report is big.

As Registered-Practitioner-adjacent analysis has framed it, citing practitioner Christopher Goodrich (CISSP), uncredentialed scans would likelybe compliant under the bare NIST text, but for CMMC the maturity expectation leans toward credentialed scanning — “since it’s essentially no harder to run a credentialed scan, it comes down to the preparedness of the organization.” That is practitioner perspective, not a regulation; we cite it as informed opinion.

Our take: run credentialed/authenticated scans on your in-scope systems where technically feasible, document where it isn’t, and you remove the argument entirely.

Does the vulnerability scanner itself need FedRAMP, GCC High, or CMMC certification?

RA.L2-3.11.2 does not say “use a FedRAMP scanner” or “use a CMMC-certified scanner” — no scanner carries a CMMC certification. But two scoping realities can pull your scanner into the assessment: a scanner that sits on your in-scope network is itself a Security Protection Asset under 32 CFR § 170.19 and must be secured; and a cloud scanner or managed service that processes, stores, or transmits CUI can trigger the cloud requirements in DFARS 252.204-7012 (FedRAMP Moderate baseline, or equivalent).

This is where a “simple tool decision” becomes an architecture decision. Two questions decide your exposure: Where does the scanner live? and What data does it touch?

Are vulnerability scan results CUI? Here is the precise answer, and the regulation is unusually clear on it. Scan output is not CUI just because the scanned system handles CUI — but it is Security Protection Data (SPD). 32 CFR § 170.4 defines SPD to include, in its own words, “data related to the configuration or vulnerability status of in-scope assets.” That’s your scan results. The practical consequence: the system that stores or processes those results is a Security Protection Assetand is in your assessment scope, even though the results aren’t CUI.

The separate FedRAMP question is triggered by CUI: per DFARS 252.204-7012, a CSP that stores, processes, or transmits CUImust meet the FedRAMP Moderate baseline or equivalent. A scanner or managed service that touches only SPD — not CUI — doesn’t trip the FedRAMP-for-CUI requirement, but it’s still assessed as part of your security-protection scope. If your scan reports happen to contain CUI or controlled technical information, document the data flow and confirm the treatment with an RP/RPO or a qualified federal-contracts attorney.

(GCC High = Microsoft’s Government Community Cloud High, a U.S.-sovereign cloud tier many DIB contractors use for CUI. FedRAMP = the federal cloud authorization program; “Moderate” is the baseline tied to CUI under DFARS 252.204-7012. See also: AWS GovCloud for CMMC.)

Primary source: 32 CFR § 170.4 (SPD definition); 32 CFR § 170.19; DFARS 252.204-7012.

Is Microsoft Defender, Nessus, Qualys, or Rapid7 “enough” for CMMC?

CMMC does not approve or reject any named scanner — there is no “CMMC-certified scanner” list for RA.L2-3.11.2. A tool is enough only if it covers your in-scope systems and applications, supports your defined frequency and event-driven scans, keeps usable historical evidence, updates its vulnerability content, and feeds a remediation workflow you can show an assessor. The brand on the box is the least important variable.

Run any candidate tool through this checklist:

So, the vendor-name FAQ, answered honestly:

• Is Defender enough for CMMC? Possibly — if it covers all in-scope systems and applications, exports usable evidence, supports your cadence and triggers, and ties into remediation. Check application and network-device coverage carefully.
• Is Nessus enough? Possibly — a correctly scoped, credentialed Nessus deployment with report history and remediation tracking can satisfy the requirement. The brand alone does not.
• Is Qualys enough?Possibly — and because it’s cloud-delivered, confirm data handling: if it touches CUI, document the FedRAMP/equivalency position; if it touches only scan results, treat it as a Security Protection Asset.
• Is Rapid7 or OpenVAS enough? Same answer: evaluate coverage, configuration, evidence, data flow, and remediation — not the logo.

The honest verdict in one line: no scanner is “CMMC-compliant”; your programis, or it isn’t.

What does vulnerability scanning for CMMC cost in 2026?

Tooling ranges from free to five figures a year; the bigger cost is almost always labor. As of June 2026, verified against vendors’ own pricing: open-source scanners (OpenVAS, nmap) are free but labor-heavy; Nessus Professional lists at $4,790/year per scanner; cloud platforms like Tenable Vulnerability Management start around $3,500/year for 100 assets; Qualys VMDR is quote-based; and managed scanning services are often billed per endpoint per month. Internal time — configuring credentialed scans, reviewing findings, closing the loop — is the line item people underestimate.

We pulled current pricing so you can budget with real numbers instead of vibes. Treat these as planning reference points; prices vary by geography, asset count, and contract term, and vendors change them.

The strategic question isn’t “which tool is cheapest.” It’s “can my team run a credentialed, fully-scoped scanning and remediation program, with assessment-grade evidence, month after month?” If yes, a self-managed scanner is the cheapest path. If no — and for a lot of small DIB suppliers the honest answer is no — a managed service that runs the whole loop usually beats buying a tool you don’t have the staff to operate.

How we verified this pricing: Tenable figures are from Tenable’s official pricing page (tenable.com/buy); Qualys is quote-based, so its number is shown only as a third-party reference; the managed-service figure is attributed to a published Registered Practitioner’s guide. Confirm any of these against a current quote for your asset count before you commit budget.

For context on what the full CMMC compliance program costs beyond scanning, see our CMMC Level 2 cost guide.

What evidence should you keep for a CMMC assessment?

Keep evidence that proves both the process and the outcome: an approved (not draft) policy and procedure, your defined frequency, SSP alignment, scanner configuration, scan targets, dated scan results across all in-scope assets, remediation tickets, risk-acceptance records, and re-scan/verification proof — and retain it all for six years from your CMMC Status Date. Assessors use three methods — Examine, Interview, and Test — and one missed determination statement makes the whole requirement NOT MET.

Below is the RA.L2-3.11.2 Evidence Matrix— a single table fusing the requirement text, the NIST SP 800-171A assessment objects, the 32 CFR scoping, POA&M, and retention rules, and the practical evidence and provider implications.

The RA.L2-3.11.2 Evidence Matrix

Your Scope & Evidence Self-Check

Before you call your scanning program “done,” run it through this self-check. If you can answer yes to every line — with an artifact behind it — you’re in strong shape for RA.L2-3.11.2:

• Scope: Have you listed every in-scope asset (including printers, switches, remote laptops, VMs, containers, and the scanner itself) and confirmed your scanner reaches all of them?
• Applications: If you run custom or web applications, are they covered by an appropriate method (SAST/DAST, dependency, or source-code scanning) — not just host scanning?
• Cadence: Is your scan frequency defined in an approved policy, set within the one-year cap, and actually being followed on a dated schedule?
• Trigger: Do you have a documented process to scan when a new vulnerability affecting your systems is disclosed?
• Depth:Are your scans credentialed/authenticated where feasible, with documented exceptions where they aren’t?
• Remediation: Can you show the loop closing — finding, risk ranking, fix or accepted risk, and a re-scan that confirms it?
• Evidence quality: Are your policy and procedure final and approved, not drafts?
• Retention:Is your scan evidence archived to survive six years from your CMMC Status Date (hashed, if you’re on the C3PAO path)?
• Data handling: If a cloud scanner or managed service touches your data, have you documented the ESP/CSP treatment — and the FedRAMP position if any CUI is involved?

Any “no” on that list is a gap worth closing before an assessor finds it.

One callout worth a sticky note: 32 CFR § 170.24 says assessment evidence must be final, not draft — an unofficial or unapproved policy is not acceptable evidence, and a single unmet objective makes the requirement NOT MET. Approve your documents before the assessment.

Primary source: DoD CMMC Assessment Guide – Level 2; 32 CFR § 170.24; 32 CFR § 170.17 (six-year artifact retention).

How does scanning connect to remediation, POA&M, and your SPRS score?

Scanning finds vulnerabilities; RA.L2-3.11.3 requires you to remediate them according to risk; CA.L2-3.12.2 requires a plan to correct deficiencies. RA.L2-3.11.2 is a 5-point requirement, so it cannot sit on a POA&M. Your results post to SPRS (the Supplier Performance Risk System) — directly for a Level 2 self-assessment, or via eMASS for a C3PAO assessment — and DFARS 252.204-7021 requires you to hold and affirm the required CMMC status where the clause applies.

Three requirements form the loop, and an assessor wants to see all three working together:

• RA.L2-3.11.2 — find vulnerabilities (5 points).
• RA.L2-3.11.3 — remediate them according to risk (1 point).
• CA.L2-3.12.2 — maintain plans of action to correct deficiencies (3 points).

The scoring picture, side by side:

That contrast is the practical lesson: the 5-point scanning capability can never be deferred, while the 1-point remediationcontrol may be POA&M-eligible only under the right conditions. In reality you want both met — scanning that finds problems you never fix is a finding waiting to happen.

On the back end: a Level 2 self-assessment posts its score to SPRS, the DoD system contracting officers check; a Level 2 C3PAO assessment records results in eMASS, which transmits to SPRS. Where DFARS 252.204-7021 (the CMMC clause) applies, you must hold the required CMMC status at award and affirm it. (SPRS = Supplier Performance Risk System; eMASS = the DoD’s Enterprise Mission Assurance Support Service; DIBCAC = the Defense Industrial Base Cybersecurity Assessment Center, which conducts Level 3 assessments.)

Primary sources: DFARS 252.204-7021; 32 CFR § 170.21; SPRS.

What provider category should handle vulnerability scanning for CMMC?

Most contractors should not start with a C3PAO for scanning. If your problem is tooling, coverage, remediation, evidence, or day-to-day operations, the right category is usually internal IT, an MSSP/MSP, an RPO/RP for readiness validation, a GRC platform for tracking, or a CUI enclave provider— with the C3PAO reserved for formal assessment when you’re ready. The Cyber AB is explicit that CMMC must be implemented before it’s assessed, and that an individual who helped you implement cannot also assess that same work.

Match your situation to the category, not the brand:

The conflict-of-interest line is not optional.A C3PAO’s job is assessment. Readiness and remediation must stay appropriately separated from the formal assessment of the same organization and engagement, per Cyber AB ecosystem rules. If a provider offers both readiness and assessment, ask them directly how they separate the roles and avoid the conflict — and if you want the cleanest path, keep the firm that fixes your environment separate from the firm that grades it.

Primary source: Cyber AB — Consulting and Implementation roles.

What does a practical CMMC vulnerability scanning program look like?

A practical program is a repeatable operating cycle, not a one-time event: confirm scope, map assets and applications, define frequency and triggers, configure the scanner and update its content, scan systems and applications, triage by risk, then remediate or formally accept, verify the fix, and preserve final evidence. The goal isn’t a report — it’s a process you can prove operated inside your CMMC assessment scope.

The seven-step cycle:

1. Confirm your CMMC assessment scope (per § 170.19).
2. Map assets and applications to that scope.
3. Define scan frequency and event triggers in policy (within the one-year cap).
4. Configure the scanner and keep its vulnerability content current.
5. Run system and application scans — credentialed where feasible.
6. Triage findings by risk: CVSS severity, exploitability (e.g., CISA KEV), business impact, and CUI impact.
7. Remediate, risk-accept, re-scan, and preserve evidence.

(CVSS = Common Vulnerability Scoring System, a 0–10 severity score; CISA KEV = the federal Known Exploited Vulnerabilities catalog. Use CVSS plus real-world exploitability and your own CUI/asset context — severity alone is not risk.)

A realistic first 90 days, if you’re starting cold:

What are the common mistakes that fail RA.L2-3.11.2?

The failures are rarely exotic. They’re scope and evidence failures: scanning some endpoints but unable to prove a defined frequency, full in-scope coverage, application scanning, current vulnerability data, remediation, or SSP alignment. Fix the boring stuff and you stop giving RA.L2-3.11.2 easy reasons to fail.

What changed with the CMMC Final Rule and the rollout timeline?

CMMC is no longer a future-planning topic. The program rule (32 CFR Part 170) took effect December 16, 2024, and the acquisition rule putting CMMC into contracts took effect November 10, 2025. Phase 1 (Nov 10, 2025 – Nov 9, 2026) focuses on Level 1 and Level 2 self-assessments; Phase 2 begins November 10, 2026, adding Level 2 C3PAO certification where applicable. If a contract requires Level 2, your RA.L2-3.11.2 evidence is live.

Why this lands on the scanning conversation specifically: when a contract requires Level 2 (Self) or Level 2 (C3PAO), RA.L2-3.11.2 is in play, DFARS 252.204-7021 ties your eligibility to holding the required status, and — to repeat the one fact worth repeating — scanning is a 5-point, non-deferrablerequirement. The contractors who treat it as a late, small item are the ones who discover, with an assessment booked, that it cannot be POA&M’d.

For a full breakdown of what each phase means for your contracts and timelines, see our CMMC deadlines guide.

Primary source: DoD CIO — CMMC.

What we actually verified for this guide

We verified the core regulatory and assessment claims against primary sources — and we’ll tell you exactly what we checked and what we didn’t, because on a Your-Money-or-Your-Life topic like federal compliance, “trust us” isn’t good enough. (See our Editorial Standards, Corrections Policy, and the CMMC Path Framework methodology for how we source and update every page.)

What we verified (June 2026):

• RA.L2-3.11.2 and RA.L2-3.11.3 requirement text and family placement — NIST SP 800-171 Rev. 2.
• The 5-point value of RA.L2-3.11.2 — the NIST SP 800-171 DoD Assessment Methodology.
• The definition of “periodically” (≤ one year) and Security Protection Data (which includes vulnerability-status data) — 32 CFR § 170.4.
• POA&M limits (select 1-point requirements only), the 88/110 (80%) threshold, and the 180-day closeout — 32 CFR § 170.21 and the CMMC Scoring Methodology, 32 CFR § 170.24.
• Six-year artifact retention (with hashing on the certification path) — 32 CFR § 170.16 and § 170.17.
• Scope categories and ESP/CSP treatment — 32 CFR § 170.19 and DFARS 252.204-7012.
• That Rev. 2 (not Rev. 3) controls CMMC today — 32 CFR § 170.14.
• Coverage of systems/applications, remote laptops, and custom software — DoD CMMC Assessment Guide – Level 2.
• The implementation-before-assessment and role-separation rules — Cyber AB.
• Phase dates — DoD CIO CMMC.
• Current scanner pricing — Tenable’s official pricing page (tenable.com/buy); Qualys shown as quote-based with a third-party reference; managed-service pricing attributed to a published Registered Practitioner’s guide.

What we did not do: we did not rank or endorse any scanner vendor, we did not treat forum posts as regulatory evidence (we used practitioner discussion only as informed opinion, clearly labeled), and we did not assert that a specific scan report is CUI — scan results are Security Protection Data, and any CUI inside them depends on content you should confirm with an RP/RPO or counsel.

Frequently asked questions about vulnerability scanning for CMMC

Does CMMC require vulnerability scanning?

Yes, at CMMC Level 2. RA.L2-3.11.2 requires scanning organizational systems and applications periodically and when new vulnerabilities affecting them are identified. Level 1 (FCI only) has no explicit scanning requirement.

What CMMC requirement covers vulnerability scanning?

RA.L2-3.11.2, the CMMC Level 2 label for NIST SP 800-171 Rev. 2 requirement 3.11.2, in the Risk Assessment family. Remediation of findings is covered by RA.L2-3.11.3.

Does CMMC require a specific scanner?

No. No scanner carries a CMMC certification. A tool is sufficient only if it covers your in-scope systems and applications, supports your defined cadence and event triggers, preserves evidence, and feeds remediation.

How often do I have to scan for CMMC?

A frequency you define and document, not to exceed one year (32 CFR § 170.4 caps “periodically” at one year), plus a scan when a new vulnerability affecting your systems is identified. Quarterly appears as an example in DoD guidance, not a universal mandate; a defensible default is monthly for internal systems, monthly-or-tighter for external, plus event-driven scans.

Can I put a vulnerability-scanning gap on a POA&M?

No. RA.L2-3.11.2 is a 5-point requirement, and under 32 CFR § 170.21 a Conditional Level 2 POA&M is limited to select 1-point requirements (with one narrow encryption exception). A working scanning capability must be fully met at assessment.

Do CMMC scans have to be credentialed?

The rule doesn’t use the word “credentialed,” so the test is whether your scan evidence satisfies the RA.L2-3.11.2 objectives. Credentialed (authenticated) scans are the operationally safer choice where feasible, because patch-level and configuration checks generally require authenticated access; document any system where credentialed scanning isn’t feasible.

Is penetration testing required for CMMC?

No. NIST SP 800-171 Rev. 2 requires vulnerability scanning, not penetration testing. Pen testing is a separate, optional activity that may suit custom software or high-risk systems.

Is Microsoft Defender (or Nessus, or Qualys) enough for CMMC?

Possibly — none is automatically enough or not enough. Evaluate coverage of all in-scope systems and applications, evidence/reporting, content updates, credentialed-scan support, data handling, and remediation integration.

Does my scanner need to be FedRAMP-authorized?

Only if it stores, processes, or transmits CUI — DFARS 252.204-7012 ties the FedRAMP Moderate baseline (or equivalent) to CUI handling by a cloud service. A scanner that handles only scan results is dealing with Security Protection Data, not CUI; it’s still assessed as a Security Protection Asset, but that’s a different question from the FedRAMP-for-CUI requirement. A local scanner on your in-scope network is itself a Security Protection Asset and must be secured.

Do vulnerability scan results count as CUI?

Not automatically. 32 CFR § 170.4 defines scan results — “data related to the configuration or vulnerability status of in-scope assets” — as Security Protection Data, which keeps the system handling them in your assessment scope. If a report happens to contain CUI or controlled technical information, document the data flow and confirm the classification with an RP/RPO or a qualified federal-contracts attorney.

How long do I have to keep my scan evidence?

Six years from your CMMC Status Date, per 32 CFR §§ 170.16 and 170.17. On the C3PAO certification path, the artifacts used as evidence must also be hashed with a NIST-approved algorithm.

Can I scan myself, or do I need a third party?

You can run your own scans — there’s no requirement for a third-party scanner. The formal assessment is the separate third-party step (a C3PAO for Level 2 certification), and it should stay separate from whoever helps you implement.

Who should help with scanning before a C3PAO assessment?

Usually internal IT or an MSSP/MSP for operations, an RPO/RP to validate readiness and evidence, a GRC platform to track findings, or a CUI enclave provider. A C3PAO is for formal assessment when you’re ready — not for fixing the gaps it will later grade.

Need help deciding what type of CMMC provider you need?Tell us your level, scope, and timeline, and we’ll match you with source-checked CMMC provider options. → Find My CMMC Path

Do not submit CUI, drawings, network diagrams with sensitive details, export-controlled technical data, or sensitive contract information through this form.