SI.L2-3.14.2 Malicious code protection requirements

What SI.L2-3.14.2 malicious code protection asks a defense contractor to prove

A compliance lead preparing a CUI environment needs to show one thing for SI.L2-3.14.2: malicious code protection is running at every place where malicious code can enter the system, and the organization can prove it. The requirement asks the organization to identify its designated locations and provide protection at each of them. In practice, that means naming the firewalls, email gateways, endpoints and other devices that screen for malware, then showing that the protection is active there. The requirement is worth 5 points under the CMMC Scoring Methodology, and if it is NOT MET, 5 points come off the maximum score of 110. Because it is worth more than 1 point, it cannot go on a plan of action and milestones (POA&M), so it must be fully MET before the organization can reach Conditional or Final Level 2 status.

The risk is straightforward. The CMMC Assessment Guide Level 2 notes that a designated location may be a network device such as a firewall or an end user's computer, and that malicious code can arrive by email, removable media or websites. An assessor will walk from those entry points inward and ask whether protection is present at each one. The hard parts are usually three: designated locations that were never written down, gaps where some endpoints, laptops or remote workers are outside the agent's coverage, and missing records of what the protection detected and what staff did about it. Assessment objects typically include the protection mechanisms, update records, scan results and records of actions taken on detections, so the compliance lead should confirm that each of these can be produced in final form.

The Level 1 counterpart is SI.L1-b.1.xiii, which applies the same assessment objectives to Federal contract information, so an organization that already meets the Level 1 version has most of the groundwork in place. Start by reconciling the designated location list against the asset inventory and the boundary diagram, then confirm with the assessor or the Department of War's current CMMC guidance which assessment path applies to the contract. Current program status is changing, so verify it against the DoW CIO About CMMC page before scoping the work.

Which systems and locations malicious code protection must cover in a CUI environment

Malicious code protection is only as complete as the list of locations it covers. The organization decides which locations are designated, documents that decision, and must be able to show that the list matches the systems that actually store, process or transmit CUI. The cards below cover the locations and access paths that most often get missed.

Network boundary devices

Firewalls, web proxies and other boundary devices are the most common designated locations for SI.L2-3.14.2 because they see traffic entering and leaving the CUI boundary. Record each device, its management interface and what protection it applies, such as malicious code inspection of web or file traffic. Check that devices added during network changes appear on the list. An assessor will compare the list against the network diagram in the system security plan and look for gaps.

Email gateways and mail flow

Email is a documented route for malicious code, so the gateway that scans inbound and outbound messages and attachments belongs on the designated locations list. Confirm which mailboxes, relays and cloud mail services route through it, including any that bypass the gateway for legacy applications or service accounts. Keep the gateway's update and alert records, since assessors look for evidence that the protection was operating, not only installed.

Servers and end user computers

Endpoints and servers are designated locations because the CMMC Assessment Guide accepts an end user's computer as a valid location. Build the list from the asset inventory rather than from memory, and include virtual machines, administrative jump hosts and systems outside the normal domain that still handle CUI. Mark which assets run protection agents, which are exceptions and why, and who approves each exception. Undocumented servers are a frequent finding.

Removable media and file transfers

Malicious code can arrive on USB drives, optical media and other removable devices, so the designated locations must include the workstations and kiosks where those devices are read. Document the procedure for scanning media before use and state which systems are permitted to accept media at all. Pair this with the media protection requirements, because a scanning rule that is not enforced on the workstation that opens the drive does not protect anything.

Cloud and third-party services

Any cloud service, managed service or contractor system that processes, stores or transmits CUI is part of the environment, and the locations that protect it must be on the list or covered by evidence from the provider. Ask each provider which malicious code controls apply to the service and what records they will furnish. Where the provider cannot supply evidence, the organization must still account for the service in its own documentation.

Keeping the list matched to reality

The designated locations list must be reviewed whenever assets, network paths or services change, and the assessor will test whether it matches the live environment. Reconcile the list against the asset inventory, the boundary diagram and the protection console's enrolled agents at least on a fixed schedule set by the organization. Record each reconciliation, the discrepancies found and how they were closed. Confirm with the assessor which evidence format they expect for this check.

How an assessor tests malicious code protection under SP 800-171A

This table compares the two SP 800-171A assessment objectives for SI.L2-3.14.2 and the assessment objects an assessor examines for each, with the test approach, evidence requested and findings that commonly cause a requirement to be scored NOT MET. Read each row as what the assessor will test, what they will ask you to produce, and where organizations usually fall short before the assessment.

