03.08.07 Media use: requirements and evidence

What NIST SP 800-171 03.08.07 media use asks an organization to control

03.08.07 asks you to decide which types of system media may be used on systems that handle CUI, and to block the rest. The requirement has two obligations: restrict or prohibit the use of media types that the organization defines, and prohibit the use of removable system media that does not have an identifiable owner. If your contract now requires NIST SP 800-171, the practical question is which USB drives, external disks, optical media and similar devices are permitted on CUI systems, who approves them, and how you would prove that only approved media connect. The risk is that CUI leaves the environment on a device nobody is tracking. A small drive can copy a full project folder in minutes, and a lost or forgotten drive with no owner is hard to trace in an incident. The requirement is harder than it reads because NIST leaves the list of media types to the organization. Rev. 3 carries a single organization-defined parameter for this requirement, so an assessor will expect a written, approved list of permitted and prohibited media types, not a general statement that removable media is controlled. Confirm with your contracting agency whether it has assigned any value for this parameter, since the organization must set it if the agency does not.

Rev. 3 folded the Rev. 2 requirement 3.8.8, which covered unmarked or unowned removable media, into this requirement. If your team mapped that older control to a separate procedure, review that procedure now so the ownership rule sits with the media type rules. The NIST Rev. 3 publication is the reference for the exact wording. Do not confuse this requirement with 03.08.01 media storage, which governs how media that contain CUI are physically secured and who may access them. 03.08.07 governs which devices may connect at all, so it needs its own inventory of device types and an enforcement mechanism, such as a restriction on USB storage in your endpoint policy.

Which systems, media and people 03.08.07 covers in practice

Most of the effort behind 03.08.07 Media use comes from deciding what counts as in scope before any restriction is configured. The cards below cover the decisions an assessor will expect to see documented: the systems, the media types, the ownership records, and the personal and contractor equipment that touches CUI.

Systems and endpoints that handle CUI

Start with the system security plan boundary and list every endpoint, server, kiosk and virtual desktop that processes or stores CUI. The restriction only means something on systems inside that boundary, so an endpoint left off the inventory is a gap an assessor can find through interviews and configuration checks. Confirm that the inventory is refreshed when new hosts join the enclave, not only at the annual review. Ask who owns the list and how it is reconciled against directory and device records.

Media types the organization restricts

The requirement lets the organization choose which types of system media are restricted or prohibited. NIST's discussion uses external hard drives, flash drives and smart displays as examples, but the list is yours to define and write down. Decide whether each type is prohibited outright, allowed only with approval, or allowed only when encrypted and issued by IT. Record the choice in the media protection policy, because the value you assign is the one an assessor tests against.

Ownership records for removable media

Removable media without an identifiable owner is prohibited under this requirement, so every approved device needs a named custodian. Keep a register that links each serial number to a person or role, the date it was issued and the date it was returned or sanitized. Unlabeled drives found in a lobby or on a shared desk become a finding even when no data is lost. Check that the register matches what is physically in use through periodic spot checks.

Personal devices and contractor equipment

Personal USB drives, phones used as storage and contractor laptops are the most common sources of unowned media in scope. Decide whether personal media may connect to any system that holds CUI, and state that decision in the rules of behavior that users sign. For contractor equipment, document who issued it, whether it is allowed on the CUI network, and how it is removed from the list at the end of the engagement. Ask your contract team to confirm that subcontractor terms reflect these rules.

Assigning the media-type parameter

Rev. 3 leaves the media-type value to the organization when the federal agency has not specified one, which means an unassigned parameter leaves the requirement incomplete. Ask the contracting officer or agency representative whether they have set a value, and if not, assign one yourself and document the rationale. The value should match the restriction list in your policy and the controls you actually enforce. Revisit it when the agency issues new guidance or the contract changes.

How an assessor tests 03.08.07 and what they ask to see

