Vulnerability Scanning for CMMC: Authenticated Scans, Exceptions, and Remediation Evidence
The Scan Is Not the Control. The Remediation Is.
CMMC Level 2 requires vulnerability scanning of in-scope systems — but the controls demand far more than running a monthly Nessus report. Authenticated scans, documented exceptions, defined patch timelines, and remediation evidence are what assessors actually evaluate. The scan is the starting point. Everything that happens after it is what gets scored.
Why Vulnerability Scanning Is Often Misunderstood
Most contractors treat vulnerability scanning as a checkbox. They run a scan once a month, export the PDF, file it in a folder, and move on. When the assessor asks about their vulnerability management program, they produce the PDF and say "we scan monthly." The assessor then asks three questions that the PDF cannot answer:
The confusion stems from reading the controls too narrowly. NIST SP 800-171 control RA.L2-3.11.2 requires organizations to scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems are identified. But that control does not exist in isolation. It is part of a chain:
Scan
Identify vulnerabilities in all in-scope systems periodically and when new threats emerge
Remediate
Remediate vulnerabilities in accordance with risk assessments
Flaw Remediation
Identify, report, and correct system flaws in a timely manner
Internal Versus External Scans
NIST SP 800-171 does not explicitly differentiate between internal and external vulnerability scans — the requirement is to scan organizational systems. But in practice, an assessor expects to see both perspectives covered, because the threat landscape differs depending on vantage point.
From Inside the Network Boundary
The scanner sits on the same network as the target systems — behind the firewall, inside the VPN, within the enclave. It sees the same attack surface that an insider or a compromised endpoint would see. Internal scans reveal missing patches on workstations, misconfigured services, weak protocols, open management ports, and unpatched third-party software. This is the primary scan type for CMMC — because most CUI-handling systems are not directly internet-facing.
From Outside the Network Boundary
The scanner runs from the internet against your public-facing IP addresses and services — web servers, mail servers, VPN gateways, cloud endpoints. It sees what an external attacker would see. External scans reveal exposed services, SSL/TLS misconfigurations, outdated web server versions, and open ports that should not be accessible from the internet. If you have any internet-facing services in the assessment boundary, external scans are expected.
For organizations where all CUI processing happens in a cloud environment like GCC High — with no on-premises servers and no internet-facing infrastructure they manage — external scanning of self-managed assets may not apply. But the assessor will still expect evidence that the cloud platform's vulnerabilities are tracked, typically through Microsoft Secure Score, Defender for Cloud, or equivalent tooling that monitors the cloud posture.
Authenticated Scanning and Why It Matters
This is the single most important technical distinction in CMMC vulnerability scanning — and the one most contractors get wrong.
An unauthenticated scan (also called a network scan or remote scan) probes a target system from the outside — checking open ports, banner-grabbing services, and testing for known remote vulnerabilities. It sees what an attacker would see across the network. It is useful, but incomplete. An unauthenticated scan cannot see locally installed software, missing operating system patches, weak local configurations, or application-level vulnerabilities — because it does not have credentials to log into the system.
An authenticated scan (also called a credentialed scan) logs into the target system using provided credentials — typically a local admin or domain admin account — and inspects the system from the inside. It reads the installed software inventory, checks patch levels, examines registry settings, reviews service configurations, and identifies vulnerabilities that are invisible from the network. The difference in coverage is not marginal. It is often an order of magnitude.
Authenticated scanning requires planning. The scan credential must have local administrator access on every target. In environments using Intune-managed endpoints without a traditional domain, this means deploying a local admin account through Intune or using a service like Microsoft Defender Vulnerability Management, which uses the endpoint agent to report vulnerability data without requiring a separate scan credential. For firewalls, switches, and network appliances, SNMP or SSH credentials may be required. Each device type has its own authentication model — and each must be configured in the scanning tool.
Handling Appliances, Servers, Workstations, and Cloud Workloads
Not every in-scope asset can be scanned the same way. The scanning strategy must account for the different capabilities and limitations of each asset type in the environment.
Windows Servers and Workstations
The easiest to scan with credentials. Use a domain-joined service account or a local admin account. Enable WMI and remote registry access on targets. Scan tools like Tenable Nessus, Qualys, or Rapid7 InsightVM support Windows credentialed scanning natively. Alternatively, Microsoft Defender Vulnerability Management uses the installed Defender for Endpoint agent to report vulnerability data continuously — no separate scan required. Either approach satisfies the control.
Linux and macOS Systems
Authenticated scanning requires SSH access with a privileged account (root or sudo-capable). Ensure the SSH service is running and the scan account has the necessary permissions. For macOS endpoints managed through Intune, agent-based vulnerability reporting through Defender for Endpoint is often more practical than network-based credentialed scanning.
Network Appliances (Firewalls, Switches, APs)
Firewalls and managed switches often support SNMP-based scanning or SSH-based credentialed access. The scanner checks firmware version against known CVE databases. For appliances that do not support agent-based or credential-based scanning, document the limitation and use the vendor's security advisory feed to track vulnerabilities manually. The key is that the appliance appears in the scan scope — even if the scan method differs from standard hosts.
Cloud Workloads (Azure VMs, Containers)
For Azure Government VMs, use Microsoft Defender for Cloud to assess vulnerability posture continuously. For containers, scan images in the registry before deployment and monitor running containers with Defender for Containers. The scanning model shifts from periodic network scans to continuous agent-based assessment — but the evidence requirements are the same: identified vulnerabilities, severity ratings, remediation timelines, and closure proof.
SaaS and Managed Services
You cannot scan GCC High, Exchange Online, or SharePoint Online with a traditional vulnerability scanner — Microsoft manages the infrastructure. Your responsibility is to track the configuration posture using Microsoft Secure Score, Defender for Cloud Apps, and Compliance Manager. For third-party SaaS in scope, verify the vendor's vulnerability management practices through their FedRAMP authorization, SOC 2 report, or shared responsibility documentation.
False Positives, Risk Acceptance, and Exception Handling
No scan report is perfect. Every environment produces false positives — findings that the scanner reports as vulnerabilities but that are not actually exploitable in context, or that apply to a component that is not in the configuration the scanner assumes. The question is not whether you have false positives. The question is whether you have a documented process for handling them.
NIST SP 800-171 control RA.L2-3.11.3 requires remediating vulnerabilities "in accordance with risk assessments." That phrase is critical — it means not every finding requires an immediate patch. Some findings are false positives that should be dismissed. Some are real vulnerabilities where the risk is accepted because the compensating control makes exploitation impractical. Some are deferred because the patch requires a maintenance window. Each of these outcomes is valid — but only if it is documented.
Patch SLAs and Remediation Proof
NIST SP 800-171 control SI.L2-3.14.1 requires identifying, reporting, and correcting system flaws in a timely manner. "Timely" is not defined by the standard — it is an organization-defined value. The contractor sets the remediation timelines in their own policy, and the assessor evaluates whether those timelines are being met.
The industry-standard approach is to define remediation SLAs by severity:
| Severity | CVSS Score Range | Typical Remediation SLA |
|---|---|---|
| Critical | 9.0 – 10.0 | 15 days or less |
| High | 7.0 – 8.9 | 30 days |
| Medium | 4.0 – 6.9 | 60 days |
| Low | 0.1 – 3.9 | 90 days or next maintenance window |
These numbers are not mandated by CMMC. They are the contractor's own policy. But once you define them, you are held to them. If your policy says critical vulnerabilities are patched within 15 days and the assessor finds a critical CVE that was open for 60 days with no documented exception, the control is Not Met — not because of the vulnerability, but because of the SLA violation.
Remediation proof is the rescan. After a vulnerability is patched, the system must be rescanned to confirm the finding is cleared. A patch ticket that says "applied KB5034441" is not remediation proof — it is remediation intent. The rescan showing the CVE no longer appears is the proof. If your scanning cadence is monthly, this means a finding remediated on day five may not be confirmed cleared until day thirty. Some organizations run targeted rescans after patch cycles specifically to close this evidence gap.
What Evidence Assessors Expect to See
The vulnerability management evidence package is one of the most heavily scrutinized artifacts in a CMMC assessment. Assessors are looking for a complete lifecycle: scan configuration, scan execution, finding triage, remediation action, and verification. Here is the full set:
The Bottom Line
Vulnerability scanning for CMMC is not a checkbox. It is a lifecycle: scan, triage, remediate, verify, document. The scan identifies the problem. The triage assigns a disposition. The remediation fixes or accepts it. The rescan proves it. The documentation ties it all together for the assessor.
Authenticated scans are the expectation — unauthenticated scans miss too much to satisfy the intent of the control. Every in-scope asset must appear in scan coverage. Every finding must have a disposition. Every remediation must be verified. And every exception must be justified, approved, and time-bounded.
The assessor does not care how many vulnerabilities your scan finds. They care that you know about them, that you have a process for dealing with them, and that you can prove the process works. A clean scan report with zero findings is not more impressive than a report with findings — if every finding is triaged, tracked, and resolved within your stated SLAs. The program is the control. The scan is just the input.