MA-3(2): Inspect Media

To meet the ma-3(2): inspect media requirement, you must scan any media that contains diagnostic or test programs for malicious code before that media is introduced to your system—including USB drives, CDs/DVDs, external drives, and downloaded ISO images. Operationalize it by defining what “maintenance media” is in your environment, enforcing pre-use scanning, and retaining scan evidence tied to each maintenance event. ¹

Key takeaways:

• You need a pre-use inspection gate for diagnostic/test media used in maintenance activities. ¹
• Scope includes third-party field service and internal IT/OT support, not just IT admins.
• The audit pass/fail hinges on repeatable procedure + proof (logs, tickets, chain-of-custody), not policy text.

MA-3(2) sits in the Maintenance (MA) family and targets a specific, high-friction pathway for malware: tools and media brought in to diagnose, test, patch, or repair systems. The requirement is narrow by design. It does not ask you to “secure all removable media” in the abstract. It asks you to prevent a common operational failure mode: a diagnostic toolkit, bootable ISO, firmware updater, or test script introduced during maintenance that carries malicious code.

If you run federal information systems, or you are a contractor handling federal data in systems assessed against NIST SP 800-53, you should treat this as a control that must work under pressure. Maintenance often happens during outages, escalations, or site visits, exactly when teams bypass normal change and security workflows.

The fastest way to implement MA-3(2) is to build a simple rule: no maintenance media touches production unless it is scanned on a controlled scanning station or scanned via an approved workflow, and the scan result is recorded in the maintenance record. The rest of this page gives you a requirement-level playbook to make that rule real and auditable. ²

Regulatory text

Requirement (verbatim): “Check media containing diagnostic and test programs for malicious code before the media are used in the system.” ¹

What the operator must do:

1. Identify media that contains diagnostic and test programs (for example, bootable recovery media, OEM diagnostics, firmware tools, vendor troubleshooting toolkits).
2. Perform a malicious code check before the media is used on the system.
3. Ensure the check is part of the maintenance workflow, including third-party maintenance where applicable. ¹

Plain-English interpretation (what auditors expect you to mean)

• “Media” includes physical removable media (USB, external drives, CDs/DVDs) and, in practice, downloadable images that become media (ISOs written to a USB drive, recovery partitions mounted from downloaded content).
• “Containing diagnostic and test programs” is the key scoping phrase. Focus on maintenance toolchains: hardware diagnostics, endpoint repair tools, privileged troubleshooting scripts, firmware/BIOS update packages, and vendor “field engineer” kits.
• “Check…for malicious code” means malware scanning with a tool and signatures/engines you approve. In higher-assurance environments, teams also validate hashes or signatures for vendor-provided images, but the minimum here is malicious code inspection prior to use. ¹

Who it applies to (entity and operational context)

Entity scope

• Federal information systems assessed against NIST SP 800-53. ²
• Contractor systems handling federal data where NIST SP 800-53 controls are flowed down contractually. ²

Operational scope

• IT operations and endpoint/server teams performing break/fix or diagnostics.
• Data center and site reliability teams using boot media during restores.
• OT/ICS support teams using vendor diagnostics on engineering workstations or HMIs (where NIST 800-53 is adopted for the environment).
• Third parties doing maintenance (OEMs, managed service providers, field service engineers). Your process must either cover them directly or force them into your gate.

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

1) Define “maintenance media” in your procedures (tight scope, no ambiguity)

Create a short definition list your teams can follow. Include:

• Bootable diagnostic media (WinPE, Linux live images, recovery ISOs)
• OEM diagnostic suites (hardware tests, RAID controller tools)
• Firmware/driver update media used during maintenance windows
• Vendor troubleshooting kits (log collectors, remote support tool packages)
• Test tools used to validate repairs

Exclude items already governed elsewhere only if you can explain the boundary cleanly (for example, “standard end-user USB storage” is governed under removable media controls; MA-3(2) focuses on diagnostic/test media). ¹

2) Establish an inspection method that works during outages

Pick one primary inspection workflow and one fallback.

Common primary workflow (works in most enterprises):

• A dedicated scanning workstation (or hardened VM) with:
  • Endpoint protection/AV enabled
  • Ability to scan removable media and archives
  • Logging enabled (central log or locally retained scan reports)
• Rule: maintenance media must be scanned on this station and tagged “scanned” before use.

Fallback workflow (for urgent situations):

• If scanning station is unavailable, allow scanning on a designated admin endpoint with equivalent controls and logging.
• Require a post-event review to confirm evidence was captured and attached to the maintenance record.

The examiner question you’re trying to answer is simple: “How do you know the tool media was scanned before it touched the system?” ¹

3) Make it enforceable in the maintenance process (not optional guidance)

Embed MA-3(2) into:

• Maintenance tickets: add a required checkbox/field (“Maintenance media scanned? Evidence attached?”).
• Runbooks: add a step immediately before “insert media / mount image / run tool.”
• Third-party access workflows: if a third party arrives with media, your onsite staff scans it first, or the third party uses your provided “clean media.”

If you use Daydream to track control-to-evidence mapping, tie MA-3(2) to the maintenance workflow and specify recurring evidence artifacts (ticket fields, scan logs, exception approvals) so the control is assessable without a scramble. ¹

