SI.L2-3.14.4 malicious code protection updates: evidence

What SI.L2-3.14.4 requires and why assessors check it closely

A CUI contractor preparing for a Level 2 assessment needs to show one thing for SI.L2-3.14.4: its malicious code protection mechanisms are updated whenever new releases are available. The requirement is the Level 2 form of NIST SP 800-171 Rev. 2 requirement 3.14.4, and the assessment objective in NIST SP 800-171A is equally narrow. The assessor checks whether the anti-malware engines and definitions on in-scope systems are current against what the vendor has released. Because the objective is singular, a partial result is not a partial credit. The requirement is either MET with evidence in final form or it is NOT MET. The weight matters more than the wording. Under the CMMC Scoring Methodology in 32 CFR 170.24, SI.L2-3.14.4 is worth 5 points, which is subtracted from the maximum score of 110 if it is not met. Because it is worth more than 1 point, it cannot go on a Plan of Action and Milestones under 32 CFR 170.21(a)(2). A compliance lead should treat it as a gate: no open item is acceptable at assessment time. The Level 1 counterpart, SI.L1-b.1.xiv, comes from FAR 52.204-21 and asks the same question for Federal contract information, so a contractor that already passes Level 1 on this point has a head start on the same evidence. The difficulty is cadence. The CMMC Assessment Guide Level 2 notes that malware changes hourly or daily, and gives daily definition checks as an example of a configuration that works. Manual patch rounds cannot keep pace with that, and an assessor will ask for proof of the update process, not just a current version number. Confirm with your endpoint and mail gateway vendors how definition updates are delivered, whether automatic update settings are enforced by policy, and how a failed update is alerted and logged. Those settings, and the records they generate, are what turn SI.L2-3.14.4 from a claim into evidence.

Which systems and teams fall under SI.L2-3.14.4 scope

SI.L2-3.14.4 applies to every system inside the CUI boundary that runs malicious code protection, so scope starts with a precise inventory of those assets. The decisions below determine which endpoints, offline systems and third parties must show updated protection when an assessor asks for evidence.

Endpoints and servers inside the boundary

Every workstation, laptop, server and virtual machine that stores, processes or transmits CUI needs malicious code protection that receives new releases. Check the asset inventory against the boundary diagram, because a forgotten build server or engineering laptop that touches CUI is still in scope. Confirm for each host which engine and definition set it runs, who approves updates, and how the update is recorded.

Gateways and email filters

Firewalls, email gateways and web proxies that inspect traffic at the boundary often carry their own malware engines and signature feeds. Their update cadence can differ from endpoint products, so they need separate entries in the evidence set. Confirm that each gateway's signature or engine updates are enabled, that failed updates raise an alert, and that the update history can be exported.

Specialized, offline and test equipment

Operational technology controllers, lab instruments and air-gapped test systems may not accept vendor updates on the normal schedule, or may accept them only through a controlled transfer. These assets are still within scope if they handle CUI or connect to the boundary. Document the reason for any deviation, the compensating measure, the transfer procedure for offline updates and the record that shows when definitions were last applied.

Managed service providers and administrators

When a managed service provider pushes definitions, runs the endpoint console or manages the firewall, the organization still owns the requirement, and the provider's update activity becomes part of the evidence. Confirm in the service agreement who applies updates, how often, and who receives the records. Ask the provider to show update logs for in-scope assets and identify any assets it cannot reach.

Cloud hosts and shared platforms

Cloud-hosted virtual machines, managed container platforms and software-as-a-service tools that store CUI may rely on the provider for malware protection. Determine which layer is the organization's responsibility and which the provider performs, and obtain the provider's documentation for that layer. Where the organization runs its own agent on a cloud instance, that agent's update records belong in the evidence package.

Asset discovery and update monitoring

Scope is only as complete as the inventory behind it, and new hosts appear through projects, mergers and emergency purchases. Use a repeatable discovery method, such as an endpoint query tool that reports installed security agents and their definition versions across the fleet. Osquery can report running processes and installed software across hosts, which helps confirm that every in-scope system is covered and reporting current definitions.

How an assessor tests SI.L2-3.14.4 against SP 800-171A

This table breaks down the single SP 800-171A objective for SI.L2-3.14.4 into the examine and test activities an assessor performs, the evidence they request, and the findings that most often keep the requirement from being marked MET. Read it as a checklist of what your records must show before an assessor arrives, since a requirement worth 5 points cannot sit on a POA&M.

