MP.L2-3.8.8 Shared media

MP.L2-3.8.8 is a 3-point Level 2 requirement that must be MET, not placed on a POA&M. It asks you to prohibit portable storage devices that cannot be traced to an accountable owner.

On this page

What MP.L2-3.8.8 shared media asks for and why it is scored hard

MP.L2-3.8.8 requires you to prohibit the use of portable storage devices that have no identifiable owner, and it carries 3 points under the CMMC scoring methodology. Because it is worth more than 1 point, it cannot be placed on a plan of action and milestones, so it must be MET for your organization to reach Conditional or Final Level 2 status. The requirement is a derived security requirement from NIST SP 800-171 Rev. 2, and it asks for a control, not a document: an assessor will look for a working mechanism that stops untraceable media from being used on in-scope systems.

The risk is simple. A USB drive or external disk with no owner cannot be tied to a person who is accountable for what it carries, so it may contain malicious files, and nobody can be asked to explain how it got onto a system. MP.L2-3.8.8 builds on MP.L2-3.8.7, which governs removable media through a written policy and technical restrictions. Where 3.8.7 asks whether removable media is controlled, 3.8.8 asks whether every device that is used can be traced to an owner who is responsible for its security. A device that passes the 3.8.7 restrictions can still fail 3.8.8 if nobody owns it.

The policy is the easy part. The difficulty is inventory and enforcement: you need a current register of portable storage devices tied to named owners, and technical mechanisms that block unregistered or unowned devices on in-scope systems. Assessors test the mechanisms and the audit records behind them, so the register must match what the endpoints actually report. Confirm with your assessor and your own environment which device classes and endpoints are in scope, and check that your endpoint tooling can report connected removable devices before you write the procedure.

Which systems, devices and teams fall under shared media rules

MP.L2-3.8.8 applies wherever portable storage can touch a system that stores, processes or transmits CUI, so the scope starts with the boundary and works outward to people and devices. Each decision below changes how many endpoints, visitors and vendors must be controlled, and how much evidence the assessor will ask you to produce.

CUI systems inside the boundary

Every system in the assessment boundary that stores, processes or transmits CUI is in scope, including workstations, servers, virtual desktops and build hosts. Your System Security Plan defines this boundary, so the first task is confirming that every host listed there has a documented answer to whether portable storage can connect to it. Ask whether any system is excluded from the boundary and be ready to show why the exclusion holds. Drawing the boundary tightly reduces the endpoints you must control, but a loose or undocumented boundary tends to surface as findings during assessment.

Endpoints and servers with open ports

Any CUI system with a USB port, optical drive or card reader is a place where portable storage can attach, so each one needs either a technical restriction or a documented prohibition. Servers in locked rooms may have fewer exposed ports, but that fact still needs to be confirmed and recorded. Check BIOS settings, device control policies and physical access together, because a port that is blocked in software but open at the hardware level still counts as exposed. Inventory tools help here, since they show which hosts are actually in use.

Personal and visitor devices

Personal phones, laptops and storage drives brought into controlled areas or connected to CUI systems fall under the rule when they have no identifiable owner or an owner outside the program's accountability. Visitor devices are the most common gap because they arrive without a record. Decide whether personal devices are barred from CUI spaces, allowed only in designated areas, or permitted with owner registration. Each choice changes the enforcement effort, the training you deliver and the evidence of visitor screening you must keep.

Third parties who bring media on site

Vendors, maintenance technicians, auditors and integrators who connect their own media to your systems create ownership questions that your contracts must answer. Define in writing who is responsible for any device a third party connects, and require that they register devices or use only media you issue. Without this, the owner definition in your SSP will not match what happens on the floor. Review these terms with counsel as part of subcontractor flowdown, because they are often missed when vendor agreements are first drafted.

Owner definition in the SSP

The meaning of an identifiable owner must be the same in your System Security Plan, your media usage procedures and your rules of behavior. The SSP should name the role accountable for each device, such as the asset custodian or system owner, and state how that link is recorded. If the SSP uses a looser definition than the procedures, an assessor may test the procedures and find the gap. Agree the definition before you write the mechanisms, since every technical control and inventory record depends on it.