Assessment element	Test approach	Evidence requested	Common findings
Objective: identify designated locations	Compare the organization's documented list of locations (firewalls, email gateways, endpoints, servers) against the system boundary and asset inventory	Boundary diagram, asset inventory, documented list of locations where protection is applied	Locations missing from the list, such as remote laptops, servers or cloud workloads outside the documented boundary
Objective: provide protection at designated locations	Sample locations from the list and confirm a protection mechanism is active and covers the listed asset	Deployment reports from the management console, agent coverage reports, gateway scanning configuration	Agents installed on some endpoints but not others, or gateway scanning disabled for a mail route
Protection mechanisms	Review the mechanisms in use and confirm they are configured to run at each designated location	Product list, configuration exports, policy assignments by device group	Mechanisms installed but not enforcing, or policies inherited incorrectly across groups
Update records	Check that definitions and engines are current and that updates are applied on a defined schedule	Update logs, version history, console timestamps showing the last successful update per location	Stale definitions on isolated or offline systems, and no record of update failures being handled
Scan results	Review scan records for coverage, frequency and the results they report	Scan logs, completed scan reports, scheduled scan configurations	Scans configured but never run, or reports stored without review or retention
Records of actions on detections	Trace a sample of detections from alert to documented response, including quarantine, removal or escalation	Detection logs, quarantine records, tickets or incident entries tied to each detection	Detections cleared without recording the action taken or who took it
Process: employing, updating and configuring	Interview administrators and read the procedures to confirm how the mechanisms are deployed, kept current and set up	Written procedures, change records for configuration, responsible role assignments	Procedures describing a process that staff do not follow, or no owner named for configuration changes
Process: handling false positives	Examine how false positives are identified, validated and excluded without weakening protection	Exclusion lists with justification and approver, records of false positive reviews	Broad exclusions with no approval, or exclusions that remove entire file types or directories

How to implement malicious code protection step by step

This sequence takes an organization from an undocumented malware posture to evidence an assessor can test against the two SP 800-171A objectives for SI.L2-3.14.2. Each step names what it produces, so the final dated test closes the loop on designated locations, protection, configuration, collection and handling.

Define and document designated locations
Start by listing every place in the system boundary where malicious code can enter or run: firewalls and gateways, email filtering, web proxies, servers, and end user computers, including removable media entry points. The assessment guide notes that a designated location may be a network device or an end user's computer, so the list must cover both. Record the list in the system security plan with the owner of each location. The step is done when an assessor can compare the list against the boundary diagram and find no gaps.
Select and deploy protection at each location
For each designated location, choose a protection mechanism that matches the threat path, such as endpoint protection for workstations and servers, mail filtering for inbound messages, and content inspection at network boundaries. Open-source options such as Wazuh and osquery can contribute visibility and file hash checks, but confirm whether a given tool provides malware prevention or only detection in your environment before you rely on it. Deploy the mechanisms and record an inventory entry for each one. The output is a deployment register that maps each location to its mechanism.
Configure protection and document the settings
Set each mechanism's policy in writing, including what it scans, which actions it takes on detection, whether users can disable it, and how exceptions are approved. Keep the configuration in version control or a managed baseline so changes are traceable. Confirm the settings with a sample of endpoints and gateways rather than trusting the console alone. The output is a configuration baseline with a reviewer sign-off and a record of each deviation.
Centralize detections and scan results
Route detection events, scan results and administrative actions from every location to one collection point, such as a SIEM or log platform. Self-hosted options include Wazuh, which decodes logs and writes matching alerts to alerts.json and alerts.log, and OpenSearch Security Analytics, which runs detectors against ingested logs. Verify that every designated location appears in the collection point, and that records are retained according to your own log policy. The output is a dashboard or query that shows detection activity per location.
Write the detection and false positive procedure
Write a procedure that says who reviews a detection, how a confirmed infection is contained and cleaned, how a suspected false positive is validated before it is closed, and when an incident is opened under your incident response process. Assessors test the process for handling false positives, so the procedure must name the steps and the records. Keep one example record per detection type. The output is an approved procedure with roles, triggers and a template for each action record.
Run and date a test that produces evidence
Test each designated location with a controlled, harmless test artifact or a vendor-supplied test, and confirm that the mechanism detects or blocks it, that the event reaches central collection, and that the procedure produced a closed record. Date the test, record who ran it, and keep the results. Use final documents only, because an assessor marks the requirement MET only when all applicable objectives are satisfied with evidence in final form. The output is a signed test report that maps each location to its detection, alert and action record.

Evidence that satisfies malicious code protection and how to keep it current

