Malware Protection for Defense Contractors: The CMMC Requirements

Word count: ~2,790

Specificity markers used:

1. NIST/CMMC control references: SI.L2-3.14.2, SI.L2-3.14.4, SI.L2-3.14.5, SI.L2-3.14.6, SI.L2-3.14.7, CA.L3-3.14.1e
2. Cost/time estimates: EDR ~$50–$100/endpoint/year; MDR $2,000–$5,000/month for small contractors
3. Tool/product names: CrowdStrike Falcon, Microsoft Defender for Endpoint, SentinelOne, Malwarebytes for Teams
4. Common mistake: Running Windows Defender without FIPS mode and without centralized management — it exists but doesn't satisfy the controls
5. Decision point: Traditional AV vs. EDR vs. MDR — with guidance based on org size and IT staffing

---

Executive Summary

Key takeaways: - CMMC Level 2 has three direct malware protection requirements under the SI domain: implement anti-malware (SI.L2-3.14.2), update signatures and mechanisms (SI.L2-3.14.4), and scan removable media (SI.L2-3.14.5) - Traditional antivirus satisfies the letter of the requirement. EDR satisfies it better and covers more of the SI domain's monitoring controls - Windows Defender is acceptable — but only if it's centrally managed, properly configured, and you can demonstrate it to an assessor - At CMMC Level 3, the bar rises significantly: you need behavior-based detection and coverage for fileless attacks (CA.L3-3.14.1e) - The decision between EDR and MDR comes down to one question: do you have staff to respond to alerts at 2 a.m.?

---

Malware protection is one of the easier CMMC requirements to satisfy on paper and one of the easier ones to get wrong in practice. The controls aren't technically complex — install anti-malware, keep it updated, scan removable media. The failure modes are operational: unmanaged endpoints, stale signatures, no centralized visibility, and nobody looking at the alerts.

This article covers what the CMMC requirements actually say, how they map to real products, and what your assessor will look for when they show up.

The Three SI Domain Controls That Matter

CMMC Level 2 has seven requirements in the System and Information Integrity (SI) domain. Three of them are specifically about malware:

SI.L2-3.14.2 — Provide protection from malicious code at appropriate locations within organizational information systems.

This is the core requirement. Every system that processes, stores, or transmits CUI needs malware protection. "Appropriate locations" means endpoints, servers, and email gateways at minimum. If CUI flows through it, it needs coverage.

The requirement also specifies what that protection must do: - Detect malicious code - Block malicious code when detected - Quarantine detected code for further analysis - Send alerts when malicious code is detected

That last bullet is where traditional AV often falls short. It may detect and quarantine, but if nobody is monitoring the alerts, you've satisfied the technical control without the operational control. Assessors will ask how alerts are reviewed and by whom.

SI.L2-3.14.4 — Update malicious code protection mechanisms when new releases are available.

Signature-based protection is only as good as its most recent update. This requirement mandates that you have automatic signature updates enabled. The common failure: endpoints that go offline for extended periods (laptops used by remote workers, test systems, air-gapped systems) that aren't getting updates pushed.

Document your update policy. Define what "timely" means for your environment — most organizations specify signature updates within 24 hours of release. Your assessor will check the update history on several systems, not just the one you pointed them to.

SI.L2-3.14.5 — Perform periodic scans of organizational information systems and real-time scans of files from external sources as files are downloaded, opened, or executed.

Two distinct requirements rolled into one:

1. Scheduled scans — full system scans on a defined schedule (weekly at minimum for CUI systems)
2. Real-time scanning — every file from an external source scanned on access

The removable media piece falls here. Any USB drive, external hard drive, or optical media inserted into a CUI system should trigger an automatic scan before any files execute. Policies banning removable media entirely (and enforcing that ban technically) also satisfy this requirement.

The Other SI Controls Malware Affects

The three controls above are the direct malware requirements. Four others in the SI domain are closely related and are often evaluated alongside them:

SI.L2-3.14.1 — Identify, report, and correct information system flaws in a timely manner; provide protection from malicious code at appropriate locations.

This is your patch management requirement. Unpatched systems are the primary delivery mechanism for malware in enterprise environments. Your malware protection controls work better when the underlying systems are hardened. Assessors who review SI.L2-3.14.2 will frequently pivot to asking about your patch process.

SI.L2-3.14.6 — Monitor organizational information systems, including inbound and outbound communications traffic, to detect attacks and indicators of potential attacks.

SI.L2-3.14.7 — Identify unauthorized use of organizational information systems.

These two controls go beyond signature-based detection. They require you to have visibility into what's happening on your network — not just whether a known piece of malware is present. EDR solutions address these controls directly by providing behavioral telemetry, network connection monitoring, and anomaly detection.

Traditional AV vs. EDR: The Decision That Matters

The question most contractors ask is: "Do I need EDR, or can I use standard antivirus?"

The honest answer: traditional AV can satisfy SI.L2-3.14.2, SI.L2-3.14.4, and SI.L2-3.14.5. It doesn't address SI.L2-3.14.6 or SI.L2-3.14.7 nearly as well. If you're using traditional AV, you'll need other controls to demonstrate coverage for those monitoring requirements — typically a SIEM with network log correlation.

EDR (Endpoint Detection and Response) consolidates multiple SI domain controls into a single platform: - Signature-based detection (covers 3.14.2) - Automatic updates (covers 3.14.4) - Real-time and scheduled scanning (covers 3.14.5) - Behavioral monitoring and anomaly detection (covers 3.14.6 and 3.14.7) - Centralized alert management with evidence retention (helps your assessor)

The three EDR platforms that come up most in CMMC-focused environments:

CrowdStrike Falcon — The market leader in the defense contractor space. Falcon Go starts around $60/endpoint/year; Falcon Pro around $100/endpoint/year. Strong detection capability, lightweight agent, cloud-based management. The limitation for highly sensitive environments: the management console is cloud-hosted, which matters for network segmentation discussions.

Microsoft Defender for Endpoint (Plan 2) — Included with Microsoft 365 E5 or Microsoft 365 Business Premium. If you're already in the Microsoft ecosystem (especially GCC High for CUI), this is worth examining before paying separately for a third-party EDR. The catch: it works well when properly configured, but the default configuration isn't sufficient. You need to enable all the advanced detection features, configure automated investigation settings, and integrate with Microsoft Sentinel for the SIEM function.

SentinelOne Singularity — Strong behavioral detection, on-premises management option (relevant for air-gapped or restricted environments), and a good story for offline endpoints. Pricing is competitive with CrowdStrike at roughly $50–$90/endpoint/year depending on tier.

For organizations with 50 or fewer endpoints and a lean IT team, Malwarebytes for Teams (around $40/endpoint/year) is a lower-cost option that satisfies the basic malware protection controls. It doesn't have the behavioral detection depth of the enterprise platforms, so you'll need to supplement with network monitoring to address SI.L2-3.14.6.

The EDR vs. MDR question — EDR gives you tools and telemetry. Managed Detection and Response (MDR) adds a 24/7 security operations team that monitors those tools and responds to alerts. MDR costs $2,000–$5,000/month for small defense contractors (50–200 employees). It's worth serious consideration if you don't have a dedicated security analyst on staff — because EDR alerts you don't act on provide no protection. Most small defense contractors that buy enterprise EDR don't have the staff to use it properly.

Decision guidance: - Under 50 employees, no dedicated security staff: Look at MDR with an included EDR component (many MDR providers bundle it) - 50–200 employees, part-time IT staff: EDR (CrowdStrike, Defender for Endpoint, or SentinelOne) plus documented alert response procedures; consider MDR during assessment crunch - 200+ employees with a security team: EDR plus SIEM; evaluate whether MDR augments or replaces internal monitoring

Removable Media: The Overlooked Scan Requirement