Teams that own the controls

Enforcement touches IT operations, facilities, security and the teams that manage visitors and vendors. Each team needs a named responsibility, such as IT maintaining device restrictions, facilities managing visitor entry, and security reviewing audit records. Unclear ownership is one of the most common reasons a prohibition exists on paper but is not applied consistently. Confirm who signs off on exceptions, and who reviews the records that show the rule is working, before the assessment begins.

How an assessor tests the shared media prohibition

This table compares the three things an assessor examines for MP.L2-3.8.8: the written policy, the technical mechanism that enforces it, and the records that show it works. Read each row as a test the assessor runs, the evidence they ask for, and where organizations most often fail. The main takeaway is that a written prohibition alone does not meet the objective, because the assessor needs proof that unowned devices are actually blocked or traced.

Assessment elementWhat the assessor checksEvidence requested and common findings
Single assessment objectivePortable storage devices are prohibited when they have no identifiable owner. The objective is met only when this holds across the assessed system.Confirm the scope covers every in-scope system component. Finding: the prohibition applies to some endpoints but not servers, kiosks or shared workstations.
System use policyThe policy states that unowned portable storage is prohibited and defines what an identifiable owner is.Current, approved policy with version and approval date. Finding: the policy says removable media is restricted but never mentions ownership.
Media usage restriction proceduresProcedures explain how devices are registered to an owner, how unregistered devices are identified, and who responds.Written steps for device registration, exception handling and removal of unowned media. Finding: procedures exist in draft form only, which does not satisfy the final-form evidence standard.
Rules of behaviorUsers acknowledge that they must not connect unowned devices and that they are accountable for devices assigned to them.Signed acknowledgments tied to user accounts. Finding: acknowledgments are missing for contractors or shared-account users.
Mechanism testsThe assessor tests whether technical controls prohibit the use of unowned media on system components, such as device control or endpoint restrictions.Configuration exports or test results showing an unregistered device is blocked. Finding: a policy with no working technical control, so unowned devices still mount.
Audit recordsThe assessor looks for records that show unowned or untraceable devices were detected, investigated and handled.Device connection logs, alerts and closed tickets. Finding: logs show unidentified USB devices with no follow-up or owner assignment.
Owner traceabilityEach device connected to a system must trace to a responsible, accountable owner recorded in an inventory.Asset records linking device serial numbers to owners. Finding: inventories list devices without owners or have not been updated after reassignment.
Interview and walkthroughThe assessor asks administrators and users to demonstrate the process, from connecting a device to the response when an owner cannot be found.Staff can explain the steps and show the tools. Finding: administrators describe the policy correctly but cannot run the detection query.

Implementation steps to prohibit unowned portable storage

