- Choose the designated locations deliberately — endpoints, email, web gateways, file-transfer points — and record why those are the entry and execution points that matter in your architecture.
- Modern endpoint detection platforms update engines and signatures automatically; the verification work is coverage, not update mechanics — servers without sensors, appliances, and unmanaged devices are where this requirement quietly fails.
- Define what happens on detection — quarantine, block, alert — and confirm the alert actually reaches a person who acts on it.
03.14.02OFFICIAL TITLEPENDING NIST SME REVIEW
03.14.02 — Malicious Code Protection
03.14 System and Information Integrity · NIST SP 800-171 Rev. 3
Independent summary of the official requirement
Implement malicious code protection at designated locations within the system, update protection mechanisms as new releases become available, perform periodic scans of the system and real-time scans of files from external sources, and take defined actions in response to detections.
Rev. 3 requirement text is multi-part and parameterized with organization-defined values, so this site summarizes rather than reproduces it. The summary is independent — read the official publication for the binding wording.
NIST SP 800-171 Rev. 3 — Protecting CUI in Nonfederal Systems ↗NIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI ↗Independent interpretation
What this requirement is after
Anti-malware that exists is not the requirement — anti-malware that is positioned where code enters and executes, kept current, actually scanning, and wired to a response is. The consolidation matters: deployment, updating, and scanning were three separate Rev. 2 line items and are now one obligation assessed together, so a current engine with a lapsed scan schedule is a finding, not a partial credit.
Across revisions
Absorbs Rev. 2's 3.14.4 (protection-mechanism updates) and 3.14.5 (periodic and real-time scanning) into a single Malicious Code Protection requirement.
Mapped practices
Brilliant at the Basics practices that support this requirement
No practice maps to this requirement — deliberately.
The campaign’s twenty practices are a priority list, not a control catalog, and none of them works this requirement’s substance directly. It still applies to you if it is in your contract’s scope: address it through your own implementation and the related artifacts below, and treat the absence of a mapping here as honesty, not permission to skip it.
Doing the work
Implementation considerations and evidence
- Deployment coverage reports reconciled against the asset inventory
- Platform configuration showing update behavior, scan schedules, and on-access scanning of files from external sources
- Detection and response records for a sampled period
Artifacts
Templates and worksheets with a mapped relationship
No artifact in the library names this requirement yet. The library index groups everything by category and practice.
The other revision
Where this came from in Rev. 2
Provenance
Sources and review status
| Primary sources | NIST SP 800-171 Rev. 3 — Protecting CUI in Nonfederal Systems · NIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI |
|---|---|
| Review status | Pending NIST SME review |
| Content version | 1.0 |
| Updated |