MA.L2-3.7.4 Media inspection: requirements and evidence

What MA.L2-3.7.4 media inspection asks you to prove

If you have a vendor troubleshooting USB drive, a diagnostic disc or a test utility and want to plug it into a system that handles CUI, MA.L2-3.7.4 requires one specific check before that media touches the system: it must be inspected for malicious code first. The requirement is not a standing monitoring duty. It is a gate at the point of use, and it applies to any media carrying diagnostic or test programs, including the tools a vendor technician brings on site. The assessor's question is simple: can you show that this media was checked, by what method, and by whom, before it ran on an in-scope system?

The risk is real because these tools are built to run with high privilege. A diagnostic program often needs administrator or kernel-level access to do its job, and the people carrying it are usually trusted vendors or internal technicians, so the media tends to skip the scanning that a file downloaded by a staff member would receive. The CMMC Assessment Guide treats diagnostic files from a vendor with the same scrutiny as any file a staff member downloads, which is the practical standard to design around. The difficulty is that this media often sits outside normal software intake. It arrives in a technician's bag, on a loaner laptop or as a disc from a field service call, so the process has to reach beyond your standard download workflow.

Because MA.L2-3.7.4 is worth 3 points in the CMMC Scoring Methodology, it must be MET. It cannot go on a POA&M, so a missing inspection process can prevent Conditional or Final Level 2 status. Confirm with your assessor how they expect the evidence to look, but plan for a written procedure that names the scanning tools and the approved machine used for inspection, a log of each media item checked with its date and result, and a rule that unchecked media may not be connected to CUI systems. Test the process before an assessment by running a sample item through it and keeping the record. Records must be in final form, not drafts.

Which media and diagnostic tools fall under MA.L2-3.7.4 media inspection

MA.L2-3.7.4 applies to any media carrying diagnostic or test programs that will touch a system handling CUI, so scoping starts with where those programs arrive. The cards below separate the common media and tools, the boundary questions that change the work, and the teams that usually own each item.

Removable media carrying vendor tools

USB drives, optical discs and ISO images that ship with diagnostic software are the most common case. Each one is media containing diagnostic and test programs, so it must be checked for malicious code before it is inserted into a system that processes, stores or transmits CUI. Record which disc or drive was checked, the scan result and who checked it. Ask the vendor for a published hash so you can confirm the image was not altered in transit.

Downloaded vendor utilities and firmware updaters

Diagnostic utilities and firmware updaters pulled from a vendor website count as diagnostic programs even when they arrive as a single executable. The CMMC Assessment Guide treats diagnostic files from a vendor with the same scrutiny as any file a staff member downloads. Define a documented path for these files: download to a staging host, scan, verify the signature, then move the file to the maintenance workstation. Field engineers often skip this step, so the procedure should be written for them.

Test harnesses brought on site by contractors

Outside technicians often arrive with their own laptops, test harnesses or licensed diagnostic suites. Those media and tools are maintenance media entering your environment, so the same inspection step applies before anything connects to a CUI system. Put the requirement into the statement of work or site access rules, and decide whether the contractor scans on arrival or your team scans the media before use. Keep the record with the maintenance records for the visit.

Tools for OT and test equipment handling CUI

Test benches, programmable logic tools and instrument controllers that store or process CUI fall within the requirement, even when they sit outside the IT network. Their vendor software is often installed from media that nobody has scanned. Confirm with each equipment vendor which installation media and update packages are supplied, and whether the vendor can provide a checksum. If an asset cannot be scanned, document that limitation and the compensating control in the system security plan.

Tools that never touch CUI systems

The boundary question turns on whether the tool is ever used on a system that processes, stores or transmits CUI. A utility used only on a standalone calibration rig with no CUI, no network path to the CUI enclave and no transfer of data from it may fall outside the requirement. Document that boundary in the system security plan, and tie it to physical or logical separation you can show an assessor. Any tool that moves between the two environments on the same media is in scope.

Ownership across field service, IT and lab teams

Field service usually carries vendor media on laptops and removable drives. IT owns the scanning tools, the staging host and the maintenance records. Lab and test engineering often hold the instrument software and its installation discs. Assign one owner for the inspection procedure and name the teams that must follow it, because a gap usually sits at a handoff between them. Review the owner list whenever a new vendor or site is added.

How an assessor tests MA.L2-3.7.4 media inspection