This sequence turns the MP.L2-3.8.8 requirement into a working control: every portable storage device is tied to a named owner, unregistered devices are blocked, unknown devices trigger alerts, and the result is tested before an assessor arrives. Each step ends with an artifact that the organization can show as evidence.

  1. Define what counts as an owned device

    Start by writing a short standard that states which devices are in scope (USB flash drives, external hard drives, SD cards, and any other removable storage that can connect to a system component) and what ownership means. Ownership should mean a named, accountable person or function who is responsible for the device's security and can be identified in your records. Security, IT and the system owner should approve the definition. The output is a signed device ownership standard that sets the rules every later step applies.

  2. Build the portable storage asset register

    Inventory every approved portable storage device and record a serial number, device type, the named owner, the business purpose, the systems it may connect to, and the approval date. Discovery can use endpoint inventory from your management tools, plus a manual check of cabinets, desks and loan pools, because devices that were never recorded are the ones the control most needs to catch. The output is an asset register in which each device has exactly one accountable owner, reviewed and signed off by the system owner.

  3. Configure technical restrictions for unregistered devices

    Configure endpoint controls so that removable storage can only be used when its identifier appears on the approved register. Typical methods include device control policies in the endpoint management platform, allow lists based on device serial or vendor and product identifiers, and blocking of mass storage classes on systems that do not need them. Test each policy on a pilot group before broad rollout, and document the configuration baseline. The output is a tested configuration record showing which devices are permitted, which are blocked, and how exceptions are approved.

  4. Set up detection and alerting for unknown devices

    Even with restrictions in place, you need visibility into attempts to connect unregistered media and into devices that appear on endpoints without a register entry. Use endpoint telemetry, inventory queries and alerting rules to flag new removable storage and send those events to the team that handles security alerts. Open-source options such as osquery can schedule queries for USB device history across a fleet, and Wazuh's inventory can support hardware review, but confirm each tool's support for the device events you need in your environment. The output is a documented alert rule set and a sample alert with its triage record.

  5. Write the owner onboarding and offboarding procedure

    Document how a new device is requested, approved, registered and assigned to an owner, and how the owner is trained on their responsibilities. The offboarding half covers return or secure wiping of the device, removal from the register, and removal of its permissions when the owner changes role or leaves. Tie these steps to your personnel and asset processes so the register stays current. The output is a written procedure with a request form, an approval record and an offboarding checklist.

  6. Test the control and retain the results

    Test the control end to end: connect an unregistered device to a test system and confirm it is blocked and generates an alert, connect a registered device and confirm it works, and check that an offboarded owner's device is no longer accepted. Compare the register against endpoint inventory to find gaps. Record the test date, the people involved and the results, and track any findings to closure. The output is a test report with evidence in final form that shows the control operating as the procedure describes.

Evidence that passes the shared media assessment

An assessor tests MP.L2-3.8.8 by checking that the prohibition exists in writing, that a mechanism enforces it, and that the organization can show who owns each device and what happened when an unowned device appeared. The cards below cover the artifacts that prove each part, and each one must be in final form when the assessor reviews it.

Approved device register with owners

A register that lists every portable storage device permitted on in-scope systems, with the serial number or device identifier, the named owner, the business purpose and the date the owner accepted responsibility. The register is the baseline the assessor compares against connection logs. Check that every device in the register has a person accountable for its security, since the assessment objective turns on whether a device can be traced to an owner. Confirm that departed owners are reassigned or the device is retired.

Written policy and rules of behavior

A signed media usage policy that states the prohibition on portable storage devices without an identifiable owner, names who approves exceptions and describes how users declare device ownership. The rules of behavior should be acknowledged by each user who can connect media to in-scope systems. Assessors look for the policy, the procedures that implement it and the acknowledgments. A draft policy does not count, so confirm the approved version and its approval date are recorded.

Configuration exports showing the blocking mechanism

Exports from the endpoint control that blocks or restricts unowned devices, such as device control rules, allow lists keyed to device identifiers or group policy settings. The export should show the rule, the scope of systems it applies to and the enforcement mode. Assessors test the mechanism itself, so a written prohibition with no technical enforcement will not meet the objective. Export the configuration on a current date and keep the change record for later edits.

Device connection and audit logs

Logs that record each portable storage device connection on in-scope systems, including the device identifier, host, user and time, along with any blocked attempts. These logs let an assessor confirm that the prohibition works in practice and that unowned devices were stopped or detected. Confirm that logs are retained long enough to cover the assessment period and that they are protected from alteration. Inventory tools can supply the device data, so check that the source and collection schedule are documented.

Records of unowned device reviews

Dated records showing that each detection of a device with no identifiable owner was investigated, resolved and closed. A record should name the reviewer, the device, the action taken (such as blocking, collection for analysis or disposal), and the link to any incident ticket. Assessors look for a process that runs on a set schedule as well as responses to individual events. If no unowned devices were detected, keep records of the review runs that found none so the review process is still shown.

Keeping evidence current between assessments