Assessors test SI.L2-3.14.2 by reading records, not policy statements. The six artifacts below are the ones that connect the designated locations to working protection, and each one needs a recurring routine so it is still accurate when an assessor asks for it. Remember that a requirement is MET only when evidence is in final form, so drafts and unsigned exports do not count.

Designated location register

This is the list of places where malicious code protection is deployed, such as firewalls, email gateways, file servers and endpoints, including end user computers. The first assessment objective depends on it, because you must show which locations were designated. Review the register whenever hosts, gateways or cloud workloads are added or retired, and record the date and approver of each change so the register matches the asset inventory an assessor samples.

Protection configuration exports

Exports of the malicious code protection settings show what is actually enforced at each designated location, including real-time protection, scan scope and exclusions. Export the configuration from each platform on a set schedule and after any policy change, then compare it to the approved baseline. Confirm with your tooling vendor which settings are exportable and in what format, since an export that omits exclusions weakens the record.

Update and signature records

Records of engine and signature updates show that protection stayed current at each location. Keep a dated log per location with the version before and after each update and any update that failed. These records also support SI.L2-3.14.4, so a single, consistent log serves both requirements. Check the log for gaps against the vendor release cadence, and investigate any location that falls behind.

Scan results and detection tickets

Scan reports and the tickets opened from detections show that protection actually ran and that the organization acted on what it found. Keep scan output for the period under review, and tie each detection to a ticket that records the host, the file or indicator, the action taken and who closed it. An assessor who samples a detection will expect to follow it from alert to closure, so make that trail easy to walk.

False positive handling procedure

The assessment objectives for 3.14.2 cover processes for handling false positives, so you need a written procedure and the records it produced. Define who can approve an exclusion, what justification is required, how long the exclusion lasts, and when it is re-reviewed. Keep each approved exclusion in the register with its approver and review date, and remove exclusions that no longer have a valid reason.

Open-source telemetry for ongoing evidence

Open-source tools can generate some of this evidence continuously rather than by hand. osquery can schedule queries across a fleet to report running processes and file hashes, Velociraptor can collect artifacts from endpoints, including offline machines when they reconnect, and Wazuh can write matched alerts to alerts.json for review. Confirm which of these outputs your environment can retain in final form and for how long before relying on them as evidence.

Which self-hosted open-source tools produce malicious code protection evidence

osquery exposes operating system state as SQL tables, including running processes, loaded kernel modules, open network connections, browser plugins, hardware events and file hashes. Its osqueryd daemon can schedule queries to run across an entire fleet of hosts, which lets a team check for suspicious processes or unexpected binaries on a recurring basis and keep the results as dated records.

Process and file hash visibility: Queries can list running processes and compare file hashes against known values, which supports the investigation of detections.
Fleet-wide scheduled queries: Scheduled results show whether endpoints were checked on a defined cadence, a point assessors often ask about.
Query results as records: Stored output can show what was observed on each host at each run.
Limits: osquery observes state. It does not quarantine files or block execution, so a protection mechanism must still be deployed at the designated locations.
License: osquery is licensed under Apache-2.0 OR GPL-2.0-only, so confirm which license option your deployment relies on.

Confirm with your assessor whether query results alone satisfy the objective for records of detections, or whether they must be paired with the protection product's own logs.

What meeting malicious code protection costs in money and effort

This table compares the main cost components of meeting SI.L2-3.14.2 and shows who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to build a written scope and to ask vendors and partners for line-item quotes. DeployOpen does not publish a price list, and a quote follows a written scope.

Cost component	One-time or recurring, and who is paid	What drives it up or down
Protection licenses or subscriptions	Recurring. Paid to the endpoint protection or gateway vendor, or to none if an open-source stack is used; confirm any licensing terms with the vendor.	Number of endpoints, gateways and firewalls in scope. Open-source options such as Wazuh remove most license spend but still need hosting and staff time.
Engineering time to deploy and configure	One-time. Paid to internal IT staff or an implementation partner under a fixed-scope agreement.	Number of designated locations, mix of platforms, and whether the scope is written before work starts. A defined list of locations shortens this work.
Designating protection locations and documenting them	One-time, with periodic review. Paid to internal staff, often the security lead.	Size and complexity of the boundary. Clear diagrams of firewalls, email gateways and endpoints reduce rework at assessment.
Ongoing signature and engine updates, tuning	Recurring. Paid to internal staff or a managed service provider.	Update cadence, false positive volume and the number of platforms. Tuning rules once and reviewing false positive handling on a set schedule keeps effort steady.
Evidence collection	Recurring. Paid to internal staff. Assessors look for update records, scan results and records of actions taken on detections.	Whether logs and reports are centralized. Automated exports from the console or a central dashboard lower the effort per assessment.
External review or testing	Recurring or periodic. Paid to an independent reviewer or a testing firm, which does not issue the assessment result.	Depth of pre-assessment review and whether testing covers detection quality. Ask for a fixed-scope review with named deliverables.
Assessor time	Periodic. Paid to the C3PAO or assessor for Level 2 certification, or to the organization for a self-assessment. Confirm current requirements with the DoW CIO.	Number of objectives and evidence items reviewed. Evidence in final form, not drafts, is needed to score the requirement as MET.

