Requirement 3.14.2 is broader than 'install antivirus.' The contractor must provide malicious-code protection at appropriate locations in the environment, which can include endpoints, servers, email or web paths, and other ingress points based on design.
For a resource-constrained defense contractor, the practical test is not whether a policy exists on paper, but whether the requirement is implemented inside the defined FCI/CUI boundary, assigned to an owner, and backed by current, checkable evidence.
The rule in plain English
The phrase 'appropriate locations' matters. The organization should explain where malicious content can enter or execute and which protection covers each path.
Related requirements address updates and scans, so 3.14.2 should sit inside an operating malware-defense process rather than a standalone purchase.
How to implement it without overbuilding
Map endpoint protection, server protection, email security, and gateway scanning to the CUI boundary. Confirm in-scope devices are actually enrolled and reporting.
Define who reviews detections and what happens when protection is disabled, unhealthy, or missing.
What evidence to keep
Keep console coverage reports, policy configuration, engine/signature update status, detection records, exclusions, and remediation tickets.
A coverage export showing the in-scope population is generally stronger than one screenshot of a healthy endpoint.
Where teams get into trouble
Common gaps include unmanaged servers, stale agents, broad exclusions, and asset lists that do not reconcile to the security console.
Small-contractor walkthrough
Endpoint protection covers laptops but not two engineering servers and a legacy jump host. A meaningful malware-protection review reconciles the security console with the scoped asset inventory and documents justified exclusions instead of reporting only the vendor's license count.
- Map malware entry points.
- Reconcile protected assets.
- Review exclusions.
- Verify update status.
Decisions to document before assessment
Before marking this topic ready, make four decisions explicit: map malware entry points; reconcile protected assets; review exclusions; and verify update status. Assign an owner and an evidence location to each decision.
Manual deep review: designate protection locations and reconcile them to actual coverage
3.14.2 asks where malicious-code protection is needed and whether protection is provided at those locations. Endpoints are usually one location, but not necessarily the only one. Consider in-scope servers, email ingress, web or download paths, file-transfer portals, removable-media entry points, VDI hosts, build systems, and other places where untrusted code or files can enter or execute. Designated locations should come from the architecture and actual data flows, not from a security-product feature list.
If email is inspected by a managed cloud service, document that mechanism and the scope it protects. If a disconnected engineering workstation receives files through controlled removable media, its relevant protection path may be different. The objective is not to deploy every possible layer; it is to identify each material ingress or execution point and show an effective protection mechanism.
A healthy endpoint dashboard does not prove complete coverage if in-scope systems never enrolled. Compare the protection console with the asset inventory and investigate every mismatch. For devices that cannot use the standard agent, document why and how malicious-code risk is addressed around them. Review exclusions just as carefully: broad folder, process, extension, or application exclusions can weaken protection and should have an owner, reason, scope, and review point.
Keep 3.14.2 distinct from related requirements for updating protection mechanisms and performing scans. An update-status screenshot does not replace proof that protection exists at the designated locations. Before assessment, use one recent benign detection, quarantined file, blocked attachment, or controlled safe test to show operation, then sample each important system class and confirm active configuration and justified exceptions.
- Designated protection-location map.
- Asset-to-console reconciliation.
- Protection policy/configuration.
- Exclusion and exception review.
- Benign detection or safe operating evidence.
Manual assessment cross-check
Reconcile every designated protection location to the actual control and evidence source, then inspect one unhealthy, excluded, or exception asset from the last review cycle.
Use CMMC Malicious Code Protection: Endpoint and Email Scanning Evidence (3.14.2) as an operating guide, not as a substitute for the controlling source. Before publication or assessment use, re-open the current NIST SP 800-171 Rev. 2 requirement, the corresponding NIST SP 800-171A assessment objectives, and the DoD CMMC Level 2 Assessment Guide. Confirm that every mandatory statement on the page maps to those sources or to a clearly labeled organizational implementation choice.
Additional objective-level implementation notes
Keep 3.14.2 separate from adjacent controls. This requirement is about identifying appropriate protection locations and providing protection there; 3.14.4 addresses updates and 3.14.5 addresses periodic and real-time scanning. One security product may support all three, but the evidence map should show which mechanism proves which objective instead of using one dashboard screenshot for the whole family.
Use the location-to-mechanism map to find holes. Email filtering does not cover a customer portal, removable-media transfer, or unmanaged server unless those paths are also protected. Review unhealthy agents and broad exclusions as operating exceptions. A dashboard showing 95 percent coverage should lead to investigation of the missing five percent, not an automatic claim of completion.
Final manual spot check
For a final spot check, pick one designated protection location from each important class—endpoint, server, email or file ingress, and removable-media path where applicable. Show the active mechanism and current health for each. Then inspect one recent exception such as an excluded application, unhealthy agent, or legacy system. The exception record should explain the risk treatment and prove the organization notices protection gaps instead of assuming the security console represents every in-scope asset.
One more edge case to verify
Document who reviews coverage and exception reports and how missing protection is remediated. This turns the protection mechanism from a one-time deployment into an operating control that can detect its own coverage gaps.
A short working check
- ✓Map malware entry points.
- ✓Reconcile protected assets.
- ✓Review exclusions.
- ✓Verify update status.
- ✓Retain detection/remediation records.
- ✓Escalate unhealthy agents.
Common questions
Is Microsoft Defender automatically enough?
No product is automatically enough. The deployed configuration has to cover the relevant environment and be operated effectively.
Does 3.14.2 require email scanning?
It requires protection at appropriate locations; email is a common malware path that should be evaluated.
Do detections matter as evidence?
Yes. Detection and remediation records show the control operating, especially alongside configuration and coverage records.
Are exclusions a problem?
They can be. Necessary exclusions should be limited, justified, and reviewed.
Does every system need the same malware-protection product?
No, but every designated protection location needs an effective mechanism and evidence supporting the chosen architecture.
Official sources used for this guide
Open the primary source before making a contract-specific decision. Regulations and program implementation can change.