This table compares the three assessment methods SP 800-171A Rev. 3 uses for 03.08.07, what each method asks the assessor to look at, and where organizations most often fall short. Read it as a checklist of evidence to gather before an assessor arrives, since the examine, interview and test steps all have to agree with one another. The main takeaway is that a written media restriction is not enough on its own; the assessor will also check that people know the rule and that a mechanism enforces it.

Method	What the assessor asks to see	Common findings
Examine: policy and procedures	The system media protection policy and procedures, the system use policy, and procedures for media usage restrictions. These should name the media types restricted or prohibited and the rule for removable media without an identified owner.	Policy lists no media types, or uses generic wording such as approved media only with no defined list.
Examine: rules and records	Rules of behavior signed by system users and system audit records that show restricted media was blocked, logged or reviewed.	Rules of behavior exist but are not acknowledged by users, or audit records do not capture media connection events.
Interview: media use responsibilities	Personnel who authorize or use removable media explain which media types are allowed, how an owner is identified and what they do when unknown media appears.	Staff describe different rules from the written policy, or no one can name the restricted media types.
Interview: information security staff	Security personnel explain how restrictions are set, who approves exceptions and how violations are investigated and recorded.	Exception approvals are informal, with no record of who approved a given device.
Interview: system administrators	Administrators describe how media restrictions are configured on endpoints and servers and how changes to them are reviewed.	Administrators can disable a restriction locally with no change record or review.
Test: restriction mechanisms	A live demonstration that the defined media types are restricted or prohibited on in-scope systems, and that removable media without an identifiable owner is refused or flagged.	Policy is in place but no technical control enforces it, so a test device mounts without a block.
Test: media use processes	A walkthrough of how a new removable device is registered, assigned an owner and approved, including what happens when no owner can be identified.	No ownership record exists for removable media, so the process cannot be shown to work.
ODP check: media types defined	Evidence that the organization has assigned values to the organization-defined parameter, meaning the specific media types restricted or prohibited, and that the values are written down and approved.	Media types are never defined, so the requirement cannot be assessed as met even when some controls exist.

Evidence that passes a 03.08.07 assessment

An assessor testing 03.08.07 looks for a written restriction, a record of who owns each removable medium, and proof that the system enforces the restriction. The cards below cover the artifacts that connect those three, and each one needs a review habit so it still matches the environment at the next assessment.

Written media use restriction

This is the policy or standard that names the system media types the organization restricts or prohibits, such as USB flash drives or external hard drives, and records the ODP value the organization assigned. Because NIST does not assign ODP values, the recorded list is the first thing an assessor checks for the parameter being defined. Review it on a schedule the organization sets and whenever a new device class enters the environment, and confirm it matches what the endpoint configuration actually enforces.

Removable media ownership register

This register links each approved removable medium to a named owner or issuing authority. It answers the core question of 03.08.07: removable media without an identifiable owner is prohibited. Reconcile the register against the asset inventory and the device management records on a regular cadence, and investigate any serial number that appears in logs without a matching entry.

Endpoint enforcement configuration

Exports of the endpoint settings that block or restrict the media types named in the policy show that the restriction is enforced rather than only written down. Assessors commonly test a sample of systems to confirm the setting applies. Keep the configuration under change control so that a later change to device classes or policy scope is visible and reviewed.

Blocked and permitted media event logs

Audit records showing attempts to connect restricted media, along with records of approved connections, demonstrate that the restriction operates over time. Confirm that the logging covers every endpoint in scope and that the records are retained and reviewed. Gaps in logging for a subset of endpoints are a frequent finding, so check coverage before each assessment.

User rules of behavior acknowledgments

Signed or electronically recorded acknowledgments of the rules of behavior show that users know which media they may use and which they may not. Assessors often interview personnel with media responsibilities to confirm this awareness. Refresh acknowledgments when the policy changes and when staff change roles, and keep the list matched to the current user directory.

Exception records with approvals

Where a business need requires a restricted medium, the exception record names the device, the owner, the justification, the approver, the compensating controls and an end date. Without these records, an exception looks like an unmanaged gap. Review open exceptions on the organization's own cadence and close any that have expired.

How to implement 03.08.07 in the order that produces evidence