This table compares what an assessor examines for each object named in NIST SP 800-171A for requirement 3.7.4, what evidence to have ready, and where organizations usually fall short. Read each row as a question the assessor will ask, then check whether your records answer it in final form. The main takeaway is that the requirement is judged on the process and its records, so a single scan result alone will not satisfy it.

Assessment object	What the assessor examines	Evidence requested	Common findings
Maintenance procedures	Whether a written procedure requires diagnostic and test media to be checked for malicious code before first use on a system that processes, stores or transmits CUI	Approved, current procedure with an owner, review date and scope naming the CUI systems it covers	Procedure exists but omits vendor-supplied media or never mentions CUI systems
Maintenance tools and their documentation	Inventory of diagnostic and test programs, vendor troubleshooting tools and their source, version and hash	Tool inventory, vendor documentation, and the hash or signature values recorded at intake	Tools run directly from a vendor USB stick or download with no inventory entry
Inspection process	Whether the scan or check is performed before the media touches a CUI system, and by whom	Intake checklist, scan logs or sandbox results showing the date and tool used before first use	Scanning is done after installation, or no one can show the check happened for a specific tool
Inspection mechanisms	Whether the anti-malware or file scanning mechanism is functional, current and able to scan the media type	Scanner configuration, signature update records, and a test result showing detection works	Scanner is installed on a workstation but not configured for removable or vendor media
Maintenance records	Whether each use of diagnostic media is traceable to an inspection result and an authorized person	Maintenance log entries linking the tool, the inspection result, the target system and the technician	Records show maintenance was performed but not that the media were inspected first
Exceptions and handling of failed inspections	Whether media that fail or cannot be checked are quarantined or rejected, and whether that decision is recorded	Quarantine log, escalation record and disposition of the media	No defined path for media that cannot be scanned, so technicians use them anyway
Consistency with system and information integrity practices	Whether the inspection aligns with the malicious code protection and file scanning practices in the Level 2 System and information integrity family	Cross-reference between the maintenance procedure and the malicious code protection and file scanning evidence	Maintenance procedure is written in isolation and not tied to the organization's malware controls
Vendor-supplied diagnostic files	Whether vendor diagnostic files receive the same scrutiny as any file a staff member downloads	Vendor file intake records, provenance checks and the same scan evidence used for other downloads	Vendor files are treated as trusted because the vendor is established

How to implement media inspection step by step

This sequence turns MA.L2-3.7.4 into a repeatable routine: every diagnostic and test medium is known, checked at a gate, scanned and staged before use, and recorded so an assessor can trace each inspection back to a named medium and a named person.

Inventory diagnostic and test media in use
Build a list of every diagnostic and test medium that touches systems handling CUI, including vendor troubleshooting tools, diagnostic disks, firmware update packages, test scripts and utility images. For each item, record the vendor, version, source, the systems it is used on and the person who owns it. The output is a maintained inventory that the assessor can compare against maintenance records to confirm nothing is used outside the process.
Define an intake procedure with a gate
Write a short procedure that says how new media arrive, who may request them, and what must happen before first use. The gate is a documented checkpoint: no medium moves to a CUI system until the inspection steps are complete and a named reviewer has approved it. The output is the approved procedure with its gate, plus the approval record for each item in the inventory.
Verify integrity and scan for malicious code
Obtain each medium from the vendor's published source and compare its hash with the value the vendor publishes, where one exists. Then scan the contents with anti-malware tooling your organization selects and confirms in its own environment. Where no vendor hash is published, record that fact and the alternative control you used. The output is a scan and hash record for each medium that shows what was checked, when, and with which tool version.
Isolate and test media in a staging system
Run the medium first on a staging system that is separated from production CUI systems and has no access to them. Observe its behavior, network connections and file changes during the test, and remove it if anything unexpected occurs. Where your monitoring stack can help, such as endpoint query or event collection tools, you can use them here to watch for new processes, network connections or file changes. The output is a staging test report that states the observed behavior and the decision to approve or reject the medium.
Record each inspection in a log
Create one entry for each inspection that names the medium, its version and hash, the scan result, the staging test result, the reviewer, the approver and the date. Keep the log with your maintenance records and store it where access is controlled. The output is a complete inspection log that lets an assessor pick any maintenance session and trace the medium used back to a documented inspection.
Review the procedure periodically
Set a review cycle, confirm it in your own governance documents, and check the inventory, gate criteria and tooling against current vendor releases and your system changes. Update the procedure when tools or vendors change and retire media that are no longer used. The output is a dated review record with the changes made, which shows the procedure is maintained rather than written once.