Assessment element	What the assessor does or checks	Common finding to avoid
Assessment objective	Confirms that malicious code protection mechanisms are updated when new releases are available. This is the only objective SP 800-171A lists for 3.14.4.	Protection is installed and running, but nobody can show that updates follow vendor releases.
Examine: update configuration	Reviews how the anti-malware product is configured to check for and apply definition and engine updates, including update frequency and source.	Automatic updates are disabled on some endpoints or set to a schedule that does not match vendor release cadence.
Examine: definition dates	Compares the date of each sampled host's current definitions with the dates of vendor releases in the same period.	Definitions are weeks or months behind the latest vendor release on a subset of hosts.
Examine: update records	Reviews logs or reports that show when updates were applied, which mechanisms they reached and whether any failed.	Update logs are missing, overwritten or cover only the management console, not the endpoints.
Examine: scan and detection records	Reviews scan results and records of actions taken on detections, which SP 800-171A lists as potential evidence.	Detections are logged but no record shows the action taken or the update that followed.
Test: update process and mechanism	Tests the process and mechanisms for updating and configuring malicious code protection, often by triggering or observing an update on a sample system.	The written process says updates are daily, but the tool was never tested against that process.
Test: host sampling	Selects a sample of hosts across the system boundary and checks each one's protection status and definition currency.	Unmanaged hosts, servers or test equipment outside the console are not counted in the population.
Evidence in final form	Accepts evidence that is final and current. Drafts, screenshots without dates or undocumented exports do not satisfy the objective.	Update procedures exist only as drafts or as an informal practice no one has written down.

Implementing malicious code protection updates step by step

This sequence turns the SI.L2-3.14.4 objective into a repeatable routine: every protected host is known, receives definition and engine updates on a schedule that matches vendor release cadence, is configured centrally, is checked for successful updates, and has any exceptions documented. Each step leaves a record an assessor can test.

Inventory every host that needs protection
Start with a complete list of the systems that run malicious code protection or should run it: servers, workstations, laptops, virtual machines, and any in-scope systems that process CUI. Record the host name, operating system, owner, location and the protection product installed. Compare the list against directory and asset records so that no endpoint is missing. The output is a protection inventory that the organization owns and keeps current, and it becomes the denominator for every later update check.
Set update schedules from vendor release cadence
Document how often each product's definitions and engine versions are released, then set the update check frequency to match. The CMMC Assessment Guide for Level 2 notes that malware changes hourly or daily and gives daily definition checks as an example, so many organizations use at least daily definition updates and confirm engine release timing with the vendor. Write the schedule into the system security plan or the protection standard. The output is a approved update standard that names each product, its cadence and its owner.
Enforce update configuration centrally
Configure update settings from a central management point rather than on each host by hand. Set the update source, the check interval, automatic engine upgrades where your change process allows them, and the behavior when a host is offline. Lock these settings so local users cannot disable them, and place the configuration under configuration management change control. Export the policy or configuration baseline and retain it. The output is a versioned policy export that shows the settings in force on each host group.
Monitor update success across the fleet
Query each host for the installed engine version and definition date, then compare the results with the inventory and the schedule. Osquery can run scheduled queries across a fleet to report running processes and file hashes, which helps confirm that the protection service is active and that its files are present, though the protection product's own console is usually the authoritative source for definition dates. Flag hosts whose definitions are older than the schedule allows. The output is a dated update report that lists compliant hosts and every host that fell behind.
Investigate and remediate lagging hosts
For each host flagged in the update report, identify the cause, such as a stopped service, a network path blocked from the update source, an expired certificate, or a machine that has been offline. Correct the cause and force an update, then confirm the new definition date in the next report. Keep the ticket that shows the investigation and the correction. The output is a closed exception log entry for each lagging host, with the root cause and the date the host returned to the schedule.
Record exceptions with approval and expiry
Some hosts cannot take updates on the standard schedule, for example isolated test equipment or operational technology with vendor restrictions. Record each exception with the host, the reason, the compensating measures, the approving owner and a review date. Confirm with the vendor and your assessor how exceptions will be evaluated, because a requirement must be MET for all applicable systems and a documented exception does not by itself satisfy the objective. The output is an approved exception register that is reviewed on a set cycle.
Retain evidence for the assessor
Assemble the artifacts that show the requirement is met: the update standard, the central configuration exports, the update reports from several points in time, the exception register, and the investigation records. Assessors test the processes and mechanisms for updating and configuring protection, so the evidence must show the routine operating over time, not a single snapshot. Keep final versions only, since drafts do not count as evidence. The output is an evidence folder mapped to the SI.L2-3.14.4 assessment objective and stored under your retention rules.

Evidence that proves malicious code protection stays current