This sequence moves from a written media-type decision to enforced settings, logged events and a documented exception trail, so each step leaves an artifact an assessor can examine, interview against and test. Work done out of order tends to produce configurations with no owner-approved rule behind them.

Define media types and set the ODP value in writing
Start by deciding which types of system media your organization restricts or prohibits, such as USB flash drives, external hard drives, smart displays and similar devices. 03.08.07 has one organization-defined parameter, so the decision must be recorded as a value, not left implied. Security, IT and the system owners sign a media use standard listing each type, the permitted or prohibited status, and the approval path for exceptions. The output is that signed standard, which later steps and the assessment both cite. If a federal customer has specified these values, confirm them in the contract or agreement before you adopt them.
Establish ownership and issuance rules for removable media
The requirement prohibits removable system media without an identifiable owner, so every approved device needs a named owner before it is used. Write the issuance rules: who may request a device, who approves it, how it is labeled or serialized, and what happens when an owner changes role or leaves. Keep an ownership register that links each device identifier to a person and an approval record. The check that closes this step is simple: pick a sample device and confirm you can name its owner and the approval behind it.
Inventory current media and endpoints with CUI access
Before you enforce anything, find out what media already exists in the environment. Scope the inventory to systems that store, process or transmit CUI, including endpoints, servers, workstations used by personnel with CUI access and any hardware that can attach external media. Record the device types present, which ones are already in use, and whether each is covered by an owner. Many organizations discover media types in use that were never considered in the standard, and those gaps feed back into step one. The output is a current-state inventory tied to the system boundary in your system security plan.
Configure enforcement on endpoints and in the environment
Turn the standard into technical settings. Depending on the environment, this may mean device control policies on managed endpoints, blocking of mass storage classes for prohibited types, and restrictions that allow only registered devices. Document the enforcement configuration as a baseline, with the exact setting, the scope it applies to and the change record that approved it. Test the baseline on representative systems, including a case where a prohibited device is attached, and keep the result. Confirm with your endpoint management vendor which control types their platform supports rather than assuming a feature exists.
Log and review media events
An assessor will ask how you know the restriction works in practice, so configure logging for media connection and blocking events and send those records to your audit repository. Define who reviews them, how often, and what a reviewer does with an unexpected attachment, such as checking the device against the ownership register. Open-source endpoint tools can run scheduled queries across a fleet and show whether each device passes or fails a policy, which supports this review. The output is a review record showing that events were examined and what was followed up. Confirm log retention and access controls with your audit requirements.
Reconcile exceptions and document the result in the SSP
Compare what the inventory found, what the register records and what the logs show, then close each gap. Each exception should have an approval, a compensating control or a removal date set by the owner, and a record of closure. Finally, update the system security plan so it describes the media types, the ownership and issuance process, the enforcement baseline and the review cycle, and points to each artifact. Plans of action and milestones apply to gaps you cannot close immediately, and 32 CFR 170.21 governs when a POA&M is allowed for CMMC Level 2 assessments, so confirm which rules apply to your contract before you rely on one. The check that closes the sequence is an internal walkthrough in which a reviewer traces one device from request to owner to enforcement to logged event.

Which open-source tools produce media use evidence

Media use controls are proven by showing which device types are present, which are blocked, and who owns each removable item. The four tools below can each produce part of that picture from endpoints inside your own environment. None of them replaces the written media use restrictions or the enforcement that makes those restrictions real.

osquery device and file queries

osquery exposes host state as SQL tables, including running processes, loaded kernel modules, hardware events and file hashes. For 03.08.07, the hardware event and kernel module tables can show whether restricted device types connected to or are loaded on a system, and file hashes can show whether prohibited media content was copied onto a host. Its osqueryd daemon can schedule the same queries across a fleet. Licensed under Apache-2.0 OR GPL-2.0-only. Confirm which tables your operating systems populate for USB and storage events before you rely on them as evidence.

Velociraptor hunts across systems

