CMMC Level 2 Practice 3.7.4: Check media containing diagnostic and test programs for malicious code before the media are

CMMC Level 2 assessments often expose a gap that has nothing to do with your endpoint protection stack and everything to do with “how things really happen” in IT and OT support: technicians show up with a bootable USB, a hardware vendor ships a recovery image, or engineering keeps an old diagnostic ISO “because it still works.” Practice 3.7.4 forces discipline around that specific risk path.

The requirement is narrow but operationally tricky: it targets media containing diagnostic and test programs and expects you to check that media for malicious code before the media are used. That means you need an intake workflow that works for real teams under time pressure, and you need evidence that proves it happens consistently, not only when someone remembers.

This page translates the requirement into an implementable control you can put in front of an assessor. It includes a practical procedure, decision points (when scanning is possible vs. not), the minimum artifacts to retain, and the questions assessors ask when they suspect your process exists only on paper. (NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance; 32 CFR Part 170)

Regulatory text

Requirement (mapped): “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.7.4 (Check media containing diagnostic and test programs for malicious code before the media are).” (NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance; 32 CFR Part 170)

Operator meaning: Before any removable or portable media that includes diagnostic or test tooling is introduced into your environment (inserted, mounted, executed, or used to boot a system), you must perform a malicious code check using an approved method, and you must be able to prove you did it.

Plain-English interpretation

You are preventing a common infection path: “tool media” that bypasses normal software delivery controls. This includes:

• USB drives used for troubleshooting, firmware updates, or field diagnostics
• Bootable recovery media (USB/DVD/ISO) with vendor tools
• Portable drives carrying test harnesses, scripts, or diagnostic executables
• Media used by third parties performing support (onsite or remote “ship-a-stick”)

The practice does not require you to scan every piece of media for every purpose in the universe. It requires that when the media contains diagnostic and test programs, you check it for malware before use. Your documentation should reflect this scoping clearly so you do not overpromise and then fail your own policy.

Who it applies to

Entity scope

• Defense contractors and subcontractors handling Controlled Unclassified Information (CUI) that must achieve CMMC Level 2. (32 CFR Part 170; DoD CMMC Program Guidance)

Operational scope (where it shows up)

• IT helpdesk and desktop support (break/fix toolkits, boot media)
• Network/server teams (driver packs, vendor “support” media)
• OT/industrial environments and labs (test rigs, specialized diagnostics)
• Field service and depot repair (portable tool media moving between sites)
• Third parties performing maintenance (OEMs, MSPs, integrators)

System scope

Apply it wherever tool media could touch CUI systems or the environment that supports them. If you segment networks, make the boundary explicit: the requirement still applies at the point of introduction into the in-scope environment.

What you actually need to do (step-by-step)

1) Define “diagnostic and test program media” in your standard

Write a short definition in your procedure so teams can recognize it. Include examples: “bootable USB with recovery utilities,” “vendor diagnostic suite on DVD,” “USB with test scripts and portable executables.”

Control outcome: Staff can classify media quickly and route it into the right intake path.

2) Establish an approved intake path (“scan-before-use”)

Create one or more approved scanning stations or workflows:

• Dedicated scanning workstation (preferred): hardened endpoint with updated signatures, no auto-run, logging enabled.
• EDR/AV-enabled staging host in a quarantine VLAN: mount media, scan, then transfer approved content to a managed repository.
• Virtual sandbox for ISO/boot images: scan extracted contents, validate hashes if available.

Document where scanning occurs, who can perform it, and what “pass” and “fail” mean.

3) Require malware scanning before any of these actions

Make “before the media are used” operational by listing prohibited actions until scan completion, such as:

• Inserting into an in-scope workstation/server
• Booting a system from the media
• Executing any program from the media
• Copying files from the media into the environment

Then specify the required check:

• Run an on-demand scan of the full media (or full file set after mounting/extraction).
• Ensure signatures/engines are up to date at time of scan.
• Record results.

4) Add controls for third-party-provided tool media

Tool media often comes from OEM support or integrators. Require:

• Advance notice and identification of media content/purpose
• A statement that the media is for diagnostics/testing
• Your organization performs the scan regardless of third-party assurances

Contract terms help, but assessors will still look for your internal control operation.

5) Handle “can’t scan” scenarios with explicit exception handling

Some bootable media or proprietary formats are hard to scan. Build an exception path:

• Approval by an accountable role (IT/security)
• Compensating controls (examples: use only on isolated, non-networked systems; use a dedicated sacrificial device; restrict to a lab segment; capture forensic image; monitor closely with EDR where feasible)
• Post-use actions (wipe/reimage the target system if appropriate; retain chain-of-custody notes)

Keep exceptions rare and auditable. The risk in assessments is not that exceptions exist; it is that they are informal.

6) Enforce with technical and procedural guardrails

Practical guardrails that reduce reliance on memory:

• Disable autorun and restrict removable media execution on managed endpoints (where feasible)
• Block USB mass storage by default and allow only managed/encrypted devices (if this fits your environment)
• Require that diagnostic tools be staged in a managed internal repository after scanning; forbid “run directly from USB” in procedure

Tie this practice into your broader malicious code protection program so it’s not a one-off. (NIST SP 800-171 Rev. 2)

7) Make evidence capture routine

Your procedure should state how evidence is recorded each time. If your AV/EDR supports centralized logs, configure retention and easy retrieval. If not, define a standardized screenshot or export method plus where it is stored.

Daydream tip (earned mention): Many teams pass the technical control but fail the assessment because evidence is scattered across tickets, screenshots, and local logs. Daydream can act as the control library and evidence binder so each scan record, exception, and procedure maps cleanly to CMMC Level 2 Practice 3.7.4 and is ready for assessor sampling.

