Media Use

To meet the FedRAMP Moderate media use requirement (NIST SP 800-53 Rev 5 MP-7), you must define what “system media” types are allowed (or banned), specify which systems/components the rule applies to, and enforce it with technical and procedural controls. Your goal is simple: prevent data loss and malware entry via removable media and other portable storage.

Key takeaways:

  • You must define media types, in-scope systems, and controls; auditors will look for your specific definitions.
  • Enforcement has to be operational, not just policy; expect technical blocks, exceptions, and monitoring.
  • Evidence should show configurations + logs + approvals, not only a written standard.

“Media use” sounds narrow until you map it to how breaches and data spills happen in real environments: USB storage, external drives, phones mounted as storage, virtual ISO images, and even diagnostic media used by admins or third parties. MP-7 forces you to make clear decisions about which media types can touch which systems, then implement controls that actually stop prohibited use.

For a FedRAMP Moderate system, you should treat MP-7 as a design constraint across endpoints, admin workstations, and any system components that can accept media. The requirement is intentionally flexible: you choose the media types, the target systems/components, and the control mechanisms. That flexibility is also the trap. Most audit findings come from vague definitions (“removable media is restricted”), inconsistent enforcement (some fleets blocked, others not), and exception processes that exist on paper but not in tickets and logs.

This page translates MP-7 into a practical implementation pattern you can put into production quickly: define scope and rules, enforce by configuration, build an exception workflow, then retain evidence that proves the controls are active and effective.

Regulatory text

Requirement (excerpt): “Restrict or prohibit the use of organization-defined types of system media on organization-defined systems or system components using organization-defined controls.” 1

Plain-English interpretation

You must (1) decide which media types are risky enough to restrict or ban, (2) decide where those restrictions apply, and (3) implement controls that enforce the rule. Auditors will expect your “organization-defined” choices to be written, approved, and consistently implemented across the in-scope boundary.

Put differently: if a user can plug in a USB drive (or mount portable storage) and copy regulated data off your environment, MP-7 expects you to have a defined stance and a working block or restriction.

Who this applies to

In-scope organizations

  • Cloud Service Providers (CSPs) operating a FedRAMP Moderate authorized system
  • Federal Agencies operating or inheriting controls for a FedRAMP Moderate system

In-scope operational context

MP-7 typically applies wherever “system media” can be introduced or used, including:

  • User endpoints that access the FedRAMP environment (corporate laptops, VDI endpoints, managed desktops)
  • Privileged admin workstations (PAWs), bastion hosts, jump boxes
  • Servers and virtual hosts where media can be mounted (physical media, ISO images, attached storage)
  • System components such as kiosks, build agents, CI runners, troubleshooting stations
  • Third-party access paths (support engineers, professional services, data migration teams)

A practical scoping rule: if the component can read/write external media and can access FedRAMP data or management planes, treat it as in-scope.

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

1) Define “system media” for your environment

MP-7 is control-by-definition. Write a short, explicit list that matches your reality. Example categories you can define:

  • Removable storage: USB mass storage, external HDD/SSD
  • Optical media: CD/DVD (rare, but still present in some environments)
  • Mobile devices presented as storage (MTP/PTP, tethered storage modes)
  • Virtual media: ISO mounting, virtual USB devices via hypervisors/remote management tools
  • Diagnostic/boot media used for recovery

Your definition must be operational. If your endpoint agent can only block “USB mass storage,” don’t write a policy that claims you block “all removable media” without carving out what you can’t enforce.

2) Define the systems/components where rules apply

Create an applicability matrix. Example rows:

  • Corporate endpoints (managed)
  • Privileged admin workstations
  • Bastion/jump hosts
  • Production servers
  • Build systems
  • Contractor-managed endpoints (if allowed)

Then set the rule per row: Prohibit, Restrict with conditions, or Allow.

3) Choose controls that enforce restrictions (not just warn)

MP-7 requires “organization-defined controls.” Common control families you can use (pick what fits your stack):

  • Endpoint device control to block or read-only USB mass storage
  • OS configuration to disable removable storage drivers or limit mounting
  • VDI controls to disable client drive redirection and USB passthrough
  • Server hardening to prevent mounting external/virtual media
  • DLP controls to restrict copying sensitive data to removable media
  • Privileged access controls to limit who can change device control settings