Velociraptor collects forensic artifacts defined in VQL from endpoints and runs hunts that gather one or more artifacts across a group of systems. For media use, a hunt can collect device and removable media records from many hosts at once, which helps when you must show the state of a whole population rather than a sample. Hunts schedule offline machines to collect when they reconnect, so laptops that were away still contribute. Licensed under AGPL-3.0-only. Confirm the AGPL obligations on your own deployment and whether your chosen artifacts cover the device types you restrict.

Wazuh configuration assessment

Wazuh Security Configuration Assessment scans monitored endpoints against YAML policies, mostly based on CIS benchmarks, and checks files, directories, registry keys and running processes. It then recommends remediation. Custom policies can check the settings your media use rule depends on, such as whether a device control setting is enabled or a prohibited service is absent. The result is a recorded pass or fail per check, which assessors can examine. Licensed under GPL-2.0-only. Confirm that a custom policy covers your specific restricted media types, because shipped policies are not written for your rule.

Fleet policies for device status

Fleet policies ask yes or no questions of devices as osquery queries, and its policies page shows which devices on each fleet pass or fail each policy. You can write a policy that asks whether a prohibited media type is connected or whether a device is in the approved inventory, then use the pass and fail view to see where exceptions sit. This gives a current, device-level view that is easy to show to an assessor. Licensed under MIT. Confirm that each policy query returns accurate results on your operating systems, since a passing policy only proves what its query actually checks.

What meeting 03.08.07 costs in money and effort

This table lists the cost components of restricting media types under 03.08.07, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. The sources supplied give no dollar figures or durations for this requirement, so use the table to build a scope and ask for quotes against it. The main takeaway is that open-source tooling removes license spend, but policy, enforcement engineering, register upkeep and assessment effort remain.

Cost component	Who is paid	One-time or recurring	What drives it up or down
Policy and standard writing for permitted and prohibited media types	Internal policy owner, or an outside consultant for drafting	One-time, with periodic review	Number of media types in scope and how many system categories each one touches
Endpoint control and monitoring tooling	Vendor for licenses, or nobody for open-source tools	Licenses recurring; open-source tools carry no license fee	Fleet size and whether existing endpoint management already reports removable device use
Engineering time to configure enforcement	Internal platform or endpoint team, or an implementation partner under a fixed-scope agreement	One-time, with changes as device policy changes	Number of operating system builds, device classes and CUI systems that need enforcement
Ownership register for removable media	Internal asset or security team	Recurring as devices are issued, reassigned or retired	Staff turnover, number of removable devices in circulation and whether issuance is centralized
User training on permitted media and owner responsibilities	Internal training staff or an outside training provider	One-time per cycle, recurring for new hires	Headcount, number of roles that handle CUI and how often training is repeated
External review of the policy and evidence	Independent reviewer or consultant, if engaged	One-time per review cycle	Scope of the written policy, number of exceptions and complexity of the evidence set
Auditor sampling during assessment	Assessor, under the assessment agreement	Recurring at each assessment	Number of endpoints sampled, quality of logs and whether the register and enforcement records are ready to produce

Who owns, implements and assesses 03.08.07

Your organization owns 03.08.07 because the requirement turns on decisions only the organization can make: which types of system media are restricted or prohibited, and which removable media may be used at all. The requirement also asks that removable media without an identifiable owner be prohibited, so someone in your organization must define what ownership means and who is accountable for each device. Your team is also responsible for the organization-defined parameter that the assessment checks, and for any exceptions and their approvals.

Defined media types: Decide which types of system media are restricted or prohibited, and record the list in the media protection policy.
Ownership rules: Define how a removable device is tied to a named owner and who may issue or approve those devices.
Exception process: Set who can approve a documented exception, how long it lasts and how it is reviewed.
Policy and rules of behavior: Keep the system use policy and rules of behavior current with the restrictions users must follow.
Accountability: Assign personnel with media use responsibilities and make sure they can answer assessor interview questions.

Before outsourcing any part of this, confirm in writing which decisions remain with your management and which technical work a partner will perform.

Where organizations fall short on media use and how to close each gap