SP 800-171A names the artifacts an assessor uses to test SI.L2-3.14.4, and each one answers a different question: is the protection in place, is it updated, does it catch threats, and what happened when it did. Keep these records final and dated so the picture holds between assessments, not just on the day of the review.

Protection mechanism inventory

Start with a current list of every malicious code protection mechanism in scope: endpoint agents, server agents, email and web gateways, and any scanning appliance. For each one, record the product, version, host or location, and the owner responsible for its updates. An assessor cannot test whether updates happen on a mechanism that is missing from the inventory. Check the list against your asset inventory, since a host with no agent is a gap the assessor will find.

Definition and engine update records

Keep dated logs showing when signature definitions and engine versions were updated on each mechanism. The assessment objective turns on whether updates occur when new releases are available, so these logs are the core proof. Export them from the management console on a regular schedule rather than relying on screenshots taken during the assessment. Note any update that failed and the retry that followed.

Update configuration evidence

Capture the policy settings that govern how often and how definitions are pulled, such as an automatic update schedule or check-in interval. The CMMC Assessment Guide gives daily definition checks as an example of a configured cadence. Assessors also test the process and mechanism itself, so show the settings exported from the console and the change record for any time they were altered.

Scan results and detection logs

Retain scan results and detection events from the protection mechanisms, showing what was scanned, when, and what was found. These records demonstrate that the protection is working against current definitions, which is the reason the updates matter. Confirm that logs are forwarded to a central store and retained long enough to cover the assessment period, and ask your assessor which retention window they expect.

Actions taken on detections

For every detection, keep a record of the response: quarantine, removal, isolation of the host, or a documented false positive. SP 800-171A lists records of actions taken on detections as potential evidence. A detection with no recorded response looks like an unmanaged event, even when the mechanism blocked it. Tie each record to the incident or ticket that followed, so the chain from detection to action is visible.

Final-form records and periodic review

A requirement is MET only when the evidence is in final form, so drafts, unsigned reviews and screenshots without dates will not count. Set a recurring review, at a cadence you define in your policy, where an owner confirms update logs and mechanism coverage and signs the result. Store the signed reviews with the rest of the evidence set so the record of currency exists for every period, not only the one before the assessment.

What meeting SI.L2-3.14.4 costs in money and effort

This table breaks down the cost and effort components of keeping malicious code protection updated for SI.L2-3.14.4, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. Use it to build a quote request, because no prices or durations for these components are published here and each figure depends on your own environment and scope.

Cost component	Who is paid or who does the work	One-time or recurring	What drives it up or down
Anti-malware licenses	The software vendor or reseller	Recurring (subscription or maintenance)	Number of endpoints and servers, license tier, and whether management consoles are bundled. Open-source engines can remove or reduce this line, but support and tuning still need budget.
Central update policy setup	Internal engineers or an implementation partner	One-time, with occasional rework	Number of sites, operating systems, and disconnected or air-gapped segments that need a separate update path. Standardizing on one console keeps setup smaller.
Update compliance monitoring	Internal security or operations staff, or a managed service	Recurring	Fleet size, how often definitions change, and whether dashboards report version and definition age per host. Automated alerts reduce manual checks.
Evidence upkeep	Internal compliance staff, with input from engineers	Recurring	Frequency of exports (update logs, scan results, detection actions), how many systems are in the assessment boundary, and how well records are retained automatically.
Detection response records	Internal security team	Recurring, driven by detection volume	Number of detections and how many need documented action. Clear response procedures keep records consistent.
External review or consultant support	Independent consultant or implementation partner	One-time for readiness, optional recurring for reviews	Size of the environment, prior assessment history, and whether the consultant only reviews evidence or also configures systems. Ask for a fixed scope in writing.
Assessor fees for certification assessments	The C3PAO that performs the Level 2 assessment	One-time per assessment cycle	Assessment scope, number of systems and sites in scope, and assessor availability. Confirm current Phase II status with the DoW before budgeting.
Open-source tooling (illustrative)	Internal staff or implementation partner for deployment and tuning	One-time setup, recurring operations	Lower license spend shifts cost toward engineering, testing, and support. Ask whether the tool's update mechanism is documented and tested for your environment.

How osquery and Velociraptor produce SI.L2-3.14.4 evidence

osquery exposes operating system state as SQL tables, and its osqueryd daemon can run the same queries on a schedule across an entire fleet of hosts. For SI.L2-3.14.4, the useful question is whether the malicious code protection engine is running, and whether the process and file state on each endpoint is consistent with a current, updated install. Queries against running processes, loaded kernel modules and file hashes give you recurring, host-level data that you can review and retain as evidence of operation. The tool does not read anti-malware vendor update logs by itself, so the definition version check usually depends on a query against files or an application-specific table that you confirm for your product.