Each artifact needs an owner, a review date and a change history. Reconcile the device register against connection logs on a regular cadence, re-export the configuration after every policy change and re-confirm rules of behavior acknowledgments when staff change roles. Store final versions separately from working drafts so that the evidence an assessor sees is the approved record. Ask your assessor or C3PAO how they expect dates and versions to be shown, since the expectations for the assessment cycle are still being set.

Open-source tools that produce shared media evidence

MP.L2-3.8.8 is only satisfied if the organization can show which portable storage devices exist, who owns each one, and that unowned devices are kept off systems. The tools below do not make that decision for you, but they give the evidence needed to show it, from fleet queries and forensic collection to asset registers and endpoint inventories.

Fleet queries with osquery

osquery exposes host state as SQL tables, and its osqueryd daemon can schedule the same query across an entire fleet. Scheduled queries against process, hardware and file data can show which hosts have mounted removable storage and whether any device is present without a matching owner record. Export the query results on a fixed cadence and keep them with your audit records. Its license is Apache-2.0 OR GPL-2.0-only, so confirm which license terms apply to your deployment. Confirm in your own environment whether osquery can block a device, because its role here is detection and reporting.

Forensic hunts with Velociraptor

Velociraptor collects forensic artifacts defined in VQL from endpoints and runs hunts across groups of systems. A hunt can collect device history or attached-device artifacts from many machines at once, and offline machines are scheduled to collect when they reconnect. Each hunt produces a notebook, which gives you a dated record of what was found and where. This is useful when an assessor asks you to show that a specific unowned device was not used, not only that a policy exists. Its license is AGPL-3.0-only, which matters if you modify and distribute it. Confirm your artifact content against the devices you actually need to see.

Peripheral register with GLPI

GLPI's Assets module tracks computers, monitors, software, network equipment, peripherals, printers, phones and racks. Peripherals, including portable storage where you choose to record it, can be entered by hand or pushed automatically by the GLPI Agent through native inventory, which has been built into GLPI since version 10. This gives you the register that links a device to a named owner, which is the core of the requirement. Ownership records, approval and the decision to prohibit unowned media must come from your organization. Its license is GPL-3.0-or-later. Confirm whether your GLPI setup captures removable storage automatically or whether you must add it manually.

Endpoint inventory with Wazuh

The Wazuh Syscollector module gathers hardware, operating system, installed software, network interfaces, running processes, services, users and groups from each endpoint, then stores them in the Wazuh indexer for dashboard reports. Those inventories help you compare what is connected to a system against the owner register and show that inventory is reviewed on a schedule. Syscollector focuses on hardware and software state, so confirm in your environment whether it records removable storage details that you need for this requirement. Its license is GPL-2.0-only. Confirm whether Wazuh can enforce device restrictions in your deployment, or whether that control sits in endpoint policy tools.

What meeting shared media costs in money and effort

This table lists each cost component of meeting MP.L2-3.8.8, who is paid for it, whether it is one-time or recurring, and what moves it up or down. Use it to build a written quote request, since no price or duration is published for this requirement. The main takeaway is that most of the cost is labor for ownership records and alert triage, not software.

Cost componentWho is paid or who spends effortOne-time or recurringWhat drives it up or down
Tooling and licensesSoftware vendor or none if self-hosted open source is usedRecurring if commercial licenses; none for open-source licensesEndpoint count and whether inventory and query tools are commercial or open source (osquery, Wazuh, GLPI are open-source options to confirm against your environment)
Engineering for inventory and detectionInternal engineers or implementation partnerOne-time for setup, recurring for tuningNumber of removable device types to detect, and whether USB connection events are logged on every endpoint
Owner register setup and upkeepAsset owners, IT staff, records keeperOne-time to build, recurring to maintainFleet size, staff turnover, and how often devices are issued, reassigned or retired
Policy and procedure writingInternal compliance lead or outside consultantOne-time, with periodic reviewNumber of systems in scope and whether existing media policy under MP.L2-3.8.7 can be extended
Alert triage and investigationSecurity operations staffRecurringVolume of unregistered device events, alert routing, and staffing hours available for review
Testing of prohibition mechanismsInternal testers or assessment supportRecurring, at each assessment cycleNumber of endpoint builds and whether test results are captured automatically
External review and assessor samplingIndependent assessor (C3PAO for certification), paid by the organizationRecurring at each assessmentQuantity of owner records and audit logs the assessor samples, which depends on scope and environment