Most 03.08.07 gaps are not missing policies. They are undefined media types, rules that exist on paper but never reach endpoints, and exceptions that leave no trace. Each card names one gap, why an assessor will notice it, and the fix that closes it before the assessment starts.

No defined media types or ODP value

03.08.07 has one organization-defined parameter: the types of system media that are restricted or prohibited. If the organization never names those types, the requirement cannot be met, and an assessor will check that the value is defined. Fix it by writing a short list that names specific classes, such as USB mass storage, optical media and personal external drives, along with the approved alternatives for each. Record the list in the system security plan and the media protection policy so the two agree.

Policy written but not enforced

A policy that bans flash drives does nothing if endpoints still mount them. Assessors test the mechanisms that restrict media use on systems and system components, not only the document. Check each endpoint class against the defined list and confirm the restriction is applied and logged. Osquery can report connected USB devices across a fleet on a schedule, and Fleet policies can flag hosts where a prohibited device class is present, giving a repeatable check rather than a one-time screenshot.

Removable media without an owner

03.08.07 requires prohibiting removable system media that has no identifiable owner. Unlabeled drives found in a drawer or a conference room are a common finding and a direct failure of this requirement. Fix it with an issuance register that records each approved device, its serial number, the custodian and the date issued, and a rule that unregistered media is quarantined and reported. Ask your team to confirm how ownership is recorded for media that leaves the organization, since that is where the register most often breaks.

Personal devices on CUI systems

Personal phones, drives and laptops connected to a system that handles CUI bring media the organization does not own, configure or track. The requirement applies to any system media used with a CUI system, so personal devices fall inside its scope. Close the gap by defining which device classes are barred from CUI systems, blocking them at the endpoint, and stating the rule in the rules of behavior that users sign. Confirm with your identity and endpoint team whether personal device connections are blocked, alerted on or only discouraged.

Exceptions granted without records

Business needs sometimes justify a USB drive for a vendor, a scanner or a data transfer. When that approval lives in an email thread, the organization cannot show who approved it, for which device, for how long or what compensating controls applied. Keep an exception register with the requester, the approver, the device, the start and end dates, and the controls applied. Review it on a fixed cycle and remove exceptions that have expired, so the register matches what is actually connected.

Confusing 03.08.07 with 03.08.01

03.08.07 restricts which types of media may be used at all, such as external hard drives, flash drives and smart displays. 03.08.01 restricts who can reach media that holds CUI, for example through storage and access controls. Teams often write one control to cover both and then cannot show evidence for either. Fix it by mapping each requirement to its own policy section, its own owner and its own evidence set, and by checking that the 03.08.01 storage rules do not stand in for a media type restriction.

Scoring and POA&M consequences

Rev. 2 3.8.7, which Rev. 3 folds into 03.08.07, is assessed under CMMC Level 2 as MP.L2-3.8.7 and is worth 5 points under the 32 CFR 170.24 scoring methodology. Under 32 CFR 170.21, that requirement cannot go on a plan of action and milestones for Conditional status, so it must be closed before the assessment. Treat this as a pre-assessment gate: confirm the media type list, enforcement and owner records are in place and evidenced, and ask your assessor which Rev. 2 or Rev. 3 version your contract requires.

Questions buyers ask about 03.08.07 cost, effort and outside help

How much effort does 03.08.07 take compared with the other media protection requirements?

Media use is usually lighter than sanitization or media marking, because it asks for a decision and an enforcement mechanism rather than a repeatable physical process. The effort depends on how many media types the organization must restrict, how many endpoints and servers it runs, and whether it already has device control or endpoint management in place. Sanitization and transport add recurring handling steps, while 03.08.07 mostly adds a one-time policy decision, configuration work and periodic evidence collection. Ask any partner to break the estimate down by endpoint population, operating systems and the media types named in your ODP value.

Can we implement 03.08.07 without an outside partner?