Who does what for malicious code protection: your team, a partner and the assessor

Your organization owns SI.L2-3.14.2 in full. The requirement asks you to identify the designated locations where malicious code protection must run and to provide that protection there. Those decisions belong to you, because they reflect your system boundary, your data flows and your risk tolerance. A partner can recommend a design, but it cannot accept the risk or sign off on the scope on your behalf.

Designated locations: Decide and document which firewalls, email gateways, servers and endpoints carry protection, and record the reasoning in your system security plan.
Operating the protection: Run the mechanisms day to day, review alerts, and handle false positives and detections through your incident process.
Updates and records: Keep the update history, scan results and action records that an assessor will ask to see.
Process ownership: Assign named roles for employing, updating and configuring the protection, and confirm that staff follow those procedures.
Final evidence: Approve the evidence package in final form, since drafts do not count toward a MET result.

Before any assessment, confirm that someone on your staff can explain the designated locations and show records from the past several months without help from the partner.

Where malicious code protection usually fails an assessment and how to close each gap

SI.L2-3.14.2 is a 5-point requirement that must be MET, so a gap here cannot be carried on a POA&M. The gaps below are the ones that most often leave an assessor with objectives they cannot mark satisfied, and each one is closed by documenting or retaining something the organization already runs.

Designated locations never written down

The first assessment objective requires the organization to identify the designated locations for malicious code protection. Many organizations run protection on endpoints but have no list that names the firewalls, email gateways, servers and end user computers in scope. Write the list into the system security plan, tie each entry to an asset in the inventory, and record who approved it. Check that every location on the list can produce a current protection status when asked.

Coverage that misses email and removable media

The CMMC Assessment Guide notes that malicious code can arrive by email, removable media or websites, so an assessor will test whether protection sits at each of those entry points. Endpoint agents alone often leave the mail gateway and USB-connected devices unchecked. Confirm that the designated locations include the gateway and that removable media scanning is enforced on endpoints. Test with a benign sample file to show the control triggers.

Update records that stop after deployment

Assessors look for records of how protection mechanisms were updated, not only proof that they were installed. Teams often deploy an agent once and never keep a log of signature or engine updates afterward. Set up a recurring export of update history from each mechanism, store it with the scan records, and review gaps in the update log on a fixed schedule. Keep the record for every designated location, including the ones that are offline for long periods.

Scan results not retained

The potential assessment objects for 3.14.2 include scan results. When the console overwrites results after each run, the organization cannot show what it found over the assessment period. Decide a retention period in the policy, export scan summaries to a central store with access controls, and make sure the store survives agent or server rebuilds. Ask the assessor which format they accept before choosing the export method.

Detections with no documented response

Assessors test whether the organization records the actions it took on detections. A quarantine event that no one reviewed, or a removal with no ticket, does not show that protection was provided. Write a short response procedure that covers isolating the host, removing the file, checking for spread and closing the record. Link each detection to an incident or ticket number so the response trail can be traced for any sampled event.

False positive handling held in people's heads

The assessment covers tests of the process for handling false positives, and that process is often known only to one or two administrators. Without a written method for exceptions, the team may whitelist files informally, which an assessor will find when reviewing configuration. Document who may approve an exception, what evidence must accompany it, how it is reviewed and when it expires. Keep the exception register with the scan records so the process can be demonstrated, not described.

Questions buyers ask about SI.L2-3.14.2 malicious code protection

How much effort does malicious code protection take to meet?

The effort depends mostly on how many designated locations your systems have and how much protection is already running at each one. NIST SP 800-171A splits the requirement into two assessment objectives: identify the designated locations, then show that protection is provided at them. Designated locations can include firewalls, email gateways and endpoints, so a small environment with a few servers and laptops usually takes far less work than a fleet spread across several sites. Ask any partner to size the work from a written inventory of locations and the protection already deployed at each. The cost table on this page lists the drivers in more detail.

Can our own IT team meet SI.L2-3.14.2 without outside help?

