Malicious Code Protection is the requirement behind your anti-malware program, and in R3 it is considerably bigger than it looks. It absorbs two withdrawn R2 requirements and now covers deployment, updates, scan frequency, real-time scanning, and what the tool actually does when it finds something. Malicious Code Protection (03.14.02) has three (3) parts: implement protection mechanisms at system entry and exit points to detect and eradicate malicious code, update those mechanisms as new releases become available, and configure them to perform scans and to block, quarantine, or otherwise respond to detections. Per the NIST discussion, malicious code includes viruses, worms, Trojan horses, and spyware, and protection mechanisms include both signature-based and non-signature-based technologies.
A common difficulty with this requirement is having anti-malware installed and updating but never confirming what it is configured to do on detection. R3 makes the response action its own assessment objective, and it is the one net-new piece of this requirement. A tool that detects and alerts but is not configured to block, quarantine, or take other action leaves that objective open. For Department of Defense (DoD) contractors, the scan frequency is specified.
Where things stand for companies facing the transition from NIST 800-171 R2 to R3:
The following is reproduced verbatim from NIST 800-171 R3, requirement 03.14.02 Malicious Code Protection. Only the formatting has been adjusted for readability. This requirement has three (3) lettered parts, the last with numbered sub-parts:
The source control is SI-03 from NIST 800-53. The bracketed assignment in part c.1 is the Organization-Defined Parameter (ODP): the scan frequency. Per the NIST discussion, non-signature-based detection includes heuristics and reputation-based technologies that provide controls against code for which signatures do not yet exist, and if malicious code cannot be detected by detection methods, organizations can rely on secure coding practices, configuration management and control, trusted procurement processes, and monitoring practices. You can read the requirement directly at NIST 800-171 R3, 03.14.02 (p. 64).
One (1) value sits inside this requirement. Depending on your contract, your organization may be permitted to define it. Organizations in the DIB subject to CMMC are not, because the DoD has defined it as policy.
The value below comes from Attachment A of the DoD Chief Information Officer (CIO) memorandum dated 10 April 2025 (signed David W. McKeown). The memo identifies each parameter by requirement sub-part, while NIST 800-171A R3 identifies the same parameter by ODP number. Both identifiers appear below so you can match your System Security Plan (SSP) language to either document.
The memo states that its values "will be updated as necessary," so confirm against the current version before writing them into policy.
NIST 800-171A R3 breaks 03.14.02 into seven (7) assessment objectives: one (1) Organization-Defined Parameter (ODP) and six (6) determination statements. These AOs are:
Detection (a[01]) and eradication (a[02]) are split into separate objectives, as are scheduled scans (c.01[01]) and real-time scans (c.01[02]). If you are a DoD contractor, the ODP is specified. Per the DoD-specified ODP value in ComplianceForge's NIST 800-171 R3 Transition Guide, the scan frequency (ODP[01]) is at least weekly. The full guidance on assessment methods and objects, is in NIST 800-171A R3, 03.14.02 (p. 84).
Examine: system and information integrity policy and procedures; configuration management policy and procedures; procedures for malicious code protection; records of malicious code protection updates; system design documentation; system configuration settings; scan results from malicious code protection mechanisms; record of actions initiated by malicious code protection mechanisms in response to malicious code detection; system audit records; system security plan.
Interview: personnel responsible for malicious code protection; personnel with system installation, configuration, or maintenance responsibilities; personnel with information security responsibilities; system administrators.
Test: processes for employing, updating, and configuring malicious code protection mechanisms; processes for addressing the detection of false positives and resulting potential impacts; mechanisms for supporting or implementing, employing, updating, and configuring malicious code protection mechanisms; mechanisms for supporting or implementing malicious code scanning and the execution of subsequent actions.
03.14.02 maps from NIST 800-171 R2 requirement 3.14.2 (provide protection from malicious code at designated locations within organizational systems), and it absorbs R2 requirement 3.14.4 (update malicious code protection mechanisms when new releases are available) and R2 requirement 3.14.5 (perform periodic scans of organizational systems and real-time scans of files from external sources), both of which R3 withdrew into this control:
Mapped against the seven (7) AOs, six (6) are direct (minimal effort) and one (1) is net new (significant effort). Almost everything carries forward, which makes sense given that R3 simply consolidated three R2 requirements into one. The single new obligation is configuring the mechanisms to block, quarantine, or otherwise act on a detection. Note also a scope shift in the wording: R2 spoke of "designated locations," while R3 specifies system entry and exit points.
Source Control in NIST 800-53 R5:
Secure Controls Framework (SCF) Crosswalk
Organizations running a single control set across multiple frameworks can satisfy 03.14.02 through the following SCF controls:
The crosswalks from NIST 800-171 R3 and NIST 800-171A R3 to the SCF are available at no cost through the SCF Set Theory Relationship Mapping (STRM): https://securecontrolsframework.com/start-here/set-theory-relationship-mapping-strm. The STRM also carries the relationship type for each mapping (Equal, Subset Of, Intersects With), which tells you whether an SCF control fully satisfies the requirement or only part of it. Mapping above taken from SCF 2026.3.
The following are issues teams may encounter rather than certainties. They are about configured response and scan coverage, each of which needs documented evidence of due diligence and due care such as policies, standards, procedures, and configuration screenshots:
Reasonable objective evidence for an assessment is often subjective. The following examples of evidence to address NIST 800-171 R3 03.14.02 are sourced from the SCF Evidence Request List (ERL), available at https://securecontrolsframework.com/free-content/scf-download. These ERL artifacts are mapped to NIST 800-171 R3 03.14.02 through SCF controls. They establish a starting point for discussions on what an organization needs to have for evidence of due diligence and due care to withstand external scrutiny by an assessor or regulator.
Alongside these, keep the System Security Plan (SSP) narrative for 03.14.02 recording the ODP values you adopted.
With six (6) AOs mapping directly and one net new, 03.14.02 is a moderate lift where the configured response is usually the gap. A realistic sequence:
What value does the DoD require for the organization-defined parameter in NIST 800-171 R3 03.14.02? R3 leaves the value to the organization. For the DIB, the DoD set it in the 10 April 2025 memorandum under ODP identifier 03.14.02.c.01: at least weekly.
How many assessment objectives does NIST 800-171 R3 03.14.02 have? NIST 800-171A R3 breaks 03.14.02 into seven (7) assessment objectives: one (1) Organization-Defined Parameters (ODPs) and six (6) determination statements. An assessor works through each one separately, so each needs its own evidence.
Which NIST 800-53 R5 control does NIST 800-171 R3 03.14.02 come from? SI-03.
Where does NIST 800-171 R3 03.14.02 sit in the NIST 800-171 R3 Kill Chain? Phase 15, Attack Surface Management (ASM). The Kill Chain is a phased model for sequencing R3 implementation, and it assigns this requirement to that phase.
03.14.02 Malicious Code Protection implements anti-malware at system entry and exit points to detect and eradicate malicious code, keeps it updated under change control, and configures it to scan on a defined frequency, scan files in real time, and act on detections. It maps from R2 3.14.2 and absorbs R2 3.14.4 and 3.14.5, with six of seven (7) objectives transitioning directly. The one net-new piece is the configured response. The recurring problem is running in alert-only mode. Set the scan frequency (for DoD, at least weekly), cover both scheduled and real-time scanning, and configure the tool to block or quarantine what it finds.
Authoritative sources:
Authoritative sources:
This guide reproduces U.S. Government text from NIST 800-171 R3 and NIST 800-171A R3 and references the DoD ODP memorandum of 10 April 2025. It is educational, not legal or assessment advice. Last reviewed: 2026-09-22.