Process presence: Scheduled queries can show whether the endpoint protection service process is running on each host and when the state last changed.
Kernel and driver state: Loaded kernel modules help confirm that endpoint protection drivers are present on systems where your product requires them.
File hashes: Hashing the protection engine and definition files lets you show that files changed between collection cycles, which supports update tracking.
Result retention: Route osqueryd output to a log store you control so that results from prior periods remain available to the assessor.
License: osquery is licensed under Apache-2.0 OR GPL-2.0-only, so confirm that the license choice fits how your organization distributes or modifies it.

Confirm which tables and paths expose definition versions for your specific anti-malware product before you rely on this approach.

Who owns SI.L2-3.14.4 and what a partner can take on

Your organization owns SI.L2-3.14.4. That means the decision about how often malicious code protection updates, who approves the configuration, and who answers for a missed update sits with your security and IT leadership, not with a vendor. The evidence has to come from your environment and be in final form when the assessor asks for it. Assessors test the update process itself, so the people who run it must be able to explain it.

Policy and update standard: Define which malicious code protection mechanisms are in scope and what "new release available" means for each, including signature feeds and engine versions.
Accountable roles: Name the individual who owns updates on each platform and the backup who covers absences.
Operating records: Keep update logs, detection records and the actions taken on each detection for the assessment period.
Exception decisions: Document any deferred update, who approved it and the compensating control in place.
Final-form evidence: Work from approved, dated documents, not drafts, because the assessment looks for final evidence.

Before you engage anyone, confirm that a named owner can walk an assessor through the update workflow from release notice to verified deployment.

Common gaps that cause SI.L2-3.14.4 to fail

SI.L2-3.14.4 is worth 5 points and cannot go on a POA&M, so a gap in malicious code protection updates can move a contractor below Conditional or Final Level 2 status. The gaps below share one root cause: the organization cannot show, with dated records, that every protected system received new definitions and engines when releases were available.

Definitions updated only by manual checks

When an administrator logs in and clicks update when they remember to, the update cadence depends on memory rather than configuration. The assessment objective asks whether mechanisms are updated when new releases are available, and malware changes hourly or daily according to the CMMC Assessment Guide. Check that automatic definition updates are enabled in the product's policy, that the schedule is recorded in the configuration baseline, and that the console shows last-update timestamps for each engine and definition set.

Unmanaged hosts missing from the console

Laptops, lab machines, engineering workstations and servers built outside the standard image often never enroll in the update console, so they run stale definitions while the dashboard shows green. Assessors will ask for the complete population of in-scope assets and compare it to the protection console. Reconcile the asset inventory against enrolled endpoints each month, and treat any host that does not report as a finding to close, not a footnote.

Offline and air-gapped systems without an update process

Systems that never reach the internet still need new definitions, so a missing transfer process is a common failure. Define how signatures are obtained, validated and moved across the boundary, who approves the import, and how each import is logged. Confirm with the product vendor which update packages are available for offline use and how their integrity is verified before they are placed on a restricted network.

Current product with no dated update records

An assessor may see a current engine version and current definitions, yet find no history showing when they were applied. SP 800-171A lists records of updates and scan results as potential evidence, so a snapshot alone does not show that updates happen when releases appear. Export update logs or console histories on a schedule, retain them, and keep the timestamps that show each release was applied, including the gap between availability and deployment.

Update failures with no follow-up

Definition pushes fail when a host is offline, disk space runs out, a service is stopped, or a policy conflict blocks the agent. These failures often show up as errors in a console nobody reviews. Set an alert for hosts whose definitions fall behind the policy window, assign an owner to clear each exception, and record the corrective action so the failure and its resolution both appear in the evidence.

SI.L2-3.14.4 questions buyers ask before hiring help

How much does outside help for SI.L2-3.14.4 usually cost?

No single price applies to this control, so the cost depends on the written scope. Costs come from three sources: partner time to configure the malicious code protection tool, document the update procedure and organize evidence; your own staff time; and the independent assessor, who is paid separately. Most of the setup cost is one-time, such as configuration, testing and writing the procedure. Recurring cost is smaller and comes from keeping definitions current, reviewing update records and any ongoing retainer. Costs rise with the number of endpoints and servers in scope, the number of tools involved, and the number of sites or enclaves that need coverage. Ask for a quote that names the systems covered, the deliverables and the evidence you will receive, then compare quotes against that scope.

How long does it take to get ready for SI.L2-3.14.4?