Evidence that proves MA.L2-3.7.4 media inspection is met

An assessor checks MA.L2-3.7.4 by following media from the moment a vendor tool or diagnostic disk arrives to the moment it is used on a system that handles CUI. The artifacts below form that trail, and each one should link to the others by item, date and person. Every artifact must be in final form, because a draft procedure or an unsigned log does not count toward a MET result.

Written media inspection procedure

This is the approved procedure that states which media are covered, who inspects them, which tools perform the check, and what happens when a check fails. It should name the malicious code checks in use and state that diagnostic and test programs are inspected before first use on any system that processes, stores or transmits CUI. Assessors compare the procedure with what staff actually do, so confirm it has an owner, an approval date and a revision history. Its final, approved version is what counts.

Inventory of diagnostic and test media

Maintain a list of every diagnostic, troubleshooting and test media item that vendors or staff bring into the environment, including USB sticks, ISO images, firmware update packages and vendor laptops that carry tools. Each entry should record the source, version, hash where available, the systems it is intended for and its current status. Without this inventory, an assessor cannot confirm that all covered media were inspected, so treat missing entries as a finding.

Inspection records for each item

Each inspection needs a record showing who performed it, when, which checks ran, and the result. A record that only says "scanned" will not satisfy an assessor who wants to see the process and mechanisms in operation. Keep the record tied to the inventory entry so one item can be traced from arrival to approval for use. Confirm that the person who signs the record is the person authorized to do the inspection under your procedure.

Scanner and hash output

Retain the raw output from the malicious code scanner and the file hashes computed before use. The hash lets you show that the media used on the maintenance system matches the media that was inspected, which closes the gap between checking a file and running it. Store the scanner version and signature date alongside the output, since an assessor may ask whether the tool was current when the check ran. Confirm your scanner's update and reporting behavior in its own documentation.

Quarantine and exception logs

When media fail inspection or a vendor requests an exception, record the quarantine action, the reviewer, the decision and the reason. These logs show that the process has teeth: a flagged file was stopped, not used. Exceptions should be time-limited, approved in writing and reviewed before the next maintenance window. An empty quarantine log in a busy environment can raise questions, so confirm that your records genuinely reflect how the process works.

Maintenance records linking tools to work orders

Connect each inspected tool to the maintenance work order in which it was used, with the system name, date, technician and the inspection record number. This is the evidence that inspection happened before use and that the tool was not reused on another system without a fresh check. The MA.L2-3.7.1 maintenance records should carry the same identifiers, so an assessor can follow one thread across both requirements.

What meeting MA.L2-3.7.4 media inspection costs

This table breaks down the cost components of checking vendor diagnostic and test media for malicious code, who gets paid for each, whether it recurs, and what to ask for in a quote. Use it to separate tooling spend, which open-source software can reduce, from labor and evidence work, which it usually does not remove.

Cost component	One-time or recurring	What drives it up or down	What to ask for in a quote
Scanning tooling or licenses	Mostly recurring if commercial; near zero for open-source tools	Commercial anti-malware or sandbox licenses scale with seats or hosts. Open-source scanners remove license spend but still need installation and tuning.	Itemized license terms, renewal basis, and whether the open-source option is priced separately or included
Staging host hardware	One-time, with refresh costs later	Number of isolated staging hosts, OS variants, and whether the host is air-gapped. Reusing existing hardware lowers this.	Hardware list, isolation design, and who owns and refreshes the staging host
Engineering time to design the procedure and staging	One-time	Number of media types, vendor tools in use, and how many systems handle CUI. Clear procedure templates shorten this work.	Fixed-scope deliverables, named procedure documents, and acceptance criteria tied to MA.L2-3.7.4
Recurring inspection labor per medium	Recurring	Volume of vendor media, number of maintenance events, and whether checks run on a schedule or per request. Standardized checklists reduce time per item.	Expected labor per inspection, who performs it, and how exceptions are escalated
Evidence upkeep	Recurring	Frequency of maintenance events, record format, and retention rules. Logging inspections in a single system reduces rework.	Records retained per inspection, retention period, and where evidence is stored
External review or testing	Optional, one-time or periodic	Scope of the review, whether testers attempt to smuggle malicious code through vendor media, and how many procedures are tested.	Test scope in writing, tester qualifications, and deliverable format
Assessor time	Recurring at each assessment	Number of media records the assessor samples and how complete the evidence is in final form. Drafts do not count as MET.	Confirm with the assessor or certification body how they sample records and what they expect