A clean operational model:

  • Default = block removable storage on in-scope endpoints and admin systems
  • Allow only by time-bound exception for approved business needs
  • Route all exceptions through tickets with explicit approvals and compensating controls

4) Build a documented exception process you can defend

Auditors accept exceptions when they are controlled. Your exception workflow should include:

  • Requestor, business justification, and data types involved
  • Systems affected (asset IDs, hostnames)
  • Media type and purpose (data import, incident response, vendor patching)
  • Duration and expiration (explicit end condition)
  • Approvers (system owner + security/compliance)
  • Compensating controls (encryption, scanning, supervised use, logging)

Make exceptions measurable: if you can’t list “who has USB enabled right now,” you will struggle in an assessment.

5) Add operational checks and monitoring

MP-7 becomes credible when you can detect violations:

  • Alerts for attempted use of blocked media (endpoint logs)
  • Inventory view of endpoints with device control disabled
  • Periodic reviews of active exceptions and stale approvals
  • Spot checks during access reviews for privileged workstations

6) Train the populations that matter

Don’t train everyone with generic content. Train:

  • IT support and desktop engineering on what is blocked and how exceptions work
  • Admins and SREs on virtual media rules (ISO mounting, hypervisor consoles)
  • Third parties (support, migration teams) on allowed transfer methods

7) Align transfer alternatives so teams can still do their jobs

Blocking USB without a safe alternative creates shadow IT. Provide approved paths:

  • Managed secure file transfer
  • Approved cloud storage with access controls
  • Ticketed data import workflows
  • Controlled staging servers with malware scanning and logging

Required evidence and artifacts to retain

Auditors will ask for proof that your “organization-defined” choices exist and that controls enforce them. Retain:

  • Media Use Standard: definitions, allowed/prohibited media types, in-scope systems, exception rules
  • System applicability matrix (by system type or environment)
  • Technical configuration evidence:
    • Endpoint management policies (device control settings)
    • VDI policies (USB passthrough, drive redirection settings)
    • Server baseline settings for media mounting
  • Exception tickets and approvals with start/end conditions and compensating controls
  • Inventory/report of devices with media controls applied (or exceptions enabled)
  • Monitoring artifacts:
    • Logs of blocked events or attempted connections
    • Periodic exception review notes and closure records
  • Training/communications targeted to IT/admin populations

A useful packaging trick: keep a single “MP-7 evidence bundle” folder per assessment period with dated exports and screenshots so you are not scrambling later.

Common exam/audit questions and hangups

Expect questions like:

  • “What media types are prohibited, and where is that defined?” (They want your explicit list.)
  • “Show me how your controls technically enforce the restriction.” (They want configs, not narrative.)
  • “Which endpoints/admin systems are exempt and why?” (They want a list plus approvals.)
  • “How do you detect unauthorized media use?” (They want logs/alerts and who reviews them.)
  • “How do you control virtual media (ISO mounting) in server/admin contexts?” (Often missed.)

Hangups that trigger deeper testing:

  • “Policy says prohibited, but your help desk can override controls without approval.”
  • “Controls exist on corporate laptops but not on admin workstations.”
  • “Exceptions never expire.”

Frequent implementation mistakes (and how to avoid them)

  1. Writing vague definitions.
    Fix: enumerate media types in plain terms and tie them to enforceable controls.

  2. Blocking USB storage but allowing uncontrolled ISO mounting.
    Fix: include “virtual media” in scope and harden admin workflows around hypervisor consoles and remote management.

  3. No system/component mapping.
    Fix: publish an applicability matrix and connect it to your asset inventory or endpoint groups.

  4. Exceptions via email/Slack.
    Fix: require tickets with approvals and expiration, then generate an exception register from the ticket system.

  5. Third-party work ignored.
    Fix: contractually require third parties to follow your transfer paths; provide a controlled method for data exchange.

Enforcement context and risk implications

No public enforcement case sources were provided for this control in the supplied source catalog, so this page does not list specific cases.

Operationally, MP-7 maps to two recurring risks you can explain to executives and system owners:

  • Data exfiltration: removable media is a straightforward path to remove sensitive datasets from controlled environments.
  • Malware introduction: portable media remains a reliable infection vector, especially in admin and recovery workflows.