In many cases an internal team can meet it, since the work is deploying, configuring and running protection across known locations. The organization owns the control and its evidence either way. Outside help is most useful when no one has a current map of designated locations, when the team lacks time to collect update and scan records, or when leadership wants an independent review before an assessor arrives. Assessors test the mechanisms and their records directly, so a vendor's statement that protection is installed does not replace evidence from your own environment. Whichever path you choose, the people who run the protection day to day should be able to show it working.

What evidence does our team need to provide for the assessment?

Assessors look for four kinds of material tied to the requirement:

A list of designated locations, such as firewalls, email gateways, servers and end user computers.
The malicious code protection mechanisms deployed at those locations, with their configuration.
Records of updates, scan results and the actions taken on each detection.
Written processes for employing, updating and configuring the protection, along with the process for handling false positives.

The assessment guide for Level 2 notes that malicious code can arrive by email, removable media or websites, so the locations you document should reflect those paths. Each item must be in final form when the assessor reviews it. Drafts do not count toward meeting the requirement.

How long does it take to produce evidence for SI.L2-3.14.2?

No researched duration is available for this requirement, so confirm the timing with your assessor and your implementation partner before planning. What you can plan for is that update records and scan results are operating history, which accumulates over time. An assessor sees records of protection actually running, so a missing period cannot be filled in with documents written shortly before the review. Start by confirming that logging and update records are being kept in a form you can export, and that the written processes match what the team actually does. The official CMMC Assessment Guide, Level 2 describes what assessors examine.

Can SI.L2-3.14.2 go on a plan of action and milestones?

No. SI.L2-3.14.2 is a 5-point requirement in the CMMC Scoring Methodology, and 32 CFR 170.21(a)(2) does not allow requirements worth more than 1 point on a POA&M. If the requirement is scored NOT MET, its 5 points are subtracted from the maximum score of 110. It must be MET to reach Conditional or Final Level 2 status. Plan the work so the protection and its records are in place before the assessment rather than relying on a remediation schedule afterward. Confirm the current scoring rules with your contracting office, since the rule text is the controlling source.

How does the Level 1 malicious code requirement differ from Level 2?

The Level 1 counterpart is SI.L1-b.1.xiii, which comes from FAR 52.204-21(b)(1)(xiii). A Level 1 self-assessment uses the same SP 800-171A objectives for 3.14.2, with federal contract information (FCI) substituted for controlled unclassified information (CUI). The protection you deploy for Level 1 can carry over to Level 2, but Level 2 adds the records, documented processes and final-form evidence that the Level 2 assessment expects. Level 2 also scores this requirement at 5 points and does not allow a POA&M for it. Level 1 covers the 15 safeguarding requirements for FCI, so a team at Level 2 should treat this requirement as a fuller evidence exercise, not a repeat of Level 1 work.

What changes if the CMMC Phase II timing shifts again?

The Department of War suspended CMMC Phase II on 13 July 2026, which had been scheduled to start 10 November 2026 and would have required Level 2 C3PAO certification for applicable contracts. It also started a 60-day review by a CMMC Reform Task Force. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. The control itself does not change: the 5-point scoring, the MET requirement and the evidence standard still apply. What can move is which contracts require a certification assessment and when. As of 17 October 2026, the DoW CIO page says implementation is paused in Phase 1 and may only require self-assessments at Levels 1 and 2, while the eCFR still shows the original schedule. Confirm the current status with your contracting officer and read the Department of War suspension release.

How DeployOpen scopes and prepares malicious code protection evidence

DeployOpen plans, implements and documents self-hosted open-source platforms that can produce the malicious code protection evidence SI.L2-3.14.2 calls for, inside your own infrastructure. We prepare systems and records for your assessment, while your organization owns its controls and an independent assessor makes the final determination.

How we scope

Written scope names the designated locations, such as firewalls, email gateways and endpoints, where protection must apply.
Scope lists the in-boundary systems, operating environments and CUI flows that the 3.14.2 objectives must cover.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.

How we build

We configure endpoint telemetry and query tooling such as osquery to check running processes and file hashes across hosts.
We set up alerting for detections so each event has a documented record of the action taken and who took it.
We test the update, configuration and false positive handling processes that an assessor will ask to see working.

How we hand over

Documentation maps each designated location to its protection mechanism, owner, update method and review procedure.
Evidence packages hold configuration exports, update records, scan results and detection response logs in final form.
We confirm with your assessor which artifacts they expect, since the assessor decides what satisfies each objective.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
Retainers can keep detection rules, scan schedules and evidence collection current between assessments.
Security testing can check whether protection at designated locations actually stops the malicious code it is meant to catch.