CMMC Level 2 Practice 3.8.7: Control the use of removable media on system components

To meet cmmc level 2 practice 3.8.7: control the use of removable media on system components requirement, you must define and enforce rules for when removable media (USB drives, external HDDs, SD cards) can connect to systems that process CUI, then prove the control works with technical settings, approvals, and logs. Your objective is to reduce malware and data-exfiltration paths tied to portable storage. ¹

Key takeaways:

• You need both policy (what’s allowed) and technical enforcement (how it’s blocked or controlled) for removable media. ¹
• Scope matters: apply controls to system components in the CUI environment, including endpoints and servers where removable media can connect. ¹
• Assessors will look for repeatable evidence: configuration baselines, exception approvals, and audit logs showing actual control operation. ²

Removable media controls fail in predictable ways: “temporary” USB exceptions become permanent, engineers keep a “known good” thumb drive, and incident response discovers weeks later that an unmanaged device carried files off-network. CMMC Level 2 Practice 3.8.7 is designed to stop that pattern by forcing you to decide, document, and technically enforce how portable storage interacts with the systems that handle Controlled Unclassified Information (CUI). ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat 3.8.7 as a guardrail + exception workflow problem. Build a default-deny posture for removable storage on in-scope system components, then create a narrow, auditable process for business-justified use cases (for example, approved encrypted media for specific maintenance tasks). Your evidence needs to show two things: (1) the rules exist and are communicated, and (2) the rules are enforced consistently through configuration and monitoring, not memory and goodwill. ¹

This page gives requirement-level implementation guidance you can operationalize quickly, including step-by-step actions, artifacts to retain, and audit hangups to preempt.

Regulatory text

Requirement (framework mapping): “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.8.7 (Control the use of removable media on system components).” ¹

Operator interpretation: You must put controls in place so removable media use on in-scope systems is governed by defined rules (allowed, restricted, or blocked), enforced through technical settings where feasible, and supported by an exception process when business needs require access. The assessor expectation is that you can demonstrate consistent implementation across the environment that processes CUI. ²

Plain-English interpretation

Control removable media the same way you control account access: define what’s permitted, block the rest by default, and require approvals plus traceability for exceptions. Removable media includes USB flash drives, external hard drives, SD cards, and other portable storage that can carry malware in or move CUI out. ¹

Who it applies to

Entity scope

• Defense contractors and other federal contractors that handle CUI and are pursuing or required to meet CMMC Level 2. ³
• Organizations implementing NIST SP 800-171 Rev. 2 controls for CUI environments. ¹

Operational scope (what systems count)

Apply 3.8.7 to system components in the CUI environment, typically:

• End-user endpoints (workstations, laptops) used to access/process/store CUI.
• Servers where removable media can be connected (including admin consoles).
• Specialized systems (test benches, engineering workstations) if they are in-scope for CUI. ¹

A practical boundary rule: if a device can touch CUI or administer systems that touch CUI, removable media controls should be enforced there.

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

Step 1: Define “removable media” and categorize use cases

Create a short standard that names what counts as removable media in your environment and identifies the limited scenarios where it is needed (for example, field updates, machine tooling, air-gapped transfers). Keep it specific so it can be enforced. ¹

Deliverable: Removable Media Standard (1–2 pages) with definitions, scope, and allowed scenarios.

Step 2: Set a default posture for in-scope systems

Pick one of these models and document it:

• Default deny: block all removable storage except approved devices and approved users.
• Default restrict: allow only read-only, or allow only encrypted corporate media.
• Allow with monitoring: generally weaker; expect to justify why deny/restrict is not feasible.

For CMMC assessment readiness, teams usually do best with “deny by default + managed exceptions” because it is testable and consistent. ²

Deliverable: Policy statement that clearly says what happens when removable media is inserted (blocked, read-only, allowed only if encrypted, etc.).

Step 3: Implement technical enforcement

Implement controls at the system level. Your approach depends on your stack, but your evidence must show the control is active.

Common patterns:

• Endpoint management controls to block USB mass storage.
• Device allowlisting for approved media (by device ID/serial where supported).
• Enforced encryption requirements for any permitted portable storage.
• Prevent execution from removable media where feasible.
• Central logging of device connection events and file transfer activity where supported.

Deliverables:

• Configuration baseline (screenshots, exported policies, or configuration reports) showing removable media restrictions applied to in-scope endpoints. ¹
• System scope list showing which device groups receive the policy (CUI endpoints, privileged admin workstations, etc.).

Step 4: Create an exception (waiver) workflow you can defend

Your exception process should answer four questions:

1. Who can request an exception?
2. Who approves it (IT/security + data owner if CUI is involved)?
3. What compensating controls are required (encrypted device, time-bounded access, scanning, check-in/out)?
4. How do you expire and review exceptions?

Deliverables:

• Exception request form (ticket template is fine) capturing business justification, scope, duration, device identity, and approvals.
• Exception register (simple table) with status, expiry, and evidence links.

Step 5: Control the removable media inventory (for what you allow)

If you allow any removable media, treat it as an asset class:

• Approved device types and approved encryption standard/setting (describe the required setting, not a brand promise).
• Issuance and return process (check-out/check-in).
• Labeling and ownership (who is responsible for the media).
• Sanitization/disposal expectations when media is retired.

Deliverables:

• Approved removable media inventory (serial/device ID where possible, owner, issuance date, status).
• Handling procedure for allowed media (storage, transport, loss reporting).

Step 6: Monitoring and response tie-in

Define what you review and what triggers action:

• Alerts for blocked device insertion attempts.
• Alerts for removable media mounted on endpoints that should not allow it.
• Investigation steps and escalation path if CUI is suspected to have moved to removable media.

