03.08.07: Media Use

NIST SP 800-171 Rev. 3 requirement 03.08.07 (Media Use) requires you to control how media is used in environments where CUI is processed, stored, or transmitted, so CUI does not end up on unapproved devices or leave controlled spaces without protection. Operationalize it by defining approved media and uses, technically enforcing restrictions, and keeping auditable proof that controls work. ¹

Key takeaways:

• Treat “media use” as a prevent-and-prove control: prevent CUI from landing on unapproved media, and prove enforcement with logs and reviews.
• Scope is broader than USB drives; include external drives, mobile devices, removable virtual media, and portable storage used with CUI.
• Your assessment outcome depends on tight SSP statements and recurring evidence tied to specific systems, owners, and configurations. ²

“Media use” is where well-written policies often fail in practice. Teams say “no removable media,” then a program manager exports CUI to a personal drive for a meeting, or an engineer burns build artifacts to external storage to work offline. Assessors focus on whether you actually prevent that behavior, not whether you discouraged it.

For NIST SP 800-171 Rev. 3, you should treat 03.08.07 as a control that sets rules for what types of media are allowed, under what conditions, and with what protections in place. Your goal is consistent: stop unapproved movement of CUI through portable or removable storage paths, and be able to show enforcement and exceptions management during an assessment. ¹

This page gives requirement-level implementation guidance you can hand to IT and system owners: scoping questions, technical enforcement options, exception handling, and the evidence package you need in your SSP and assessment binder. Where teams stumble most is not the “rule,” but the operational boundary: which endpoints, which enclaves, which third parties, and which workflows are in scope for CUI. ²

Regulatory text

Requirement: “NIST SP 800-171 Rev. 3 requirement 03.08.07 (Media Use).” ¹

Operator interpretation (what you must do):

• Define and enforce rules for how media can be used when interacting with CUI, including what media types are approved, what uses are prohibited, and what protections apply.
• Implement the rule in the environment, not only on paper, and retain evidence that the restrictions are working. ¹

Because the excerpt provided is a requirement label, assessors will rely heavily on your SSP control narrative, your technical configurations, and your operational evidence to determine whether “media use” is controlled in the CUI boundary. ²

Plain-English interpretation of 03.08.07: Media Use

If CUI touches a device or storage medium, that medium becomes a risk path. This requirement expects you to:

1. decide what media is allowed,
2. restrict media to approved uses, and
3. make exceptions rare, controlled, and provable.

Practical translation: if endpoints can mount removable storage, users can copy CUI out. If virtual “removable media” is enabled (ISO mounting, passthrough to VMs), CUI can move the same way. If mobile devices sync files, that is media movement. Your control should reduce these paths to only what the mission requires and add safeguards where allowance is necessary. ¹

Who it applies to (entity and operational context)

Applies to:

• Any nonfederal organization that processes, stores, or transmits CUI under a federal contract or similar requirement flow-down. ¹

Operationally, it applies to:

• CUI in-scope endpoints (workstations, laptops, VDI thin clients where local media mapping is possible).
• Servers and admin jump hosts that can read/write to external storage.
• Virtualization platforms where removable media or local drive passthrough is possible.
• Printers/MFPs and scanner workflows if they store jobs to internal/external storage (treat as media until proven otherwise).
• Third-party-managed devices inside your CUI boundary (managed service providers, contract engineers) because they can introduce uncontrolled media paths.

Scope tip: write down your CUI boundary first (systems, subnets, tenants, enclaves). Then declare media rules for anything inside that boundary. Your SSP must match that boundary. ²

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

1) Define “media” for your environment (and don’t argue about semantics)

Create a short media taxonomy you can enforce:

• Removable storage: USB drives, external HDD/SSD, SD cards
• Mobile devices used as storage: phones/tablets when connected for file transfer
• Removable virtual media: ISO mounting, VM device passthrough, redirected drives in VDI
• Portable backup media: tapes, encrypted portable backup drives

Add a simple statement: “Any media that can store CUI is covered by 03.08.07.” Keep it enforceable.

2) Set the default rule: “blocked unless approved”

Write a standard that answers:

• Which roles can use removable media with CUI (if any)
• What “approved media” means (corporate-owned, inventoried, encrypted, labeled)
• Where it can be used (only inside controlled spaces, only on managed endpoints)
• What is prohibited (personal USB, unknown media, ad hoc transfers, uncontrolled home devices)

This is where policy becomes testable. If you cannot test it, rewrite it.

3) Implement technical enforcement (your primary line of defense)

Pick enforcement mechanisms that match your endpoint and identity stack:

• Endpoint management: block removable storage classes, allow by device ID, restrict write access, require encryption.
• DLP / device control: prevent copying CUI-labeled files to removable storage; alert on violations.
• VDI controls: disable clipboard/file redirection, block local drive mapping, restrict ISO mounting.
• Privileged access controls: admins shouldn’t bypass media restrictions on jump hosts without documented need.

Expectation management: assessors generally view technical enforcement as stronger than “user training + policy,” especially for a medium-severity control that prevents direct CUI exfil paths. ²

4) Build an exception process that is narrow and auditable

You need an exception workflow for legitimate mission needs (e.g., offline maintenance, classified facility interfaces, lab equipment constraints). Minimum elements:

• Business justification tied to contract/program
• Defined duration and expiry
• Compensating controls (encryption, custody logging, restricted endpoints, secure storage)
• Approval by system owner and compliance/security
• Post-use verification (confirm media returned, wiped/sanitized, or stored per rules)

Track exceptions in a register. If you can’t list exceptions quickly in an exam, you don’t control them.

5) Operationalize with monitoring and review

Decide what “proof” looks like in your environment:

• Alerts on blocked device insertions
• Reports of permitted device IDs and assigned custodians
• Review of exceptions and expirations
• Sampling of endpoints to confirm policies are applied

Tie every review to an owner and a cadence you can sustain.

6) Document it cleanly in SSP and POA&M

In your SSP, write a control statement that names:

• In-scope systems/endpoints
• Enforcing tools (MDM/EDR/device control)
• The exact rule set (block classes, allowlist, encryption requirement, VDI redirection disabled)
• Exception process and where evidence is stored (ticketing system, GRC repository)

If enforcement is partial, put the gap in the POA&M with a clear closure test (what you will show an assessor to prove it is fixed). ¹

Practical note: Daydream is useful here when you need to map 03.08.07 to SSP language, assign control ownership across IT and program teams, and keep recurring evidence attached to the control so assessments don’t become a scavenger hunt. ²

Required evidence and artifacts to retain

Keep artifacts that show design, implementation, and operation:

Governance artifacts

• Media Use policy/standard (approved, versioned)
• Data classification/CUI handling standard cross-referencing media restrictions
• Exception procedure and exception register

Technical artifacts (most exam-relevant)

• Endpoint configuration baselines showing removable media restrictions
• Screenshots/exports from device control rules (block/allowlist logic)
• VDI or endpoint profiles showing drive redirection disabled (if applicable)
• Encryption enforcement evidence for approved removable media (configuration, not just a statement)

Operational evidence

• Logs or reports of removable media events (blocked/allowed)
• Review records (meeting notes, sign-offs, tickets) showing periodic checks of:
  • policy application coverage
  • exceptions and expirations
  • violations and remediation actions
• Training and awareness materials specific to removable media rules (helpful, but not sufficient alone)

SSP/POA&M alignment

• SSP control narrative for 03.08.07 mapped to system components and owners
• POA&M entries for incomplete rollout, with closure criteria and validation evidence ²

Common exam/audit questions and hangups

Expect these lines of questioning (and prep your evidence to answer in minutes, not days):

1. “Show me how removable media is blocked on CUI endpoints.”
   Hangup: you show a policy, not a configuration export.

2. “Which endpoints are in scope, and how do you know the policy applies to all of them?”
   Hangup: no authoritative asset inventory tagged to the CUI boundary.

3. “Do you allow any removable media? If yes, how is it approved and tracked?”
   Hangup: informal approvals via email; no device inventory or custodian assignment.

4. “How do you detect and respond to attempted use?”
   Hangup: logging exists, but nobody reviews it, or reviews are not recorded.

5. “How is this described in the SSP, and where is your evidence stored?”
   Hangup: SSP is generic and doesn’t name systems/tools, which raises doubts across the assessment. ²