Who owns the control, who can prepare it and who must assess it

The organization owns MP.L2-3.8.8. Its leadership must decide that portable storage without an identifiable owner is prohibited, assign an accountable owner for that decision, and make sure the rule is enforced on every system that processes CUI. No outside party can accept that accountability on the organization's behalf. The internal team also runs the daily work that keeps the control true after an assessment, including reviewing alerts when an unregistered device appears and deciding what happens to it.

  • Policy ownership: A written media usage rule that states who may connect portable storage, that devices must have a named owner, and what happens to unowned devices.
  • Owner register: A current list of approved devices with a responsible person for each one, kept up to date as staff join, leave or change roles.
  • Alert response: A documented process for handling detections of unregistered or unowned devices, including who is notified and how the event is closed out.
  • Rules of behavior: Acknowledgments from users that they will not connect unowned media and will report found or unknown devices.
  • Management review: Periodic checks that the register matches what the monitoring tools actually see.

Before engaging any partner, confirm that someone inside the organization can state who owns each approved device and can show an alert that was handled from start to finish.

Where shared media compliance usually breaks down

MP.L2-3.8.8 is short, but assessors test whether the prohibition holds in daily operation, not only on paper. The gaps below share one root cause: the rule depends on knowing who owns each device, and that knowledge decays unless someone maintains it. Each card names a gap and the check that would catch it before an assessment does.

Owner records fall out of date

A device registered to a departed employee is untraceable in practice, even though the record exists. Ownership data in asset tools often lags behind HR changes, contractor offboarding and device reassignment. Check whether each portable device in your inventory has a current, named owner responsible for its security, and whether a leaver's devices are reassigned or retired during offboarding. Ask who reviews these records and how often.

Written prohibition without technical blocking

A policy that bans unowned drives does nothing if endpoints still accept any USB storage device. Assessors look for mechanisms that actually prohibit use, along with the policy that describes them. Confirm which endpoints enforce device restrictions, how those restrictions identify devices with no registered owner, and whether tests show an unregistered drive being refused. Document the test results, not only the intent.

Personal devices never considered

Staff often plug in personal phones, drives and cameras to charge or transfer files, and those devices have no organizational owner at all. Many programs cover only corporate-issued hardware and miss these cases entirely. Check whether your rules of behavior address personal storage, whether endpoints detect unregistered mass storage on any connection, and whether the scope of the requirement is written down with the devices it covers.

Detections logged but never reviewed

Endpoint tools can record every device connection, yet a log nobody reads does not show the prohibition is working. Assessors expect audit records that support the requirement and evidence that someone acts on them. Define who reviews device connection events, how often, and what happens when an unowned device appears. Keep the review record with the date, reviewer and disposition of each alert.

Evidence that exists only as a draft

A procedure marked draft, or a test run that was never signed off, does not count as final evidence. An assessor can only mark the requirement MET when every applicable assessment objective is satisfied with evidence in final form. Before an assessment, confirm that the media policy, procedures, rules of behavior and test records are approved, dated and version controlled, and that they match what the endpoints actually do.

Questions buyers ask about shared media before hiring help

How much effort does MP.L2-3.8.8 take to meet?

The control itself is narrow, but meeting it takes effort in policy, device inventory and proof. The organization must prohibit portable storage devices that have no identifiable owner, and an assessor will look for a written rule, mechanisms that enforce it and records showing it works. Most of the effort sits in the inventory and enforcement work, not the policy text. The amount depends on how many endpoints connect to USB and other removable ports, how many devices are already registered to people, and whether the environment is cloud, on-premises or mixed. Ask any partner to size the work from your asset list and endpoint count, not from a generic estimate.

Can we meet MP.L2-3.8.8 in-house without outside help?