Deliverables:

• Log samples showing removable media control events.
• Incident playbook addendum for suspected removable media data movement.

Step 7: Train the populations that will break the rule

Targeted training beats broad training here:

• Engineering / manufacturing teams that use portable media in workflows.
• IT admins and desktop support who troubleshoot “just this once” requests.
• Users in the CUI enclave.

Deliverables:

• Targeted awareness snippet (what’s blocked, how to request an exception, what to do if you find unknown media).
• Training completion evidence (roster or LMS export).

Required evidence and artifacts to retain

Use this as your assessment-ready checklist:

Evidence item	What it proves	Good format
Removable Media Policy/Standard	Rules exist and define allowed use	Approved doc with version/date
In-scope system list (CUI boundary)	Control applies to system components that matter	Asset/export + scope statement
Endpoint/device control configuration	Technical enforcement exists	MDM/GPO/export, screenshots, config report
Exception workflow + examples	Controlled, approved deviations	Tickets + approvals + expiry
Approved media inventory (if any allowed)	Accountability for permitted devices	Spreadsheet/asset tool export
Logging/monitoring records	Control operates and is monitored	SIEM queries, sample logs
Periodic review record	Exceptions and settings are maintained	Review memo, tickets, change records

Operational tip: store evidence in a single “3.8.7 evidence folder” mapped to the control statement so you can respond quickly during assessment. This aligns with the expectation to map the practice to documented control operation and recurring evidence capture. ²

Common exam/audit questions and hangups

Expect an assessor (or internal auditor) to probe these points:

• “Show me enforcement.” They will ask for the actual device control configuration, not a policy PDF. ¹
• “What’s in scope?” If you cannot name which endpoints/servers are covered, they will assume gaps.
• “How do exceptions work?” They will want to see approved exceptions with expiry and compensating controls.
• “What about admins?” Privileged users often have broader rights; assessors will ask whether removable media restrictions apply to admin workstations too.
• “Do you monitor violations?” If devices are blocked but nobody reviews alerts or logs, the control looks brittle.

Frequent implementation mistakes and how to avoid them

1. Policy without enforcement. Fix: implement device control settings and keep exported configurations as evidence. ¹
2. Overbroad exceptions (“IT can override”). Fix: require a ticket, named approver, and an expiry date; record the device identity.
3. Ignoring “non-USB” removable media. Fix: explicitly include SD cards and portable storage connected through other interfaces in the definition.
4. Allowing personal devices “if encrypted.” Fix: “encrypted” must be verifiable and managed; otherwise keep to corporate-issued media with accountability.
5. No link to incident response. Fix: add a simple response step for suspected CUI transfer and lost media.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific practice, so you should treat assessment risk as your primary driver: if you cannot show consistent enforcement plus evidence, you risk failing to demonstrate CMMC Level 2 practice implementation during assessment. ²

Operational risk is straightforward:

• Removable media creates a direct malware ingress path.
• It also creates a low-friction data egress path for CUI if copying is not controlled and logged. ¹

Practical execution plan (30/60/90)

First 30 days (stabilize and define)

• Confirm the CUI boundary and list in-scope endpoints and servers.
• Publish a removable media standard with a default posture (deny or restrict).
• Stand up an exception workflow (ticket template + approvers + register).
• Pilot technical enforcement on a small in-scope group to validate operational impact. ¹

Days 31–60 (enforce and evidence)

• Roll out enforcement broadly to in-scope endpoints.
• Implement allowlisting/encrypted-only rules for any approved media.
• Start centralized collection of device control events (or establish where logs will be pulled from during assessment).
• Capture baseline evidence exports and store them in an assessment-ready location. ²

Days 61–90 (operationalize and audit-proof)

• Run an internal control test: attempt blocked media insertion on multiple device types and document results.
• Review exceptions for necessity, expiry, and compensating controls.
• Train high-risk user groups and desktop support on the new process.
• Build recurring evidence capture in Daydream so your control mapping and artifacts stay current between assessments. ²

Frequently Asked Questions

Does 3.8.7 mean we must block all USB ports?

No. It requires you to control removable media use on system components, which can be implemented as block-by-default with managed exceptions, or a restricted model like encrypted-only corporate media. Your choice must be documented and enforceable. ¹

Are keyboards, mice, and USB headsets “removable media”?

3.8.7 focuses on removable storage media, not all USB peripherals. Write definitions that separate mass storage from other device classes, then enforce controls against the storage class. ¹

If a machine needs removable media for maintenance, can we allow it?

Yes, but treat it as an exception-backed workflow: approve the use case, require corporate-issued encrypted media, and keep an inventory plus log evidence. Make the exception narrow and auditable. ¹

What evidence is most persuasive to an assessor?

Exported endpoint/device control policies, proof they apply to the in-scope device group, and real tickets showing exceptions with approvals and expiry. Add log samples that show blocked or controlled events. ²

How do we handle third parties (MSPs, onsite technicians) who bring USB tools?

Make third party access part of your removable media rules: require approved media, approved workflow, and supervision or controlled admin workstations where possible. Document the rule and keep exception approvals tied to the engagement. ¹

We can’t technically block removable media on a few legacy systems. What then?

Document the limitation, narrow exposure (isolate the system, limit accounts), and require procedural controls such as check-in/out of approved media plus heightened monitoring. Keep explicit exceptions and revisit feasibility during system lifecycle planning. ¹

Footnotes

1. NIST SP 800-171 Rev. 2

2. DoD CMMC Program Guidance

3. 32 CFR Part 170