SI.L2-3.14.5 has two parts that often get treated as one: periodic system scans and real-time scans of files from external sources. The removable media component of the second part is where a lot of organizations are noncompliant without knowing it.

"Real-time scans of files from external sources as files are downloaded, opened, or executed" — the "external sources" phrase explicitly includes removable media. Every USB drive inserted into a CUI system should trigger an automatic scan before any files execute. The question your assessor will ask: is that automatic and enforced, or is it dependent on a user remembering to right-click and scan?

There are two defensible approaches:

Technical enforcement via Group Policy or Endpoint Manager — configure Windows to run an automatic scan whenever removable storage is connected. Microsoft Defender's Group Policy settings include "Scan removable drives during a full scan" (this scans during scheduled scans) and "Configure monitoring for incoming and outgoing file activity" (this enables real-time scanning of files accessed from removable media). In Intune, Device Restriction profiles let you both block removable storage entirely and configure scan behavior.

Complete technical block on removable media — disable USB storage ports via Group Policy, Intune, or endpoint management entirely. If users can't connect removable drives to CUI systems, there's nothing to scan. This is a stronger control than scanning (you've eliminated the attack vector rather than detecting it after connection) and is increasingly common in defense contractor environments. The trade-off is operational friction — engineers who need to move large files will need an alternative path.

If you choose the blocking approach, document it clearly in your SSP against SI.L2-3.14.5. Your assessor needs to see how you satisfy the "scan files from external sources" requirement — and "we've blocked external sources entirely" is a valid answer, but it needs to be technically enforced and documented.

The Windows Defender Problem

The most common mistake in this domain: running Windows Defender and assuming it satisfies the requirements without doing the configuration work.

Windows Defender is a legitimate malware protection solution. Microsoft Defender for Endpoint (the enterprise version) is a legitimate EDR. But bare Windows Defender running on a standalone workstation in its default configuration fails several assessment criteria:

1. No centralized management — you can't demonstrate to an assessor that all endpoints are covered, all signatures are current, and all alerts are being monitored without centralized management. Defender needs to be enrolled in Microsoft Endpoint Manager (Intune) or managed through Group Policy at minimum
2. No alert visibility — default Defender alerts only appear on the local machine. Without a management console pulling alerts centrally, you can't satisfy the "alerts generated" component of SI.L2-3.14.2
3. No scan history — assessors will ask for evidence of scheduled scans and removable media scans. Without centralized logging, you're pulling this from each machine manually

If you're going to use Windows Defender, run it through Microsoft Defender for Endpoint Plan 1 or Plan 2, enrolled in Intune, with alerts feeding into Microsoft Sentinel or a similar SIEM. At that point, you have a legitimate solution. The bare-bones version is not it.

CMMC Level 3: The Bar Rises

If you handle CUI for priority DoD programs and you're pursuing CMMC Level 3, the malware requirements become more demanding. Level 3 pulls from NIST SP 800-172, which adds enhanced requirements on top of the 800-171 baseline.

The key addition for malware protection:

CA.L3-3.14.1e — Employ threat-hunting activities using automated tools and manual techniques to search for indicators of compromise in organizational systems.

This goes beyond detection. It requires proactive hunting — looking for evidence of compromise that automated detections may have missed. Threat hunting assumes that sophisticated attackers may already be in your environment without triggering signatures or behavioral alerts. It requires analysts who know how to look for lateral movement, persistence mechanisms, and data staging activity.

For Level 3, you're not just running EDR — you need threat intelligence feeds, behavioral baselines, and analysts who can run hunts against your endpoint telemetry. That's either an internal security team or a dedicated MDR provider with explicit threat hunting capabilities.

The other Level 3 additions relevant to malware include enhanced monitoring requirements and coverage for non-traditional endpoints (OT systems, IoT, specialized equipment). If those systems are in scope for your Level 3 assessment, your protection coverage needs to extend to them.

Cloud Environments and Container Workloads

Cloud-hosted CUI environments add complexity to malware protection coverage. Traditional endpoint agents work fine on virtual machines in Azure Government, AWS GovCloud, or Google Cloud, but container-based workloads require a different approach.

For containerized workloads running on Kubernetes or managed container services (Azure Kubernetes Service, AWS ECS):

• Container image scanning — scan images for known vulnerabilities and embedded malware before they're deployed. Tools like Aqua Security, Palo Alto Prisma Cloud, or the native scanning in Azure Container Registry handle this. The principle mirrors SI.L2-3.14.5's file scanning requirement applied to the container build pipeline.
• Runtime security — behavioral monitoring at the container runtime level detects anomalous process execution, unexpected network connections, and file system modifications inside containers. This is where SI.L2-3.14.6 and 3.14.7 apply to containerized environments.
• Node-level protection — the underlying virtual machines running your container hosts still need traditional endpoint protection. Don't let container orchestration create an assumption that OS-level protection is someone else's responsibility.

If you're using a FedRAMP-authorized cloud platform, review the cloud provider's shared responsibility matrix carefully. The provider's FedRAMP authorization covers the infrastructure layer controls; your endpoint protection on virtual machines you manage remains your responsibility. "The cloud is FedRAMP" is not a sufficient answer to SI.L2-3.14.2 coverage of your workloads.

Cross-Framework References

If your organization uses ISO 27001 or NIST CSF alongside CMMC, the malware protection controls map cleanly:

• ISO 27001 A.8.7 (Protection against malware) — direct equivalent to SI.L2-3.14.2. ISO requires malware detection and prevention controls plus user awareness. The CMMC requirement adds the technical specifics (quarantine, alerting, signature currency)
• NIST CSF PR.DS-6 / DE.CM-4 — the Protect and Detect functions cover malware protection in the CSF. If you've implemented CSF controls, you've likely addressed the CMMC malware requirements with some documentation gaps
• FedRAMP SI-3 — essentially the same requirement as SI.L2-3.14.2, structured for cloud service providers. If you're using a FedRAMP-authorized cloud environment for CUI, verify that the cloud provider's SI-3 implementation extends to your workloads, or that you have an additional layer at the endpoint

These mappings matter if you're managing multiple compliance programs. One endpoint protection implementation can satisfy requirements across all three frameworks — but each framework wants different documentation.

What Your Assessor Expects

For the SI domain malware controls, your assessor will use all three assessment methods from NIST 800-171A: examine, interview, and test.

Examine — Your assessor will review: - System Security Plan (SSP) description of your malware protection implementation, including product name, version, and deployment scope - Policies covering malware protection, including signature update timelines and scan schedules - Screenshots or exports from your management console showing: coverage (all in-scope systems enrolled), signature currency (last update date for each endpoint), and scan history - Alert logs demonstrating that alerts are being generated and reviewed

Interview — Common questions: - "Walk me through how you know all your systems have anti-malware installed." - "What happens when malware is detected? Who gets notified? What's the response process?" - "How do you handle laptops that are offline for extended periods — how do you ensure their signatures are current when they reconnect?" - "How is removable media handled? Is it technically blocked, or just policy-blocked?"

Test — Assessors may use a benign test file (EICAR test string) to verify real-time scanning is active on systems they can access. They may check a subset of endpoints individually to compare against what the management console shows. Surprises here — endpoints the console shows as compliant that turn out not to be — are significant findings.

The evidence package to have ready: - Management console dashboard showing all enrolled endpoints, protection status, and last signature update - Sample of alert logs from the past 90 days with evidence of review or response - Scan schedule configuration - Removable media policy or technical control evidence - Incident response playbook section covering malware detection

Don't describe what you're going to do. Show what you've done. Policies without evidence of implementation are a common source of "partially met" findings in the SI domain.

---

Ready to assess your current endpoint protection coverage against the CMMC requirements? Schedule a gap assessment consultation — we'll map your existing tools to each SI domain control and identify what's missing before your C3PAO shows up.

Related reading: System and Network Requirements for CUI — scoping your environment correctly determines what needs to be protected.