Skip to content
ControlVerdict
Sign in
SI.L2-3.14.4CMMC Level 2Level 2

Update Malicious Code Protection [CUI Data]

Submit your own example

Practice statement

Update malicious code protection mechanisms when new releases are available.

Quoted verbatim from NIST SP 800-171 Rev. 2 §3.14.4.Source

The source document’s non-normative “Discussion” section is not reproduced here. ControlVerdict quotes normative text verbatim or omits it — it never paraphrases a standard. Follow the source link above for the full context.

Assessment Objectives(1)

An assessor determines each objective separately. “Mostly implemented” is not a result — every objective below has to stand on its own.

  1. [a]

    malicious code protection mechanisms are updated when new releases are available.

    1 example covers this

Objective text quoted verbatim from NIST SP 800-171A via the CMMC Level 2 assessment guide.

Implementation examples(1)

Submit your own example
  • addresses
    SI.L2-3.14.4Update Malicious Code Protection [CUI Data]
    Update malicious code protection mechanisms when new releases are available.

    • [a]

      malicious code protection mechanisms are updated when new releases are available.

    Definitions update automatically within hours; stale-definition devices lose CUI access

    ControlVerdict Corpus@cv-corpusOSCJul 31, 2026
    Community is just starting — add yours. No verdicts yet.

    Implementation

    AO coverage. Addresses the single Update Malicious Code Protection objective across every location designated for malicious code protection.

    Automatic by default. Signature and intelligence updates are pulled automatically on the vendor's release cadence, multiple times daily, with cloud-delivered protection on so the endpoint also consults current cloud intelligence between definition drops. Platform and engine updates ride the same automatic channel; the organization does not pin an engine version, because pinning is how “updated when new releases are available” silently becomes “updated last quarter.”

    Enforced freshness. Definition age is a compliance signal, not just a dashboard column. A device whose definitions are older than 3 days, or whose engine version falls behind the assigned baseline, is marked noncompliant and loses access to CUI applications through Conditional Access until it updates. This makes the update state self-correcting: the user's own workflow pushes them to reconnect and update rather than waiting on a help desk queue.

    Update path availability. Endpoint egress rules permit the vendor's update endpoints explicitly in the enclave allow-list, so the deny-by-default egress policy cannot starve the very mechanism this practice depends on. Devices that cannot reach the vendor fall back to an internal distribution point.

    Air-gapped hosts. The two lab hosts get a signed offline definition package on a controlled schedule — weekly, with the transfer logged in the same ticket queue. The procedure names the operator, records the package version applied, and includes verifying the signature before import. A missed week is a ticket, so a manual process still produces a record an assessor can sample.

    Failure visibility. Update failures alert rather than silently retry forever. The queue receives an item for any device failing definition update three times consecutively, and for any managed device that has not reported a definition version in 48 hours.

    Maintenance. Weekly report of definition age distribution and engine version spread across the fleet. Monthly confirmation that the offline package log has an entry for each week. Re-validate the update channel after major OS upgrades, which occasionally reset the update service state.

    Accepted gap. One vendor-managed test appliance receives definition updates on the vendor's own schedule, which the organization cannot control or verify directly. It is on an isolated VLAN with no route to the enclave, and the vendor's update attestation is filed with the annual exception review.

    What the evidence looks like

    • Endpoint protection policy showing automatic definition and engine updates enabled
    • Compliance policy definition keyed on definition age, with the Conditional Access dependency
    • Weekly definition-age and engine-version report for the fleet
    • Offline definition package log for the air-gapped hosts with operator and version per entry
    • Sample update-failure ticket and its resolution

    Environment

    Cloud-managed endpoint protection for the main fleet, plus two air-gapped lab hosts that must be updated by offline package.

    Tools

Discussion(0)

No discussion on this control yet

Edge cases, scoping questions, and “would this pass?” scenarios belong here.

Sign in to start a thread.