Your goal is to reduce both risks while preserving a controlled path for legitimate data movement.

Practical 30/60/90-day execution plan

First 30 days (stabilize and define)

  • Publish a Media Use Standard with: defined media types, in-scope components, default rule, and exception requirements.
  • Build the applicability matrix and confirm ownership for each system class.
  • Identify current “known needs” for media (IR kits, data migration, lab workflows) so your default block does not break critical operations.

By 60 days (enforce and evidence)

  • Deploy endpoint/VDI controls to block or restrict defined media types across in-scope fleets.
  • Stand up the exception workflow in your ticketing system with mandatory fields and an expiration requirement.
  • Start collecting baseline evidence exports (policy screenshots, endpoint reports, exception register).

By 90 days (monitor and make it sustainable)

  • Turn on alerting/reporting for attempted media use and policy drift.
  • Run the first exception review with system owners; close stale exceptions.
  • Test an audit-ready walkthrough: pick one endpoint group, one admin system, and one exception; prove the full chain from policy to enforcement to logs.

If you use Daydream to manage control requirements and evidence, treat MP-7 as a “living requirement” with assigned owners, mapped artifacts (config exports, reports, tickets), and recurring review tasks so your evidence stays current between assessments.

Frequently Asked Questions

Does MP-7 only apply to physical USB drives?

No. You define “system media,” and many programs include virtual media such as ISO mounting and virtual USB presented through remote consoles. Document what you include and enforce it consistently.

Can we allow USB for developers but block it for everyone else?

Yes, if you explicitly define that exception in your “organization-defined” rules, apply it only to named groups/systems, and control it with approvals, logging, and periodic reviews.

What do auditors want to see as proof that media is restricted?

They typically ask for the written standard, technical policy/configuration evidence (MDM/endpoint settings, VDI settings), and an exception register with approvals and expirations.

How should we handle third parties who need to transfer data during onboarding or support?

Give them an approved transfer method (secure file exchange, controlled staging workflow) and prohibit ad hoc removable media. Record their access and require the same exception process if media is ever permitted.

Is encryption of USB drives enough to satisfy MP-7?

Encryption can be a compensating control for approved exceptions, but MP-7 still expects you to restrict or prohibit media use on defined systems using defined controls. If your rule is “allow encrypted USB only,” you must enforce the encryption requirement and document it.

What’s the fastest way to find gaps before an assessment?

Compare your policy’s defined scope to reality: list all endpoint groups, admin workstations, and server/admin consoles, then verify which ones have technical blocks enabled and which ones rely on informal practice.

Footnotes

  1. NIST Special Publication 800-53 Revision 5

Frequently Asked Questions

Does MP-7 only apply to physical USB drives?

No. You define “system media,” and many programs include virtual media such as ISO mounting and virtual USB presented through remote consoles. Document what you include and enforce it consistently.

Can we allow USB for developers but block it for everyone else?

Yes, if you explicitly define that exception in your “organization-defined” rules, apply it only to named groups/systems, and control it with approvals, logging, and periodic reviews.

What do auditors want to see as proof that media is restricted?

They typically ask for the written standard, technical policy/configuration evidence (MDM/endpoint settings, VDI settings), and an exception register with approvals and expirations.

How should we handle third parties who need to transfer data during onboarding or support?

Give them an approved transfer method (secure file exchange, controlled staging workflow) and prohibit ad hoc removable media. Record their access and require the same exception process if media is ever permitted.

Is encryption of USB drives enough to satisfy MP-7?

Encryption can be a compensating control for approved exceptions, but MP-7 still expects you to restrict or prohibit media use on defined systems using defined controls. If your rule is “allow encrypted USB only,” you must enforce the encryption requirement and document it.

What’s the fastest way to find gaps before an assessment?

Compare your policy’s defined scope to reality: list all endpoint groups, admin workstations, and server/admin consoles, then verify which ones have technical blocks enabled and which ones rely on informal practice.

Authoritative Sources

Operationalize this requirement

Map requirement text to controls, owners, evidence, and review workflows inside Daydream.

See Daydream
FedRAMP Moderate Media Use: Implementation Guide | Daydream