Open-source tools that support media inspection evidence

None of the tools below inspects physical media or scans a USB drive or vendor disc on its own. They produce host-level records that help an organization show what a diagnostic tool did after it ran, and whether maintenance hosts carry known-vulnerable software. Confirm how each one fits your environment before you rely on it as evidence.

Osquery file hashes and processes

Osquery exposes running processes, loaded kernel modules, open network connections and file hashes as SQL tables, and its osqueryd daemon can schedule the same queries across a fleet of hosts. For MA.L2-3.7.4, a scheduled query can compare hashes of binaries in known tool directories against a recorded baseline taken before a vendor tool was run. Confirm that your baseline is captured and stored before maintenance begins, because a hash you did not record beforehand cannot prove a change.

Velociraptor hunts across systems

Velociraptor collects forensic artifacts defined in VQL from endpoints and runs hunts that collect one or more artifacts across a group of systems. Offline machines are scheduled to collect when they reconnect, and each hunt gets a notebook for analyzing the combined results. Use it to check whether a diagnostic tool left persistence, new services or unexpected files on every host it touched, not only the one it was run on. Confirm that the artifacts you define match what the vendor tool is known to write.

Wazuh vulnerability detection

Wazuh correlates the software inventory that each agent collects with its vulnerability repository, or with a locally hosted offline copy, to identify vulnerabilities in the operating system and installed applications of monitored endpoints. This matters for maintenance hosts, because the diagnostic laptops and jump systems that run vendor tools are often where unreviewed software accumulates. Confirm that agents are installed on those hosts and that the offline repository is current for your air-gapped or restricted networks.

Fleet software vulnerability matching

Fleet detects vulnerable software on enrolled hosts by matching installed software against sources including the NVD, OVAL definitions, Microsoft security bulletins, Amazon Linux advisories and OSV. On a maintenance workstation, this gives you a current list of installed applications with known vulnerabilities, which you can review before a vendor diagnostic package is installed and again after. Confirm which operating systems and advisory sources your hosts require, since coverage depends on the feeds your environment can reach.

Who owns media inspection and what can be outsourced

Your organization owns MA.L2-3.7.4 in full. The control asks that media containing diagnostic and test programs be checked for malicious code before they touch systems that process, store or transmit CUI, and the accountability for that check cannot be handed to a vendor or a consultant. Your security and IT leaders decide what the rule covers, who performs the check and what happens when a tool fails inspection.

Policy ownership: Your written procedure defines which media are in scope, including vendor troubleshooting tools, diagnostic images and test utilities, and who may approve their use.
Staging host ownership: Your team decides where the inspection happens, controls who can reach that host and keeps it isolated from production CUI systems.
Inspection records: Every scan, hash comparison and approval decision must be recorded by your staff, with dates, the media identifier and the reviewer's name.
Exception decisions: Only your authorized personnel can approve a tool that fails or cannot be inspected, and that decision belongs in the record.
Ongoing operation: Your team runs the procedure each time new media arrives, not only during an assessment.

Check that your procedure names an accountable owner and that someone outside the maintenance team can show the records for any tool used in the last review period.

Questions buyers ask about media inspection before hiring help

How much effort does media inspection take compared with other maintenance requirements?

MA.L2-3.7.4 is usually a narrow requirement in effort, but it is not a low-stakes one. The scope is limited to media that carry diagnostic and test programs, such as vendor troubleshooting tools, so most organizations have far fewer items to manage here than under the broader maintenance requirements. The scoring weight is 3 points, which is higher than MA.L2-3.7.1 and below MA.L2-3.7.2 and MA.L2-3.7.5, which are each worth 5 points. The effort concentrates in building a repeatable check, documenting it and keeping records that show the check happened before each use. Effort rises with the number of vendors, the number of tool media in circulation and how often maintenance is performed. Confirm the figures in the current scoring methodology in 32 CFR 170.24 before you plan your budget.