Yes, many organizations do this with internal staff, provided they have an endpoint management or inventory tool, a named policy owner and someone who can run queries across the fleet. The organization owns the control and its evidence in every case. Outside help is most useful where the team lacks endpoint telemetry skills, has no authoritative device register, or needs an independent check before an assessment. An implementation partner can prepare the monitoring and evidence collection, but it does not decide whether the control is met. Only the independent assessor makes that call.

What does the work need from our team?

The work needs four kinds of input from your side:

  • A policy owner who can approve a rule that prohibits unowned portable storage and defines who is accountable for each registered device.
  • An IT or endpoint administrator who can enforce device restrictions and tie removable media to named users.
  • A security engineer who can collect endpoint data and review it for unregistered devices.
  • A records owner who keeps the device register, exception approvals and review logs current.

Without these roles in place, the technical controls will exist but the evidence will not hold up.

How long does it take to meet MP.L2-3.8.8?

The duration depends mainly on fleet size, how well asset records already link devices to owners, and how many staff must approve exceptions. A small environment with clean inventory records can move faster than a large distributed fleet with shared workstations and no device register. Timelines also depend on whether the organization must change endpoint configurations, test restrictions with users and collect several review cycles of evidence before an assessment. Ask a partner for a written timeline based on your inventory and endpoint count, and confirm which dependencies sit with your change board.

Why can't MP.L2-3.8.8 go on a POA&M?

MP.L2-3.8.8 is worth 3 points in the CMMC Scoring Methodology, and the rule does not allow a requirement worth more than 1 point to sit on a plan of action and milestones. It must be MET for the organization to reach Conditional or Final Level 2 status. A plan of action can cover some 1-point gaps, but it cannot carry this control forward while the organization pursues certification. Confirm the current scoring and POA&M rules in the eCFR text of 32 CFR Part 170 before planning, because the program schedule has changed.

What evidence will an assessor expect for shared media?

An assessor will expect the written policy prohibiting portable storage devices without an identifiable owner, procedures that define how owners are assigned, and technical evidence that the prohibition is enforced. Records of device inventories, rules of behavior, audit logs of removable media events and documented exceptions also matter. Under NIST SP 800-171A, the single objective is that use is prohibited when devices have no identifiable owner, so each artifact should show that rule in operation. Drafts do not count, so finalize documents and keep dated records before the assessment.

What should we ask a partner before signing?

Ask for a written scope that names the systems, endpoints and devices covered, and the deliverables for each. Confirm who owns the policy, the device register and the final control decisions. Ask how the partner will use open-source tools such as osquery, GLPI or Wazuh to inventory devices and collect removable media data, and what they will hand over afterward. Ask whether the partner prepares evidence only, and how they keep their role separate from the independent assessor. Request a quote based on the written scope, and confirm what changes would trigger a new quote.

How DeployOpen scopes and prepares shared media evidence

DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, and prepares the systems and evidence that show MP.L2-3.8.8 is met. We do not decide whether the requirement is met, and an independent assessor makes that call.

How we scope

  • The written scope lists every endpoint, server and user group in the CUI environment that can connect portable storage.
  • It names the owner of each removable device and the system use policy that prohibits unowned media.
  • Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

  • We configure endpoint tooling to inventory connected removable storage and record the device serial and assigned owner.
  • We set technical restrictions so that devices without a recorded owner are blocked or flagged for review.
  • We test the blocking mechanisms and keep the test results, so the assessor can check them against the assessment objective.

How we hand over

  • We deliver the written procedure, rules of behavior and device ownership records in final form, not as drafts.
  • We provide audit records and configuration exports that show the prohibition operating across the in-scope systems.
  • We document the test method, the people who ran it and the known gaps, so your team can explain them to the assessor.

How we support

  • Ongoing support, upgrades and continuous testing are available as a retainer after handover.
  • A retainer can cover periodic re-checks of device ownership records and blocking rules as the fleet changes.
  • Your organization keeps ownership of the control, and an independent assessor issues any report or certification.

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.