4) Handle vendor-provided “known good” media without creating a blind spot

Vendors often claim their toolkit is safe. Treat that as useful context, not a substitute for your inspection step. Practical options:

• Maintain an internal library of approved tool images, scanned on intake and re-scanned on update.
• For each new version, scan again before first use and record the scan output.

5) Create an exception path that doesn’t become the default

You will have edge cases (air-gapped environments, constrained OT hosts, emergency restores). Build a documented exception workflow:

• Who can approve
• What compensating steps apply (for example, scan on a separate enclave host before crossing zones)
• What evidence is required after the fact

Required evidence and artifacts to retain

Keep evidence that proves pre-use scanning happened and ties to a specific maintenance event.

Minimum audit-ready evidence set

• Procedure/runbook for inspecting diagnostic/test media (version controlled)
• Maintenance records (ticket or change record) showing:
  • Media type/source (USB, ISO, vendor kit)
  • Date/time of scan
  • Tool used to scan and result
  • Approver (if exception)
• Scan output:
  • AV scan log, report screenshot, or exported result
  • Centralized security tooling log entry (if available)
• Third-party maintenance terms (contract language or SOP) requiring compliance with your media inspection gate

Tip: auditors like “traceability.” One ticket should let them trace from maintenance action → media introduced → scan proof → outcome.

Common exam/audit questions and hangups

• “What counts as diagnostic and test programs?” Expect to justify your scope statement and show examples.
• “Show me three recent maintenance events where media was used.” They will sample tickets and ask for scan evidence.
• “How do you control third-party field engineers?” They will look for a gate that doesn’t rely on trust.
• “What happens during an emergency?” They will expect an exception process with approvals and post-event evidence.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Fix
Policy says “scan media,” but no workflow step	No operational trigger, no proof	Put a required scan step in maintenance runbooks and ticket templates
Scans happen “sometimes” on whichever laptop is nearby	Inconsistent tooling and missing logs	Standardize a scanning station or designated scanning endpoints
Third parties bring their own media and bypass your controls	You can’t evidence inspection	Require scanning on arrival or provide controlled “clean” media
Evidence is screenshots with no tie to a ticket	Hard to sample and verify	Attach scan output to the maintenance record and record date/time and media identifier
Exception process exists but isn’t used consistently	Drift becomes normal	Require approval + after-action documentation for every exception

Risk implications (why this requirement exists)

Diagnostic and test tools typically run with elevated privileges and broad system access. A malicious toolchain can:

• introduce malware during a sensitive maintenance window,
• bypass normal endpoint controls (bootable media),
• spread laterally if used across multiple systems.

MA-3(2) is a practical control to reduce that pathway by adding a pre-use inspection gate. ¹

Practical 30/60/90-day execution plan

First 30 days (stand up the control skeleton)

• Name a control owner (IT Ops, SecOps, or Infrastructure) and a backup.
• Write the one-page procedure: what media is in scope, where scans happen, what evidence is required.
• Update maintenance ticket templates to require scan attestation and evidence attachment.
• Identify where scan logs will live (central logging or ticket attachments). ¹

Days 31–60 (make it real in operations)

• Build or designate the scanning workstation/VM and document its configuration.
• Train internal teams and onsite hands on the workflow, including “third-party shows up with a USB” scenarios.
• Pilot the process on a subset of maintenance types (endpoint repair, server firmware updates) and fix friction points.

Days 61–90 (prove it works and close gaps)

• Run an internal sample test: pull recent maintenance events involving media and verify evidence completeness.
• Add third-party language to maintenance SOWs/SOPs and site access procedures.
• Formalize exception handling and review any exceptions for patterns that require process changes.
• In Daydream (or your GRC system), map MA-3(2) to the procedure, owner, and recurring evidence artifacts so assessments become a retrieval exercise, not a hunt. ¹

Frequently Asked Questions

Does MA-3(2) apply to downloaded diagnostic tools, not just physical USB drives?

Yes if the downloaded content becomes “media” used in the system (for example, an ISO written to a USB drive or mounted to run diagnostics). Treat intake and first use as the point where scanning must be evidenced. ¹

If the vendor provides a checksum or says the tool is signed, can we skip malware scanning?

The requirement text calls for checking for malicious code before use, so treat signature or checksum validation as additive assurance, not a replacement. If you use both, document both steps in the runbook. ¹

What evidence is strongest for auditors: screenshots or logs?

Logs tied to a ticket are easier to validate and harder to dispute. If you must use screenshots, include the system date/time, media identifier, and attach them to the maintenance record.

How do we handle air-gapped or high-restriction environments where scanning tools can’t be installed?

Scan in a controlled staging enclave before the media crosses into the restricted zone, and document chain-of-custody from scan to use. Use an exception workflow only if staging is impossible and record compensating steps. ¹

Does this apply to third-party maintenance teams who only connect over remote session tools?

It applies when they introduce diagnostic/test programs via media into your environment. If they transfer toolkits through remote file transfer, treat that transfer as “media use” and require scanning before execution.

What’s the cleanest way to operationalize MA-3(2) across many sites?

Standardize the gate: a defined scanning endpoint per site (or a centralized intake process for mailed media), plus the same ticket evidence fields everywhere. Centralize evidence collection so sampling works across locations.

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5