Can a small team handle media inspection in-house?

Yes, in most cases a small team can run this control in-house, provided someone owns the procedure and keeps the records. The work is a documented process: identify each piece of media that holds diagnostic or test programs, scan or analyze it for malicious code before it touches a system that processes, stores or transmits CUI, and record the result. Small teams usually struggle with consistency rather than technical skill, because the check is easy to skip when a technician is in a hurry. Assessors look for procedures, the tools and their documentation, and maintenance records, so the team needs to show that the check runs every time. Consider an outside implementation partner if you lack a documented maintenance process or staff who can build the scanning workflow.

What does media inspection need from our side before work starts?

The work needs a clear picture of your maintenance environment before anyone configures a tool. Expect to provide the following:

An inventory of every system that processes, stores or transmits CUI, and the maintenance tools that touch them
A list of vendors and service providers who supply diagnostic or test media, with named contacts for asking how their media are built and delivered
Staff time from the people who perform maintenance, so the procedure matches how work is actually done
Access to existing maintenance records and any prior inspection logs

Without these inputs, the procedure tends to cover only the media you remember. Ask any partner to confirm how they will collect and validate this information before quoting.

How long does it take to set up media inspection?

The setup time depends on the size of your maintenance inventory, how many vendors you deal with and whether a documented process already exists. Organizations with a mature change and maintenance process usually need less time to add a media check step than organizations that must write procedures from scratch. The first phase covers inventory and the procedure. The second covers tool selection, testing the scan workflow on a sample of media and training technicians. The third covers record keeping and a dry run before any assessment. No fixed duration applies to every environment. Ask a provider to break the timeline into these phases and to name the dependencies, such as access to vendor contacts or approval of the procedure.

Can media inspection go on a POA&M?

No. Because MA.L2-3.7.4 is worth 3 points, it cannot go on a plan of action and milestones under the CMMC rules. Under 32 CFR 170.21, only requirements worth 1 point may be carried on a POA&M, so this requirement must be fully MET before you can reach Conditional or Final Level 2 status. The rule exists to keep higher-weighted practices from being deferred. Plan for the control to be operating and evidenced before your assessment date, not as a future milestone. Confirm the POA&M eligibility rules against the current text of the rule, since the program timeline has changed.

What should we look for in a quote for media inspection help?

A useful quote should be tied to a written scope that lists the systems, media types, vendors and records covered. Ask the provider to separate the cost of the assessment-ready procedure from ongoing work, because the check repeats every time media is used. Look for these items:

A list of deliverables, such as the written procedure, tool configuration, technician training and record templates
Clear ownership of each step, showing what your staff must do and what the partner prepares
Recurring costs for tool licenses, updates and periodic review
An explicit statement that the partner prepares evidence but does not issue assessment results, since only an independent assessor can do that

DeployOpen works from a written scope and does not publish prices, so the quote will follow from the scope you agree to.

How DeployOpen scopes and prepares media inspection evidence

DeployOpen plans and implements the inspection process and tooling for MA.L2-3.7.4 Media inspection inside your own infrastructure, then prepares the records an assessor will examine. Your organization owns the control, and only an independent assessor can judge whether it is MET.

How we scope

Written scope lists every system that handles CUI and every maintenance tool or diagnostic media source in use.
Scope identifies which vendor troubleshooting tools, diagnostic images and test programs must pass inspection before use.
Scope confirms who in your organization approves media, who performs checks and where inspection records are kept.

How we build

We set up a documented inspection procedure for diagnostic and test media, with a clear point where media are held until checked.
Where your environment supports it, we configure malware scanning and file hash checks on inspection workstations and record results.
We test the procedure on sample media so you can confirm the steps work before an assessor reviews them.

How we hand over

You receive the written inspection procedure, the tool configuration, and a register of inspected media with dates and outcomes.
Handover includes a short walkthrough so your staff can repeat the inspection without us and show it to an assessor.
Deliverables are finalized documents, since assessors accept only evidence in final form, not drafts.

How we support

Ongoing support covering procedure updates and inspection records is available as a retainer after handover.
Ask any provider to confirm in writing which parts of the inspection evidence they prepare and which parts your assessor will test.
Confirm the current CMMC assessment schedule with your contracting officer, since implementation timing has changed.

MA.L2-3.7.4 Media inspection