Yes, if your team can define the restricted media types, configure enforcement and produce evidence, since the organization owns its controls and an outside party cannot assume that responsibility. A partner is most useful when fleet coverage is uneven, when the policy must be enforced across mixed platforms, or when the evidence must be collected from many hosts consistently. Whoever does the work, only an independent assessor issues the assessment result. Clarify early whether the partner will prepare evidence only or also configure and test the enforcement mechanism.

What does the work need from our internal staff?

Expect three groups of internal input. Policy owners must decide which media types are restricted or prohibited and document that decision. Endpoint and system administrators must apply the restriction and keep it consistent across the fleet. Security staff must review the exceptions, including removable media that lacks an identifiable owner, and confirm the records are retained. Interviews are part of the assessment method, so the people who run these tasks should be able to explain them in their own words.

How did Rev. 3 change the requirement from Rev. 2 3.8.8?

Rev. 3 withdrew the separate Rev. 2 requirement 3.8.8 and folded its intent into 03.08.07. Rev. 2 treated prohibiting removable media without an identifiable owner as its own requirement, while Rev. 3 combines it with restricting or prohibiting defined media types. NIST's change analysis classifies the change for 03.08.07 as significant, with more detail and foundational tasks. For CMMC Level 2 assessments, which still use Rev. 2, the 3.8.8 requirement still appears separately, so keep both mappings in your evidence set.

Does the organization or the assessor set the ODP value for 03.08.07?

The organization sets it. NIST does not assign organization-defined parameter values, and a federal agency that does not specify them leaves the nonfederal organization to assign them to complete the requirement. For 03.08.07, the ODP covers the types of system media that are restricted or prohibited. An assessor checks that the value is defined and then tests whether the restriction works, so the assessor does not choose the media types. Check whether your contract or the DoW's published values set any parameters before you finalize the list.

Can open-source tools replace commercial endpoint control for 03.08.07?

Open-source tools can produce much of the evidence, but whether they can fully replace a commercial endpoint control depends on your platforms and the enforcement you need. osquery can query hardware events and running processes across a fleet, and Fleet policies can show which devices pass or fail a yes or no check written as an osquery query. Wazuh Security Configuration Assessment checks configuration settings against YAML policies, and Velociraptor can collect artifacts across groups of systems. Confirm with each vendor whether a tool can block a media type on your operating systems, because monitoring a restriction differs from enforcing it.

What should we ask for in a quote for 03.08.07 work?

Ask for a written scope that names the media types in scope, the endpoints and servers covered, the operating systems and the enforcement method. Request the deliverables in detail: updated policy and procedures, configuration of the restriction, a fleet compliance report, exception records and test results. Confirm what is one-time and what recurs, such as monitoring, review cycles and evidence refresh. Ask who performs interviews and walkthroughs, and confirm that the assessment itself is performed by an independent assessor, not by the implementation partner.

How DeployOpen works on this

DeployOpen plans and implements the technical controls that restrict or prohibit defined types of system media, then prepares the evidence an assessor will examine, interview and test against 03.08.07. The organization keeps ownership of its media policy and decides which media types are restricted, while DeployOpen works inside the client's own infrastructure to make those decisions enforceable and provable.

How we scope

Agree in writing which media types the organization restricts or prohibits, and which systems in the CUI boundary apply those rules.
Confirm the value of the organization-defined parameter for 03.08.07, since the requirement cannot be complete until it is set.
Map the roles that approve exceptions for removable media and record who owns each device that is permitted.

How we build

Configure endpoint controls that block or restrict defined media types, with osquery queries to inventory attached and mounted media.
Deploy Fleet policies as yes or no checks so each device in scope shows whether it passes or fails the media restriction.
Set Wazuh Security Configuration Assessment checks for media-related settings, and extend the policies where the organization's own rules differ.

How we hand over

Deliver the media use policy, procedures and rules of behavior mapped to the examine objects listed for 03.08.07.
Export query results, policy pass or fail reports and audit records that show restrictions were tested and enforced.
Document the owner registry for permitted removable media, so an assessor can trace each device to an identifiable owner.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer to keep media controls current as systems change.
DeployOpen prepares evidence for an independent assessor. Only the assessor or a certification body issues findings or reports.