Frequent implementation mistakes and how to avoid them

• Mistake: “No USB” declared, but admin exceptions are effectively unlimited.
  Fix: separate admin use from general user population; require ticketed approval, time-bound access, and reporting.

• Mistake: Only laptops are controlled; engineering workstations and lab machines are missed.
  Fix: define CUI endpoints by boundary tag, not by department.

• Mistake: Allowing “encrypted USB drives” with no proof the encryption is enforced and configured correctly.
  Fix: standardize on approved models and enforce via device control/MDM; keep configuration exports as evidence.

• Mistake: Ignoring VDI/remote session redirection paths.
  Fix: test from a standard user session: attempt local drive mapping, clipboard transfer, ISO mount, and document results.

• Mistake: Evidence is scattered across IT consoles and personal folders.
  Fix: store evidence per control in a single repository with naming conventions; Daydream can serve as the control-centered evidence binder so owners attach exports and review records directly to 03.08.07. ²

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat “enforcement” here as assessment and contractual risk rather than a referenced case record. ¹

Operational risk is straightforward:

• Uncontrolled media use is a high-confidence path for CUI loss, accidental disclosure, and untracked distribution.
• In assessments aligned to NIST SP 800-171A, weak evidence and generic SSP narratives commonly drive findings even when teams believe controls exist. ²

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and stop obvious bleed)

• Confirm the CUI system boundary and list in-scope endpoint groups. ²
• Publish a Media Use standard: default deny, approved media definition, exception flow.
• Implement quick technical wins: block removable storage broadly on in-scope endpoints where feasible; disable common redirection paths in VDI where used for CUI.
• Stand up an exception register and require tickets for any approved removable media.

Days 31–60 (make it enforceable and auditable)

• Move from broad blocks to controlled allowances (allowlisting by device ID, custodian assignment).
• Turn on logging/reporting for removable media events; define who reviews what and where results are stored.
• Update SSP for 03.08.07 with specific tools, configs, and in-scope components. ¹
• Create a POA&M entry for any endpoint populations not yet covered, with a clear closure test. ²

Days 61–90 (prove operation and harden edge cases)

• Perform an internal control test aligned to assessment expectations (attempt removable media use on sampled endpoints; confirm blocks; validate logs). ²
• Review exceptions for expiry, compensating controls, and closure evidence (wipe/sanitize/return).
• Run a management review with metrics that are defensible (counts are fine, but don’t invent targets); document decisions and follow-ups.
• Centralize artifacts (configs, exports, review records) in a control-based evidence binder; Daydream helps keep SSP/POA&M, owners, and evidence in one place for assessments. ²

Frequently Asked Questions

Does 03.08.07 mean we must ban all USB drives?

No. The requirement is to control media use in the CUI environment. Many teams choose “default deny with narrow, documented exceptions” because it is easier to prove in an assessment. ¹

What counts as “media” for this control?

Treat any device or mechanism that can store and move CUI as media: removable drives, portable backup devices, and virtual removable media (like ISO mounting or redirected drives). Document your definition in your standard so the scope is testable. ¹

How do assessors validate this control?

They look for a clear SSP description plus objective evidence: endpoint configurations, device control rules, logs, and recorded reviews or exception approvals. NIST SP 800-171A provides the assessment lens for what “implemented” and “operating” look like. ²

We have a policy, but we can’t technically block removable media on a subset of specialized machines. What should we do?

Treat that as an exception path with compensating controls (approved encrypted media, physical custody controls, restricted ports where possible) and track it in your POA&M until you can close or reduce the gap. Keep approval and verification evidence. ²

How should third parties fit into media use controls?

If a third party works inside your CUI boundary or on your managed endpoints, they must follow the same media restrictions and exception process. Put requirements in contracts and onboarding, then confirm enforcement through the same technical controls and logs. ¹

What’s the minimum evidence set to avoid a “paper control” finding?

An assessor should be able to see: (1) a written rule, (2) technical enforcement exports, (3) logs or reports showing the enforcement operates, and (4) documented reviews/exceptions. Store it in a single place mapped to 03.08.07 to reduce scramble during assessment. ²

Footnotes

1. NIST SP 800-171 Rev. 3

2. NIST SP 800-171A