The timeline depends mainly on how mature your update process already is, and no duration for this control has been established here. If your protection product already updates automatically and logs each update, the work is mostly testing and documenting that evidence. If updates are manual or some hosts are unmanaged, expect more time to inventory assets, standardize configuration and collect several cycles of records. Federal timing also matters. The Department of War suspended CMMC Phase II on 13 July 2026, so confirm the current schedule on the official DoW CIO page before you set an internal deadline. Ask any partner for a milestone plan in the written scope, with each milestone tied to a specific piece of evidence.

What does our team need to provide for this control?

Your team owns the control, so the partner needs named people who can make decisions and grant access. Name an owner for malicious code protection, usually in IT operations or the security team, and someone who can approve configuration changes. The partner will need administrator-level access to the management console, a current inventory of endpoints and servers, your existing change process, and copies of update logs and scan results. Staff time goes into reviewing configuration, confirming that every in-scope host is covered, and approving written procedures. Without these inputs and approvals, the work stalls on access requests instead of moving forward on technical tasks.

Can a small team handle SI.L2-3.14.4 in-house?

Often yes, because SI.L2-3.14.4 has a single assessment objective: malicious code protection mechanisms are updated when new releases are available. The practical test is whether one person can show, for every in-scope system, that the protection is installed, updates on the vendor's release cycle and leaves a record. The CMMC Assessment Guide Level 2 notes that malware changes hourly or daily, so plan for updates at that frequency. Small teams most often miss unmanaged laptops, servers in a separate enclave and systems that stay offline for long periods. Outside help is useful for a configuration review against the assessment objective, a practice assessment or evidence packaging. Your team still owns the control, and the independent assessor still tests it.

What does a partner do versus the assessor for this control?

A partner prepares the systems, controls and evidence, and an independent assessor tests them and issues the outcome. DeployOpen plans, configures, documents and supports self-hosted platforms in your environment and helps prepare SI.L2-3.14.4 evidence, but it does not issue assessment reports, attestations or certifications. For Level 2 certification, a C3PAO authorized or accredited by The Cyber AB performs the assessment against the NIST SP 800-171A objectives. Because the Department of War suspended Phase II on 13 July 2026, confirm which assessment path currently applies to your contracts before you engage anyone. Scope the partner to build and document the control, and scope the assessor to test it independently.

Can SI.L2-3.14.4 be placed on a POA&M?

No. SI.L2-3.14.4 is worth 5 points, and under 32 CFR 170.21(a)(2) a requirement worth more than 1 point cannot be placed on a plan of action and milestones. It must be MET to reach Conditional or Final Level 2 status. If it is NOT MET, its 5 points are subtracted from the maximum score of 110, so this control cannot be deferred with a POA&M. Plan to test it early, before any formal assessment, and keep a dated record of each update on every in-scope system. Confirm the current rule text in the eCFR, since it is the authoritative source for POA&M eligibility.

Which open-source tools can produce evidence for SI.L2-3.14.4?

osquery and Velociraptor can help you check coverage, but neither replaces the malicious code protection product itself. osquery exposes running processes, loaded kernel modules, open network connections and file hashes as SQL tables, and osqueryd can schedule those queries across a fleet of hosts. This helps confirm that protection is running and that hosts report in. Velociraptor collects forensic artifacts through hunts, schedules collection for offline machines when they reconnect, and creates a notebook per hunt for analysis. Confirm with your protection vendor which update history and definition versions the product exposes, and ask whether the platform can export that history in a form an assessor can review.

How DeployOpen prepares SI.L2-3.14.4 systems and evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so update mechanisms for malicious code protection run on your systems and produce records you control. We prepare the systems and evidence for SI.L2-3.14.4, while your organization owns the control and an independent assessor makes the determination.

How we scope

Written scope names the endpoints, servers and gateways where malicious code protection must update.
We confirm which update sources, release cadence and configuration settings apply in your environment.
Scope lists the evidence each assessment objective needs, such as update records and scan results.

How we build

We configure malicious code protection to check for and apply new definitions and engine releases on a defined schedule.
We set up osquery queries that report agent versions and definition status across the fleet.
We test update mechanisms on sample hosts, including systems that are offline for extended periods.

How we hand over

Handover includes configuration records, update logs and runbooks that your staff can operate after delivery.
We document test results against the SP 800-171A objective so your team can review them before assessment.
Evidence is delivered in final form, with dated records that your assessor can trace to each system.

How we support

Ongoing support is available as a retainer for monitoring update health and handling changes to the platform.
Retainers can cover periodic checks of update records ahead of your assessment or annual review.
Confirm with us in writing which support tasks, response expectations and review frequency apply to your engagement.