Required evidence and artifacts to retain

Keep artifacts that prove both design (you planned the control) and operation (you do it).

Minimum evidence set (assessment-ready)

• Policy/procedure for handling diagnostic/test program media, including definitions, workflow, roles, and exceptions. (NIST SP 800-171 Rev. 2)
• Inventory or register of approved diagnostic/test media (optional but helpful), or at least an intake log showing date, media identifier, source, purpose, and disposition.
• Scan records (central logs, exports, or screenshots) showing:
  • media identifier/path
  • scan engine/tool
  • date/time
  • result (clean/quarantined/blocked)
• Exception approvals with compensating controls and closure notes.
• Training or work instructions for IT/support staff and any team that commonly uses such media.
• Ticket linkage (recommended): intake log references the service ticket/change record that justified use.

Evidence quality checklist

• Can you produce a sample set on request without hunting on endpoints?
• Do scan records show signatures were current (or at least show a timestamp that you can correlate to update status in your tooling)?
• Do exceptions show a real decision and mitigation, not “approved” with no detail?

Common exam/audit questions and hangups

Assessors typically probe consistency and scope boundaries.

Questions you should be ready to answer:

• “What counts as diagnostic/test media here, and who decides?” (NIST SP 800-171 Rev. 2)
• “Show me the procedure that requires scanning before use.” (NIST SP 800-171 Rev. 2)
• “Give me three recent examples of diagnostic media used and the scan evidence.”
• “How do you handle vendor-provided boot media that can’t be scanned normally?”
• “How do you ensure technicians follow this during outages or urgent troubleshooting?”
• “Where are logs stored, and how long are they retrievable?”

Hangups that cause findings:

• You scan “sometimes,” but there is no consistent intake workflow.
• Your AV is deployed, but you cannot prove an on-demand scan occurred before use.
• The procedure says “scan all removable media,” but operations can’t support it and exceptions are undocumented.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Fix
Relying on “EDR is on endpoints” as proof	The requirement is about checking media before use, not only detecting after	Add a defined pre-use scan step with records
No definition of “diagnostic and test programs”	Teams don’t know what falls into scope	Include examples and a simple decision tree
Scanning happens on the target system after insertion	“Before the media are used” can be interpreted as before execution/boot; assessors may still see this as weak	Prefer a scanning station or quarantine host before introduction into in-scope endpoints
Exceptions are informal	High-risk path becomes ungoverned	Create an exception form and require compensating controls
Evidence is not centralized	You cannot satisfy sampling	Store scan outputs in a controlled location and tie to tickets

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific practice, so treat enforcement discussion as general program risk rather than case-based.

Risk-wise, diagnostic/test media is a classic ingress path because it frequently:

• originates outside normal software procurement,
• runs with elevated privileges,
• is used during incidents when controls get bypassed.

If you cannot show a repeatable scan-and-record workflow, you create two problems: higher likelihood of malware introduction and assessment failure due to missing objective evidence. The CMMC program framework and mapping to NIST SP 800-171 Rev. 2 place this squarely in expected hygiene for CUI environments. (DoD CMMC Program Guidance; NIST SP 800-171 Rev. 2; 32 CFR Part 170)

Practical execution plan (30/60/90-day)

First 30 days (stabilize the intake path)

• Assign an owner for removable media/tool media handling (IT + security).
• Publish a one-page procedure: definition, scan-before-use rule, and where scanning occurs. (NIST SP 800-171 Rev. 2)
• Stand up a scanning station or quarantine workflow and test it with common tool media (USB, ISO).
• Create a simple intake log template and require it for any diagnostic/test media event.

By 60 days (make it repeatable and auditable)

• Integrate the intake log with your ticketing workflow (service request/change).
• Configure centralized logging/retention for scan results where possible.
• Train helpdesk/field techs and any groups that commonly use diagnostic media.
• Implement an exception workflow with required compensating controls and approvals.

By 90 days (tighten controls and reduce exceptions)

• Reduce “run directly from USB” by moving approved tools into a managed internal repository after scanning.
• Add technical restrictions where feasible (USB controls, execution controls) aligned to your environment.
• Run a mini-assessment: sample recent diagnostic media events and verify evidence is complete end-to-end.
• If you use Daydream, map this practice to your control narrative and set recurring evidence tasks so evidence stays current for assessments.

Frequently Asked Questions

Does this mean we must scan every USB drive before anyone plugs it in?

The practice targets media containing diagnostic and test programs. Define that scope clearly, then enforce scan-before-use for that category and retain evidence. (NIST SP 800-171 Rev. 2)

What about vendor bootable recovery media that our AV can’t read?

Document an exception workflow with approval and compensating controls, such as using an isolated device or segmented environment and restricting network access during use. Keep the approval and the mitigation steps as evidence. (NIST SP 800-171 Rev. 2)

Is it acceptable to scan the media after it’s inserted but before running anything?

Many teams implement it that way, but you need to be able to show the check occurred before use of the programs on the media. A safer pattern is a scanning station or quarantine host that avoids introducing unknown media to in-scope endpoints.

Do we need a dedicated “media scanning workstation”?

Not strictly, but you need a controlled, repeatable method that produces retrievable records. A dedicated station reduces operational variance and makes evidence collection easier.

What evidence will an assessor ask for first?

Expect requests for the procedure, a handful of recent scan records tied to real tickets, and any documented exceptions with compensating controls. (NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance)

How do we handle third-party technicians who arrive with their own diagnostic USB?

Require they route media through your scan process before connecting it to your environment, and record the intake and results. Add this expectation to third-party access and onsite support procedures. (NIST SP 800-171 Rev. 2)