Current CMMC status — verified August 21, 2026. Phase 1 began November 10, 2025 and, under the original rollout, ran through November 9, 2026. On July 13, 2026, the Department suspended Phase 2 — which had been scheduled to begin November 10, 2026 — along with pending and future implementation milestones. Level 1 and Level 2 self-assessments, SPRS recordkeeping and affirmations, DFARS 252.204-7012, and NIST SP 800-171 Revision 2 remain in force. Nothing about your removable-media obligations changed. What changed is that Phase 2 no longer makes a C3PAO assessment the routine next gate. Select government-led assessments remain available. See the July 13, 2026 Department release.
A CMMC removable media policy has to do more than restrict USB drives. A removable-media decision can touch 11 scored requirements across three control families, worth 27 points on a Level 2 score when all eleven apply — and 22 of those points sit on requirements that cannot be placed on an assessment plan of action. The policy document receives no standalone points. Your implementation and evidence do.
That last sentence is the part almost nobody tells you, and it's the reason this page exists. Read on and we'll show you the exact clause list, the requirement each clause serves, and the four artifact classes assessors compare — plus a Department of Defense Inspector General audit in which six of the ten contractors reviewed had the removable-media deficiency, two of them because policy language did not cover or enforce the actual media path.
What changes the answer: whether you handle Federal Contract Information (FCI) only or Controlled Unclassified Information (CUI); whether removable media touches your in-scope systems at all; and whether you can enforce your rule with a technical setting or only with a signature.
| Key fact | Bottom line |
|---|---|
| 5 points | MP.L2-3.8.7, the requirement that directly names removable media |
| No assessment POA&M | A 5-point failure can't be deferred |
| No universal USB ban | Prohibition and controlled use are both defensible |
Which approach fits — and which doesn't
| If this is you | Start here |
|---|---|
| CUI in scope, removable media is used or possible | The 11-requirement map, then the template |
| CUI in scope, you plan to ban removable media entirely | Model A below — a ban still needs enforcement and evidence; it does not erase the rest of the media lifecycle |
| FCI only, no CUI | One media rule applies to you. Skip to the Level 1 section. |
| A gap assessment or mock already flagged MP.L2-3.8.7 | The evidence section — that's where you're losing |
| You don't yet know whether an asset is in scope | Stop here. Read our CMMC scoping guide first. |
Which removable media model fits your business?
Answer capsule: There are three defensible ways to handle removable media under CMMC Level 2: prohibit it, allow only approved and attributable devices, or run a controlled transfer path for equipment that can't work any other way. NIST SP 800-171 Revision 2 permits prohibition and controlled use. Our third model applies controlled use to a dedicated transfer path for equipment that cannot work any other way. The right one is the narrowest model your business can actually live with and prove.
| Your situation | Default answer | What proves it | The main risk |
|---|---|---|---|
| Nobody can name a legitimate reason to use portable storage | Model A — Prohibit | Endpoint configuration export, denied-device events, a test record, an exception register (even an empty one) | An overbroad block breaks security keys and scanners, so people route around it quietly |
| A few people occasionally need to move files | Model B — Approved, attributable media only | Device register with named owners, approval records, scan logs, check-out records | The register goes stale and a drive walks out with an employee |
| CNC, OT, lab, field, or legacy gear depends on media transfer | Model C — Controlled transfer path | Workflow diagram, dedicated serialized media, custody log, scanning records, SSP treatment | It quietly becomes a permanent undocumented exception |
Pick the model before you write a word of policy. Everything downstream — the clauses, the configuration, the evidence — follows from that one decision.
What does CMMC actually require for removable media?
Answer capsule: CMMC Level 2 does not have one removable media requirement. It has eleven that a removable media decision touches, spread across Media Protection, Access Control, and Maintenance. The requirement that names removable media directly is MP.L2-3.8.7 — "control the use of removable media on system components" — worth five points under the CMMC scoring methodology at 32 CFR § 170.24.
We read 32 CFR § 170.24(c)(2)(i)(B) in full at the eCFR on August 21, 2026 and pulled every point value below out of the rule's own lists — not from a vendor's summary. Title 32 was current as of August 19, 2026 and last amended August 17, 2026. We then cross-checked deferral eligibility against § 170.21(a)(2).
Here is the combined map.
The Removable Media Control Map
| Requirement | What it actually demands | Points | Potentially eligible for an assessment POA&M? | Assessment objectives | Can policy language alone satisfy it? |
|---|---|---|---|---|---|
| MP.L2-3.8.7 | Control the use of removable media on system components | 5 | No | 1 | Partly. The official guidance allows nontechnical controls — but the objective measures use, not the document |
| MP.L2-3.8.3 | Sanitize or destroy media before disposal or release for reuse | 5 | No | 2 | No. Needs sanitization or destruction evidence tied to the media or batch |
| MP.L2-3.8.1 | Physically control and securely store media — paper and digital | 3 | No | 4 | No. Needs physical control and secure storage |
| MP.L2-3.8.2 | Limit access to CUI on media to authorized users | 3 | No | 1 | No |
| MP.L2-3.8.8 | Prohibit portable storage devices that have no identifiable owner | 3 | No | 1 | The policy can define the prohibition, but interviews and practice must show it operates |
| MA.L2-3.7.4 | Check media carrying diagnostic and test programs for malicious code before use | 3 | No | 1 | No. Needs a scanning step |
| MP.L2-3.8.4 | Mark media with CUI markings and distribution limitations | 1 | Yes, if every § 170.21 condition is met | 2 | No. Needs markings where applicable |
| MP.L2-3.8.5 | Control access to media during transport and maintain accountability | 1 | Yes, if every § 170.21 condition is met | 2 | No. Needs transport accountability evidence |
| MP.L2-3.8.6 | Protect CUI on digital media during transport with cryptography unless alternative physical safeguards are used | 1 | Yes, if every § 170.21 condition is met | 1 | No |
| MP.L2-3.8.9 | Protect the confidentiality of backup CUI at storage locations | 1 | Yes, if every § 170.21 condition is met | 1 | No |
| AC.L2-3.1.21 | Limit use of portable storage devices containing CUI on external systems | 1 | Yes, if every § 170.21 condition is met | 3 | Mostly. Two of its three objectives are definition and documentation; the third tests whether use is limited as defined |
| Total | 27 | 6 of 11 locked | 19 |
Point values: 32 CFR § 170.24(c)(2)(i)(B), read August 21, 2026. Deferral eligibility: § 170.21(a)(2). Objective counts are ours, counted line by line from the CMMC Level 2 Assessment Guide, Version 2.13: 19 across all eleven requirements.
The arithmetic that should change how you plan
When all eleven requirements apply, twenty-seven points ride on your removable media decisions. Twenty-two of them, across six requirements, cannot go on an assessment plan of action and milestones. Section 170.21(a)(2)(ii) bars any requirement worth more than one point from a POA&M, with one narrow exception for partially implemented FIPS-validated encryption that doesn't touch a single requirement in the table above.
Do the math on what that means. Conditional Level 2 status requires a score of at least 88 out of 110 — an 80% threshold under § 170.21(a)(2)(i) — which leaves you a total deferral budget of 22 points. Removable media can't spend one dollar of that budget on its six heavy requirements. A single one of them scored NOT MET removes the Conditional path entirely, no matter how strong the other 109 look.
That's the whole reason this control gets more attention than its line count suggests. The policy is small. In an ordinary office environment, enforcement can be cheap. And the six heavy requirements are binary for Conditional status.
The point-to-objective inversion
Look at the objectives column again.
MP.L2-3.8.7 is worth five points and has one assessment objective. AC.L2-3.1.21 is worth one point and has three.
Read AC.L2-3.1.21's three objectives and the reason jumps out. An assessor checks whether the use of portable storage devices containing CUI on external systems is identified and documented, whether limits on that use are defined, and whether use is limited as defined. Two of the three are writing tasks.
So the one-point requirement can demand more definition and documentation than the five-point requirement that directly names removable media. If you've been budgeting your document-writing time by point value, you've been doing it backwards.
One more thing about AC.L2-3.1.21: it is one of five requirements in this group that can be placed on an assessment POA&M, assuming the overall score and every other condition in § 170.21 are met. It is worth one point, and it is not among the six requirements named by ID as ineligible at § 170.21(a)(2)(iii) — those are AC.L2-3.1.20, AC.L2-3.1.22, CA.L2-3.12.4, PE.L2-3.10.3, PE.L2-3.10.4, and PE.L2-3.10.5.
The second ring: requirements your policy decides but doesn't own
These aren't removable media requirements. They're requirements your removable media decision moves, and pretending otherwise would be sloppy. But when you write "we disable USB storage ports," you've just made a claim an assessor can test against these:
- CM.L2-3.4.6 and CM.L2-3.4.7 (5 points each) — least functionality, and restricting or disabling nonessential ports, protocols, and services. This is where port disabling actually gets scored.
- SI.L2-3.14.2, SI.L2-3.14.4, SI.L2-3.14.5 (5, 5, and 3 points) — malicious code protection, keeping it current, and scanning files from external sources. Your scanning station lives here.
- SC.L2-3.13.16 (1 point) — protecting CUI at rest. SC.L2-3.13.11 (5 or 3, partial credit) — FIPS-validated cryptography, if encryption is how you're protecting it.
- AT.L2-3.2.1 and AT.L2-3.2.2 (5 points each) — awareness training and role-based training. Your rules of behavior acknowledgment is training evidence.
- PE.L2-3.10.1 (5 points) — limiting physical access, including to wherever that media cabinet sits.
- AC.L2-3.1.20 (1 point) — verifying and controlling connections to external systems. Worth flagging: this one is a named POA&M exclusion even at one point.
Related reading on our site: the complete NIST 800-171 requirements checklist with all 110 requirements, how SPRS scoring actually works, and the differences among the CMMC levels.
Do you actually need a written removable media policy?
Answer capsule: No CMMC requirement states "write a removable media policy." NIST left policy and procedure controls out of the 110 on the assumption that companies already have them. But the Department's own CMMC Level 2 Assessment Guide directs organizations to write one, and 32 CFR § 170.24(b)(1) lists unofficial and unapproved policies as evidence an assessor cannot accept. The defensible assessment-readiness answer is to have the document, and it has to be approved before you offer it as evidence.
This is the single most useful thing we can tell you, so let's take it apart properly. Three facts, all verifiable, that belong next to each other.
One. The policy isn't one of the 110. NIST built SP 800-171 Revision 2 by tailoring the moderate control baseline and removing controls it expected nonfederal organizations to satisfy without being told to — including the policy and procedure controls. NIST has a name for that category: NFO, defined as controls "expected to be routinely satisfied by nonfederal organizations without specification." Go through the list of 110 requirements yourself. There is no line item that says "have a media protection policy."
Two. The rule names bad policies as evidence that doesn't count. Section 170.24(b)(1) says all evidence must be in final form and not draft, and that unacceptable forms of evidence include working papers, drafts, and unofficial or unapproved policies. That's the only place in the entire scoring section where the word "policies" appears — and it's in the list of things that don't work.
Three. DoD tells you to write one anyway. The official CMMC Level 2 Assessment Guide's Further Discussion for MP.L2-3.8.7 says to write a specific policy for removable media, says it should cover the different media types, and names two things to put in it: limit removable media to the smallest number needed, and scan all removable media for viruses.
Put those together and you get the honest answer. The policy is not the requirement. It's the record of how you decided to meet the requirement. Approved and matching reality, it's the backbone of your evidence package. Downloaded, unsigned, and describing a company you aren't, it is worth exactly nothing — and the rule says so in writing.
The part we'd rather tell you now than have you learn at an assessment
A template you download earns you zero points by itself. Including the one further down this page.
Not one of the eleven requirements in that table is satisfied by a downloaded policy alone. An assessor scores what your machines do, what people do, and what your final records show. We publish the copy-and-adapt template on this page and we'd still rather say that out loud than let you file a Word document and feel finished.
Here's the part that should give you some hope, and it's not a consolation prize.
The document has one job nothing else can do. Look back at AC.L2-3.1.21: two of its three objectives ask whether limits are defined and whether use is documented. You are the one who defines them. Nobody at DoD is going to hand you a list. Write limits that match what your building actually does, and the policy becomes the map for your evidence — every clause pointing at an artifact you can produce. Write aspirational limits that sound impressive, and you have handed an assessor a list of your own failures, in your own words, with your signature at the bottom.
That's the whole game. The policy is easy. Making it true is the work.
The right CMMC provider isn't the same for every contractor — the category you need (a C3PAO, an RPO, an MSSP, a GRC platform, or a CUI enclave) depends on your required CMMC level, whether you handle FCI or CUI, your assessment type, your cloud and IT environment, and your contract timeline. The contract clause sets your level, not a checklist. Because a general answer can't resolve those for you, use The Defense Compliance Report's Find My CMMC Path tool to map your situation to the right provider category before you request quotes — and do not submit CUI, drawings, or sensitive contract details.
The Defense Compliance Report is an independent trade publication and decision resource for CMMC and Defense Industrial Base compliance. We ground material regulatory claims in primary sources and map a contractor's level, CUI scope, assessment type, and timeline to the provider category that fits. Read our methodology and editorial standards.
Policy, procedure, SSP, and evidence do four different jobs
Answer capsule: A CMMC removable media program needs four distinct artifacts. The policy states management's rule. The procedure describes the workflow. The System Security Plan (SSP) explains how the in-scope environment implements the requirement. The evidence proves the implementation actually operated. Assessors compare all four against each other, and mismatches between them are a common source of findings.
| Artifact | Its job | What belongs in it | The failure to avoid |
|---|---|---|---|
| Policy | State the rule and the risk decision management made | Scope, default posture, roles, allowed and prohibited use, who approves exceptions | Stuffing it with tool-specific detail that becomes false the next time you change products |
| Procedure | Tell people how to actually operate the rule | Issue, approve, scan, transport, return, sanitize, report, test | Leaving the real workflow tribal and unwritten |
| SSP | Describe how this environment meets the requirement | Assets, technologies, named responsibilities, inherited or shared controls, evidence pointers | Restating the control text instead of describing your implementation |
| Evidence | Prove the control operated, in final form | Configuration exports, logs, registers, approvals, records, test results | Undated screenshots with no scope, no owner, and no tie to a requirement |
Do not choose between them. The SSP is itself a scored requirement, the policy defines the rule, the procedure makes it operable, and the evidence proves it. If you can only make one true first, make the implementation that produces the evidence — then bring the policy, procedure, and SSP into alignment before you assess.
What goes in a CMMC removable media policy?
Answer capsule: Our copy-and-adapt removable media policy architecture uses 24 clauses covering scope, device definitions, the control model chosen, ownership and approval, CUI handling, scanning, transport, storage, marking, logging, sanitization, incidents, exceptions, training, and review. Each operating clause should name an owner or point to the record that makes it provable.
Below is the architecture. We've mapped each clause to the requirement it serves, so you can see exactly why it's there rather than trusting us. Bracketed fields are yours to fill.
Document control block
Policy title · organization · policy owner · approving authority · effective date · version · next review date · superseded version · related SSP section · related procedures.
Unglamorous — and Section 170.24(b)(1) makes approval status consequential. Draft, unofficial, and unapproved policies are not acceptable evidence.
The clause list
| # | Clause | What it has to establish | Serves |
|---|---|---|---|
| 1 | Purpose | Why the rule exists: controlling media use and reducing unauthorized CUI transfer and malicious code | Context for all |
| 2 | Scope | People, facilities, systems, endpoints, specialized equipment, and media covered | MP.L2-3.8.7 |
| 3 | Definitions | Removable media, portable storage device, CUI, approved media, owner or custodian, controlled area, exception | MP.L2-3.8.7, MP.L2-3.8.8 |
| 4 | Roles and responsibilities | Policy owner, IT or security, media custodian, users, incident contact, approving authority | MP.L2-3.8.2 |
| 5 | Default posture | Model A, B, or C, stated in one unambiguous sentence | MP.L2-3.8.7 |
| 6 | Approved media types | Which device categories are permitted — or that none are | MP.L2-3.8.7 |
| 7 | Prohibited media and uses | Unknown-owner devices, personal storage, unapproved types, unauthorized systems, personal use | MP.L2-3.8.8 |
| 8 | Authorization and issuance | Who approves, who issues, who revokes, and on what business justification | MP.L2-3.8.2 |
| 9 | Identifiable ownership | Owner or custodian of record, project or organization attribution, asset or serial identifier | MP.L2-3.8.8 |
| 10 | Permitted systems and users | Named roles, endpoint groups, specialized equipment, least privilege | MP.L2-3.8.2, MP.L2-3.8.7 |
| 11 | CUI storage conditions | When CUI may and may not be placed on media at all | MP.L2-3.8.1 |
| 12 | Encryption and transport conditions | Conditional language tied to transport, not a blanket mandate | MP.L2-3.8.6, SC.L2-3.13.11 |
| 13 | Malware scanning | Where scanning happens, when, whose signatures, and what happens on a hit | MA.L2-3.7.4, SI.L2-3.14.5 |
| 14 | Inventory and labeling | The media register, identifiers, owner, status, and CUI marking where applicable | MP.L2-3.8.4; supports MP.L2-3.8.8 |
| 15 | Check-out, check-in, and storage | Custody, locked storage, overdue and lost media | MP.L2-3.8.1, MP.L2-3.8.5 |
| 16 | External systems and third parties | Vendor, customer, partner, and government-furnished media | AC.L2-3.1.21, MA.L2-3.7.4 |
| 17 | Legacy and specialized workflow | The controlled transfer path, if you have one | MP.L2-3.8.7 |
| 18 | Logging and monitoring | Device events, transfer records, alerts, retention, who reviews them | AU.L2-3.3.1 |
| 19 | Sanitization and destruction | Approved methods by media type, authorization, and records | MP.L2-3.8.3 |
| 20 | Lost, found, and suspicious media | Do not insert it. Report it. Where it goes. | MP.L2-3.8.8 |
| 21 | Backups on removable media | How backup media is handled and where it's stored | MP.L2-3.8.9 |
| 22 | Training and rules of behavior | Initial and recurring instruction, plus acknowledgment | AT.L2-3.2.1 |
| 23 | Exceptions | Owner, business reason, compensating controls, approval, and an expiration date | MP.L2-3.8.7 |
| 24 | Testing and review | Functional test cadence, review triggers, evidence owner | CA.L2-3.12.1 |
Copy-and-adapt CMMC removable media policy template
Template status: Editorial drafting language, not government text and not a substitute for implementation. Delete every option that does not match reality. A downloaded template earns no points by itself.
Document control. Policy title: [Removable Media Policy] · Organization: [legal name] · Policy owner: [role] · Approving authority: [role] · Effective date: [date] · Version: [version] · Next review date: [date] · Related SSP section: [section] · Related procedures and records: [list].
1. Purpose. [Organization] controls the use of removable media to reduce unauthorized movement or disclosure of CUI, prevent malicious code from entering organizational systems, preserve accountability for approved media, and ensure media is protected through issue, use, transport, storage, sanitization, destruction, and retirement.
2. Scope. This policy applies to [employees, contractors, temporary personnel, facilities, systems, endpoints, networks, cloud-connected workstations, CNC/OT/lab/test equipment, government-furnished equipment, and other assets] within or connected to the CMMC Assessment Scope, plus any removable media used to process, store, transmit, back up, diagnose, test, or transport CUI.
3. Definitions. “Removable media” means [approved definition and included media types]. “Portable storage device” means a storage component that can be inserted, attached, and easily removed. “Approved media” means media authorized by [role], recorded in the media register, assigned to an identifiable owner or custodian, and configured or handled under this policy. “Controlled area,” “CUI,” “owner,” “custodian,” “exception,” and “specialized asset” have the meanings stated in [SSP, procedure, or glossary].
4. Roles and responsibilities. [Executive role] approves this policy. [IT/security role] configures and tests technical controls, maintains logs, and investigates alerts. [Media custodian] issues, inventories, stores, receives, and retires approved media. Users follow the approved workflow and report lost, found, unknown, or suspicious media immediately. [Exception authority] approves and expires exceptions. [Incident role] owns escalation and reporting.
5. Default posture. Insert one of the three model clauses in the next section and delete the other two. The chosen clause must match the configuration and workflow that actually operate.
6. Approved media types. Only [device types, media formats, manufacturers, device classes, encrypted models, or none] may be used. Approval of a media type does not approve every individual device. Each permitted device must meet the authorization, ownership, inventory, scanning, transport, and custody conditions that apply to its use.
7. Prohibited media and uses. The following are prohibited: devices with no identifiable owner; [personally owned storage]; unapproved or unregistered devices; media obtained from an unknown source; media used on unauthorized systems; personal use; bypassing device-control settings; sharing an assigned device without approval; and any use outside the business purpose recorded for the device. The prohibition on personally owned media is [Organization’s] risk decision, not a statement that NIST universally bans every personally owned device.
8. Authorization, issuance, and ownership. [Role] approves removable-media use only for a documented business purpose. The media custodian records the device identifier, serial number or other unique identifier, media type, owner or custodian, approved users, approved systems, purpose, issue date, status, and return or retirement history. Authorization ends when the business purpose ends, the user changes role, the device is lost, the approval expires, or [other trigger] occurs.
9. Permitted systems and users. Approved media may be used only by [roles or named users] on [systems, endpoint groups, scanning stations, CNC/OT/lab equipment, or other approved assets]. Use on external systems is [prohibited / limited to defined systems and conditions]. Any allowed use of portable storage devices containing CUI on external systems must be identified, documented, defined, and limited as stated in [procedure/SSP section].
10. CUI storage and access. CUI may be placed on removable media only when [business condition] exists and [role] authorizes it. Access is limited to authorized users. Media containing CUI must be physically controlled and securely stored in [location or container] when not in use. CUI may not be copied to media merely for convenience.
11. Marking. Media containing CUI must carry the applicable CUI markings and distribution limitations required by [contract, agency guidance, and organizational marking procedure]. Ownership, project, or custodian labels may be added to support accountability, but they do not replace required CUI markings.
12. Malware inspection. Media containing diagnostic or test programs must be checked for malicious code before use on systems within the CMMC Assessment Scope. [Organization] also requires [all approved removable media / media from external sources / specified categories] to be scanned at [managed scanning station or approved endpoint] using [tool] with current protections. A detection is isolated and handled under [incident procedure]; the media is not connected to the destination system until cleared.
13. Transport and cryptography. CUI on digital media during transport must be protected by [FIPS-validated cryptography] unless [Organization] uses the documented alternative physical safeguards in [procedure/SSP section]. Transport also requires authorized custody, accountability, [locked container / hand-carry / courier / receipt], and a record of release and receipt. Product language such as “AES-256,” “FIPS capable,” or “FIPS compliant” is not accepted as validation evidence by itself.
14. Check-out, check-in, and storage. The media custodian records each issue, transfer, return, overdue status, loss, and change of custody. Approved media is stored in [locked cabinet, safe, controlled room, or other location] accessible only to [authorized roles]. Returned media is [scanned, inspected, reconciled, sanitized, or reissued] under the operating procedure.
15. External, customer, vendor, and government-furnished media. Media received from a customer, vendor, partner, government activity, or maintenance provider is treated as untrusted until ownership, purpose, authorization, and required scanning are established. Diagnostic and test media follows the MA.L2-3.7.4 inspection workflow. CUI-bearing media is not connected to an external system unless the limits required by AC.L2-3.1.21 are documented and enforced.
16. Legacy, CNC, OT, laboratory, and test-equipment workflow. Where direct technical enforcement is not feasible, transfers use [dedicated serialized media], [named personnel], [managed scanning or transfer station], [write protection or one-way transfer where feasible], [defined source and destination], [custody records], and [periodic end-to-end testing]. Specialized equipment does not disappear from scope; its Level 2 treatment is documented in the SSP, asset inventory, network diagram, and risk-based policies and practices.
17. Logging and monitoring. [Organization] records [device identity, user, endpoint, timestamp, allowed or denied action, file-transfer event, alert, approval, and exception] to the extent supported by the selected architecture. [Role] reviews [logs/registers] every [cadence] and retains them for [period aligned to evidence-retention and contractual requirements].
18. Sanitization, destruction, and release for reuse. Before disposal, return, warranty replacement, lease return, transfer, or release for reuse, media containing CUI must be sanitized or destroyed using the method assigned to that media type in [sanitization standard/procedure]. [Organization] uses NIST SP 800-88 Revision 2 and [IEEE 2883, NSA specifications, or an organization-approved standard] to select and document methods. [Role] authorizes the action, and the sanitization or destruction record identifies the media, method, date, performer, verifier if required, and final disposition.
19. Lost, found, unknown, or suspicious media. Users must not insert unknown or found media into any organizational system. They report it to [contact] and deliver it to [help desk/security location] under [procedure]. Lost approved media, suspected unauthorized copying, malware detections, or policy bypasses are reported immediately and handled under [incident response procedure].
20. Backup media. Removable backup media containing CUI is inventoried, access-controlled, protected during transport, and protected at storage locations. Offsite storage, vendor custody, encryption or physical safeguards, restoration testing, rotation, sanitization, and retirement are documented in [backup procedure and SSP section].
21. Training and rules of behavior. Before receiving access or media, users are trained on approved and prohibited use, unknown-media handling, scanning, transport, custody, CUI marking, incident reporting, and exceptions. Users acknowledge [rules of behavior or policy] at [initial and recurring cadence]. Training records are retained by [role].
22. Exceptions. An exception requires a named owner, business reason, affected systems and media, CUI determination, risk analysis, compensating controls, approval by [role], start date, expiration date, and review before renewal. An exception does not make a requirement disappear and does not move a non-deferrable requirement onto an assessment POA&M.
23. Testing. [IT/security role] tests representative allowed, denied, known-safe but deliberately unapproved, revoked, and expired-device cases every [cadence] and after material changes. Found or truly unknown media is never used for testing. Model C environments add a witnessed end-to-end transfer test. Results identify the scope, configuration, expected outcome, actual outcome, tester, date, evidence location, and remediation owner.
24. Review and approval. This policy is reviewed every [cadence] and after material changes to contracts, CUI scope, architecture, tooling, workflows, service providers, incidents, or assessment findings. Superseded versions are retained under [records policy]. Approval: [name/role/signature/date].
Choose one default-posture clause for the template
Editorial drafting language, not government text. Adapt it.
Model A: "Removable storage is prohibited on systems within the CMMC Assessment Scope unless a documented, time-limited exception is approved by [role]. The organization technically blocks removable-storage device classes and records attempted use."
Model B: "Only removable storage issued or approved by [role], recorded in the media inventory, assigned to an identifiable owner or custodian, and used for an approved business purpose may be connected to authorized systems."
Model C: "Transfers to or from designated [CNC / OT / laboratory / legacy] equipment must use the approved transfer path, dedicated inventoried media, named personnel, required scanning, custody records, and the safeguards documented in the SSP and associated procedure."
Five clauses that must stay conditional
This is where good templates go wrong. Do not turn your implementation preference into a fake universal requirement, because an assessor will hold you to your own words.
- "All media must be encrypted." Too broad unless you're deliberately adopting it as an organizational standard. The encryption requirement in MP.L2-3.8.6 is scoped to CUI on digital media during transport.
- "All USB ports must be disabled." This confuses the connector with the storage function. A smart-card reader is not removable media.
- "Personal media is prohibited by MP.L2-3.8.8." It isn't. 3.8.8 prohibits devices with no identifiable owner. Prohibiting personal media is a good organizational rule — own it as your decision, don't attribute it to NIST.
- "CNC media is exempt." Too broad. A CNC or other specialized asset may receive specialized-asset treatment under § 170.19, but the asset, data flow, and risk-based safeguards still have to be scoped and documented. Document the control path instead.
- "We use FIPS-capable drives, so we're compliant." Product capability isn't evidence. See the encryption section.
Turn the template into an evidence plan
Copy only the clauses that match reality, then use our CMMC Readiness Checklist to map the remaining control families, point values, POA&M eligibility, and evidence around them. The checklist asks for no CUI and does not depend on hiring anyone.
Use the CMMC readiness checklist →
Do not enter or email CUI, drawings, contract numbers, credentials, device serial numbers, network diagrams, or sensitive technical details.
Can you just ban USB drives?
Answer capsule: Yes, and for many small office-based defense contractors a ban is the cheapest defensible answer. But a ban does not reduce eleven requirements to zero. You still have to make the prohibition operate, prove it, and separately handle disposal, marking, transport, backups, and diagnostic media where those requirements apply. A written ban with open storage access and no operating evidence is a finding waiting to happen, not a finished control.
NIST SP 800-171 Revision 2's discussion for 3.8.7 is unusually flexible. It contemplates restricting or prohibiting flash drives and external hard disks. It says organizations can use technical and nontechnical controls — policies, procedures, and rules of behavior. It mentions physical cages on workstations. It mentions limiting use to approved devices, including devices provided by the organization and devices that are not personally owned. It mentions prohibiting writeable portable devices by removing write capability.
That's four different architectures the source contemplates in one paragraph. There is no single mandated answer here, and anyone telling you there is hasn't read the source.
Model A — Prohibit removable storage
Best for: cloud-first or office environments where nobody can articulate a real business need.
Block the removable-storage device class. Not every device that uses a USB connector — that's how teams break smart-card readers, security keys, scanners, and label printers, and it's how shadow exceptions get born. Test both halves: that storage is blocked, and that the peripherals you need still work.
Write the exception process even if the register stays empty. An exception path that exists and is never used is part of the control. An exception that happens informally because there was no path is a finding.
Directly addresses when implemented and evidenced: MP.L2-3.8.7 and MP.L2-3.8.8; it addresses AC.L2-3.1.21 when the prohibition covers portable storage containing CUI on external systems. Doesn't touch by itself: MP.L2-3.8.3, 3.8.4, 3.8.5, 3.8.6, 3.8.9, or MA.L2-3.7.4. Those requirements need separate treatment wherever you have retired media, removable backups, transport, or vendor diagnostic media.
Model B — Approved, attributable media only
Best for: mixed environments with occasional legitimate transfer needs.
Organization-issued or approved devices only. Every device has an owner or custodian of record. Allowlist by device identity where your tooling supports it. Scan on introduction. Restrict read and write where the use case allows. Log connections. Check devices out and back in.
Directly addresses when implemented and evidenced: MP.L2-3.8.7 and MP.L2-3.8.8, and it supports MP.L2-3.8.2, MP.L2-3.8.4, and MP.L2-3.8.5 when CUI is on the media and those lifecycle conditions apply. Ongoing cost: the register. Let it go stale, and the model loses the attribution evidence it depends on.
Model C — Controlled transfer path
Best for: machine shops, plants, labs, test equipment, and field systems where media transfer is the only way the work gets done.
A dedicated pool of serialized devices. A named custodian and a named user list. A managed transfer or scanning station. A defined route. Locked storage and a custody log. Write protection or one-way transfer where feasible. A periodic end-to-end walkthrough test.
Directly addresses when implemented and evidenced: MP.L2-3.8.7; it addresses AC.L2-3.1.21 when the controlled path covers portable storage containing CUI on external systems, plus MA.L2-3.7.4 when the station checks media containing diagnostic or test programs before use. How it fails: it stops being a controlled workflow and becomes a permanent informal exception that nobody has looked at in two years.
DoD already showed what a satisfied objective can look like
This worked example sits in the official Level 2 Assessment Guide for MP.L2-3.8.7. It is an example, not the only acceptable architecture.
The guide's MP.L2-3.8.7 example combines four elements: organization-issued USB drives, work-only use, a separate scanning computer, and current antivirus before a drive reaches the network. Its MP.L2-3.8.8 example uses a found parking-lot drive to show the other half of the program: do not connect ownerless media, and turn it over to the help desk.
Read those examples side by side and the shape of one defensible implementation is obvious. Issued devices. A scanning step. A written rule people have actually been told about. A place to hand in the mystery drive.
What the rule permits versus what we'd recommend
Separating these two is how you avoid writing checks your evidence can't cash.
| Question | What the source says | What we recommend |
|---|---|---|
| Must all removable media be banned? | No universal ban appears in 3.8.7. Restriction, prohibition, and approved-device approaches are all contemplated | Ban storage classes where there's no business need. It's the cheapest thing to prove |
| Can personal drives be allowed? | 3.8.8 requires an identifiable owner. The 3.8.7 discussion offers non-personally-owned devices as an example of controlled use | Prohibit personally owned storage on CUI systems — and say plainly in the policy that this is your risk decision, not a NIST mandate |
| Must every approved drive be encrypted? | Not as a blanket rule. Encryption is specifically triggered for CUI on digital media during transport, unless alternative physical safeguards protect it | Encrypt portable CUI media where feasible, but don't write a universal mandate you can't evidence |
| Is a USB mouse or keyboard in scope? | These requirements address media and portable storage devices, not every peripheral using a USB connector | Define your device categories explicitly in the policy so the question never comes up in an interview |
How do you enforce a removable media policy technically?
Answer capsule: Technical enforcement should implement the exact decision the policy made: block the storage class, allow only approved devices or users, make media read-only, require an approval event, or log permitted transfers. Blocking every USB function indiscriminately is an overcorrection that breaks legitimate peripherals and pushes users toward workarounds.
| Control option | What it does | Best fit | Evidence it produces |
|---|---|---|---|
| Block removable-storage device class | Denies storage while leaving other peripheral classes alone | Model A | Policy or configuration export, blocked-device event, test record |
| Allowlist approved device identity | Permits only registered devices or serials | Model B | Allowlist export, device register, allowed and denied logs |
| User or endpoint-group authorization | Limits use to designated people or machines | Models B and C | Group membership, policy assignment, approval record |
| Read-only or write block | Allows controlled reading, or prevents copying out to writable media | Specific business cases | Configuration plus a read/write test |
| Encryption enforcement | Blocks use unless the protection condition is met | CUI transport | Configuration plus validation evidence |
| Logging and alerting | Records device connection, identity, user, endpoint, action | All models | Event sample, retention and review record |
| Physical port control | Prevents connection where software control isn't available | Legacy and OT | Photographs, inventory, walkthrough, test |
| Managed transfer station | Centralizes scanning and controlled movement | Model C | Architecture, configuration, scan records, workflow test |
Platform examples worth knowing, none of which we endorse: Microsoft Intune or Group Policy device installation restrictions, endpoint detection and response device-control modules, data loss prevention file rules, Linux USBGuard, physical port blockers and lockable cages, and a dedicated scanning workstation.
A capability existing in a product you own is not evidence. The evidence is that the setting is enabled, correctly scoped to the right endpoints, and currently operating.
Our recommended configuration-drift cadence is quarterly: does the policy assignment still reach every intended endpoint, do exception groups contain only approved users, are retired devices removed from the allowlist, are logs still being retained and reviewed, do newly deployed endpoints inherit the rule, and do your approved peripherals still function? The rule does not prescribe that quarterly cadence; we do.
What will an assessor actually examine, ask, and test?
Answer capsule: Assessors examine documents, interview people, and test mechanisms. For MP.L2-3.8.7 the official assessment objects include the media protection policy, system use policy, procedures addressing media usage restrictions, the system security plan, rules of behavior, system design documentation, configuration settings, and audit logs — plus interviews with personnel responsible for media use, and testing of the mechanisms that restrict or prohibit media use on systems.
That last item is where programs fall apart. The document review is the easy part.
| Method | What gets pulled | What you should have ready |
|---|---|---|
| Examine | Media protection policy, system use policy, media usage procedures, SSP, rules of behavior, design and configuration documentation, audit records | Final approved documents, correct versions, scope labels, named artifact owners, an evidence index |
| Interview | Personnel with media-use responsibilities, information security personnel, system and network administrators | A consistent story about what's allowed, who approves, what happens with unknown media, how exceptions expire |
| Test | Organizational processes for media use; mechanisms restricting or prohibiting media use on systems or system components | A repeatable functional test with results, covering both allowed and denied cases |
Six of ten contractors had this deficiency. Here's exactly how.
We read DODIG-2019-105, "Audit of Protection of DoD Controlled Unclassified Information on Contractor-Owned Networks and Systems," in full. The report is dated July 23, 2019 and was publicly released July 25. It is a detailed government record of how removable-media controls failed in the field.
The DoD Office of Inspector General assessed ten defense contractors — nine drawn from a nonstatistical sample of 26 out of 12,075 contractors holding DoD contracts worth $1 million or more, plus one follow-up from a prior audit. The audit was prompted by 248 security incidents reported by 126 contractors to the DoD Cyber Crime Center between March 2015 and June 2018.
Six of the ten had the removable-media deficiency. The report identifies Contractors A, B, and I as compliant on this point; Contractor B's implementation details are redacted in the public table, and Contractor C is not listed in this removable-media finding. Here is why each listed contractor failed, from the report.
| Contractor | What they did | Why it failed |
|---|---|---|
| D | Let users export CUI to any device and relied on users to encrypt it. The system administrator said the information wasn't "sensitive enough" to require encryption | No safeguard, and that sensitivity judgment wasn't theirs to make |
| E | Limited USB drives and external hard drives to company-issued devices — but did nothing about CDs and DVDs — and relied on its acceptable-use policy to limit other devices, putting the burden on the user. Argued discs were low risk because of low capacity | OIG's response was blunt: discs can still be used to steal or compromise CUI, so restricting them is also necessary. This is the "we have a policy" failure |
| F | Couldn't encrypt because the equipment used with the devices didn't support it | The hardware limitation did not eliminate the requirement; another compliant safeguard was still needed |
| G | Allowed any device, citing the cost of replacing already-deployed drives. Called it a risk-based decision — but had no formal risk assessment of that decision | An undocumented risk decision is not a control |
| H | Still allowed CUI on any removable media with no technical safeguards. Had identified a tool but couldn't deploy it until a server upgrade | Repeat finding from a prior audit |
| J | Had policies requiring the right behavior but had not implemented tools to enforce them | The second "we have a policy" failure |
Now the two public implementation descriptions from contractors the table lists as compliant, because this is the part that's actually useful:
- Contractor A stored removable media received from the requiring activity in locked safes, only put information on media when it needed to hand-deliver it, and monitored how much information was being stored on removable media using anomaly detection.
- Contractor I issued removable media devices to specific named personnel, and only those individuals were authorized to store information on them — which meant the company could identify who was responsible if an incident occurred and begin tracking it. That is MP.L2-3.8.8's identifiable-owner requirement, done correctly before the current CMMC rule existed.
What this data is and isn't. Ten contractors. A nonstatistical sample. Fieldwork in 2018 and 2019, assessed against NIST SP 800-171 Revision 1, before CMMC existed. It is not a CMMC pass-rate statistic and we won't present it as one. What it is: a detailed public record of how this control failed, published by the government, and two of the six deficiencies involved policy language that did not cover or enforce the actual media path.
The evidence package
Assemble these before you self-assess, not after somebody asks:
- Final signed policy with version history
- Operating procedure
- SSP section mapping MP.L2-3.8.7 and MP.L2-3.8.8 to actual assets and mechanisms
- Media inventory: device ID, owner or custodian, status, approved use, issue and return history
- Approved-user and approved-system list
- Endpoint or device-control configuration export
- Sample allowed and denied device events
- Scanning procedure and a recent scan record
- Approval and exception tickets, including expiration dates
- Training record and rules-of-behavior acknowledgments
- Transport records and encryption or physical-safeguard evidence where triggered
- Sanitization or destruction records
- Lost-and-found media procedure
- Current functional test script and its results
- An evidence index tying each artifact to the objective it supports
The six-step functional test
Run it, record it, keep it. This single artifact separates a tested program from a hopeful one.
- Use a known-safe test device that is deliberately unapproved in the management system, and connect it to a representative in-scope endpoint. Do not use found or truly unknown media for this test.
- Confirm the expected behavior — blocked, read-only, quarantined, or routed to an approval path.
- Insert an approved device and confirm only the intended operation is permitted.
- Confirm the event appears in the log or record where your SSP says it will.
- Confirm a user can explain, unprompted, the lost-and-found and exception process.
- Test a revoked or expired device and confirm access no longer works.
For Model C, add a witnessed end-to-end transfer from the managed station to the legacy asset and back, including scanning, custody, and completed records.
Every artifact should answer six questions: which requirement it supports, what scope it covers, who owns it, when it was captured or approved, whether it's final, and whether the result can be reproduced.
The full NIST SP 800-171 Revision 2 baseline is 110 requirements across 14 families. A removable-media decision can touch eleven of them. For the whole board, use the complete NIST 800-171 requirements checklist or the CMMC Level 2 checklist.
Does CUI on removable media have to be encrypted?
Answer capsule: CMMC does not require every removable device to be encrypted. MP.L2-3.8.6 requires cryptographic mechanisms to protect CUI stored on digital media during transport unless alternative physical safeguards protect it, and SC.L2-3.13.16 covers CUI at rest. When cryptography is the mechanism protecting CUI confidentiality, SC.L2-3.13.11 requires that it be FIPS-validated.
Three different situations, three different answers. Collapsing them into one produces the wrong answer.
| Situation | The answer | Requirement |
|---|---|---|
| Approved media is used inside a controlled area and isn't transporting CUI anywhere | Controlled use is still required. A universal encryption mandate doesn't arise from 3.8.7 by itself | MP.L2-3.8.7, MP.L2-3.8.8 |
| Digital media containing CUI is transported, especially outside a controlled area | Use cryptography, unless qualifying alternative physical safeguards protect it — and maintain transport accountability either way | MP.L2-3.8.5, MP.L2-3.8.6 |
| Cryptography is the mechanism protecting CUI confidentiality | The deployed module must be FIPS-validated | SC.L2-3.13.11 |
"FIPS capable," "FIPS compliant," and "AES-256" are not evidence. The evidence is a validated cryptographic module with a certificate, a version, an operational status, and a configuration that match what you actually deployed. A product family name and an algorithm claim prove nothing on their own. We cover how to check that properly on our CMMC FIPS 140-2 requirements page. FIPS 140-2 modules remain accepted for new systems through September 21, 2026; after that, the NIST Cryptographic Module Validation Program moves their certificates to the Historical list. Federal agencies may continue using them in existing systems, but should not procure them for new systems. If you're buying encrypted drives this quarter, read that before you buy.
The alternative physical safeguard path is real, and it is not a waiver. MP.L2-3.8.6 itself offers it. A locked container with authorized custody during transport is a legitimate implementation. NIST SP 1334, the current NIST guidance on portable storage in operational environments, says the same thing. But you have to define the safeguard, operate it, and record it — writing "legacy exception" in a policy is not a physical safeguard.
How does removable media change your CMMC scope?
Answer capsule: A removable device that processes, stores, or transmits CUI is a CUI Asset within the Level 2 assessment scope under 32 CFR § 170.19(c). An endpoint that is capable of handling CUI but is not intended to may be treated as a Contractor Risk Managed Asset — but only when policy, procedures, practices, inventory, and SSP treatment actually support that claim.
Ask these separately, because the answers differ:
- Does the removable device itself hold CUI?
- Does the endpoint read, write, process, or transmit CUI through it?
- Does anything in the chain provide a security function for CUI?
- Is the endpoint capable of handling CUI but deliberately prevented from doing so?
- Is the target asset specialized equipment — operational technology, industrial IoT, government-furnished equipment, a restricted information system, or test equipment?
| Asset category | Removable-media example | What must be documented |
|---|---|---|
| CUI Asset | A USB drive holding CUI; an endpoint reading or writing CUI to it | Asset inventory, SSP, network diagram, assessed against applicable Level 2 requirements |
| Security Protection Asset | The device-control server or logging platform protecting in-scope endpoints | Inventory, SSP, network diagram, assessed against requirements relevant to the capability it provides |
| Contractor Risk Managed Asset | An endpoint that could mount storage but isn't intended to handle CUI because policies, procedures, and practices prevent it | Inventory, SSP, network diagram, documented treatment; if the documentation or other findings raise questions, an assessor may conduct a limited check |
| Specialized Asset | CNC, OT, IIoT, government-furnished equipment, test equipment | Inventory, SSP, network diagram, risk-based policies and practices |
| Out-of-Scope Asset | An asset unable to process, store, or transmit CUI, not providing security protection, and physically or logically separated from CUI assets | A justification of that inability and separation — and it must not actually be doing a CUI media workflow |
Here's the sentence to write on the wall: a policy can support a scope classification only when the configuration, the workflow, and the user behavior make the policy true. It cannot convert an endpoint that actually handles CUI into an out-of-scope asset. Scope arguments often collapse under exactly one question — "so how does the program get to the machine?"
Full asset-category treatment lives on our CMMC scoping guide. Don't finalize this policy until scope is settled.
Machine shops, CNC, and legacy equipment
Answer capsule: A CNC controller or legacy machine that depends on removable media needs a controlled transfer architecture, not an informal exception. NIST published guidance for exactly this problem in September 2025 — SP 1334, "Reducing the Cybersecurity Risks of Portable Storage Media in OT Environments" — recommending write protection, disabled autorun, disabled or physically blocked ports, encryption, and hash verification when moving files.
SP 1334 is a NIST National Cybersecurity Center of Excellence publication, finalized September 30, 2025. It is not a CMMC document and it doesn't claim to be. The publication does not map itself to CMMC, so we did the crosswalk below.
NIST SP 1334, translated into CMMC points
| What NIST SP 1334 recommends | Control type | The CMMC requirement it serves | Points |
|---|---|---|---|
| Policies enforcing purchasing, authorization, and management of organization-owned media; treat media from other sources as untrusted | Procedural | MP.L2-3.8.7, MP.L2-3.8.8 | 5, 3 |
| Store media in a physically secure location where only authorized individuals have access | Physical | MP.L2-3.8.1, MP.L2-3.8.2 | 3, 3 |
| Inventory and label approved media — who may use it, which system it may be used on, its purpose | Physical | Supports MP.L2-3.8.7 control and MP.L2-3.8.8 ownership evidence; supports MP.L2-3.8.4 only when the label also carries applicable CUI markings and distribution limitations | 5, 3 (+1 when applicable) |
| Disable unnecessary ports — logically through BIOS, operating system, or group policy, or physically with port locks, epoxy, or locking cabinets | Technical | MP.L2-3.8.7, plus CM.L2-3.4.6 and CM.L2-3.4.7 | 5 (+5, +5) |
| Write protection when files only need to be read | Technical | MP.L2-3.8.7 | 5 |
| Disable Autorun | Technical | CM.L2-3.4.6, SI.L2-3.14.2 | 5, 5 |
| Encrypt data stored on portable media | Technical | SC.L2-3.13.16 at rest; SC.L2-3.13.11 when cryptography protects CUI confidentiality | 1, 5 or 3 |
| Use encryption or a locked container to transport devices; perform hash or checksum verification when transporting files | Transport | Encryption or the physical safeguard serves MP.L2-3.8.6; custody and accountability serve MP.L2-3.8.5. Hash verification is an operational integrity measure, not a substitute for either requirement | 1, 1 |
| Sanitize before disposal, with monitoring, review, approval, tracking, and documentation | Disposal | MP.L2-3.8.3 | 5 |
The mapping is ours, not NIST's. SP 1334 does not reference CMMC. SP 1334 uses the phrase "FIPS-certified algorithm"; CMMC evidence under SC.L2-3.13.11 turns on a FIPS-validated cryptographic module, not an algorithm label alone.
The practical value: if a NIST publication recommends a port lock on a machine you can't patch, and the same action can support a five-point CMMC requirement, you have both the technical justification and the compliance rationale in one line item for your capital request.
Start with the data flow, not the policy
Map it before you write anything: where the file originates, whether it's CUI, the workstation of origin, the transfer or scanning station, the device, the physical path it travels, the machine, the return path, and what happens to the copy afterward.
Then design the pattern: one small pool of serialized devices, a named custodian, a managed transfer station, scanning on introduction, read-only or one-way transfer where feasible, locked storage, a checkout log, a defined source and destination, and a periodic end-to-end test.
Four sentences never to put in writing: "CNC machines are exempt from CMMC." "Air-gapped means out of scope." "Unencrypted USB is always fine in manufacturing." "The assessor will accept this exception."
More on the shop-floor problem: CMMC for machine shops and CMMC for manufacturers.
Marking, transport, storage, and disposal
Answer capsule: Controlled use is one stage of the media lifecycle. When media contains CUI, MP.L2-3.8.1 through MP.L2-3.8.5 also require accountable storage, applicable CUI markings, and authorized transport with records — and MP.L2-3.8.3 requires sanitization or destruction before disposal or release for reuse, a five-point requirement that cannot be deferred.
| Stage | The decision | Evidence |
|---|---|---|
| Approve and issue | Owner, purpose, users, systems, media ID | Approval, inventory entry, checkout record |
| Use | Allowed operation, scan, read/write rule, logging | Endpoint event, scan record |
| Mark | Applicable CUI marking and distribution limitations | Labeled media, spot check |
| Store | Controlled storage and authorized access | Storage list, walkthrough, access roster |
| Transport | Authorized custody, tracking, receipt | Transport log, locked container, receipt |
| Protect in transit | Validated cryptography or the documented physical safeguard | Validation evidence or safeguard procedure |
| Return and reissue | Check-in, scan, custody, status update | Check-in record, scan result |
| Sanitize or destroy | Method by media type, authorization | Certificate or log |
| Retire | Remove from allowlist and inventory | Deprovision record |
The sanitization clause that goes stale
Go look at your sanitization clause right now. If it cites NIST SP 800-88 Revision 1, it cites a document that no longer exists as an active standard.
We read the withdrawal notice on the Rev. 1 PDF ourselves. NIST withdrew SP 800-88 Revision 1 on September 26, 2025 and superseded it in its entirety with Revision 2. And Rev. 2 didn't just renumber. It shifted the focus from hands-on technique selection to establishing a media sanitization program, and — apart from cryptographic erase — replaced technique-level detail with a recommendation to comply with IEEE 2883, NSA specifications, or an organizationally approved standard.
If your clause instead cites DoD 5220.22-M overwrite passes, NIST SP 800-88 Revision 2 explicitly treats that old multi-pass language as obsolete.
What your clause should say now: name the current standard, name the method by media type, name who authorizes it, and name the record that proves it happened. That's a small document fix on a five-point non-deferrable requirement.
The media nobody remembers
Printer and copier internal drives. Multifunction devices going back at lease end. Drives returned to a vendor under warranty. Backup drives and tapes — which is what MP.L2-3.8.9 is about, and which can disappear from the media inventory if nobody owns the lifecycle.
A drive that leaves your control under an RMA can be a release-for-reuse event. Resolve sanitization and custody before it leaves.
Marking detail lives on our CUI marking requirements page. Backups: CMMC-compliant backup solutions.
The removable-media failures that recur
Answer capsule: The removable-media failures to check first are mismatches — the policy says one thing, the endpoints allow another, the inventory can't identify devices or owners, and the SSP doesn't describe the real workflow. Draft evidence, unverified encryption claims, permanent legacy exceptions, and the absence of any functional test round out the list.
| The failure | Why it costs you | The fix |
|---|---|---|
| Signed policy, no operating evidence | The requirement is scored on implementation, not prose | Configure, log, test, retain |
| "Company devices only," but no inventory exists | You can't prove approval or identifiable ownership | Build the register: ID, owner, status, use, history |
| Every USB port blocked indiscriminately | Breaks required peripherals and creates shadow exceptions | Control the storage class; document allowed peripheral classes |
| Personal drives allowed because the user is known | User identity doesn't establish device approval, configuration, or custody | Prohibit personal storage on CUI systems as an organizational decision |
| "Encrypted USB" with no validation evidence | Product language isn't proof of a validated deployed module | Verify certificate, version, configuration, and use case |
| CUI leaves a controlled area with no analysis | Transport triggers a specific cryptography-or-safeguard question | Document the path and the chosen safeguard |
| A permanent CNC exception | An informal exception becomes the normal uncontrolled channel | Managed transfer architecture, owner, review, expiration, test |
| Unknown drive inserted to find the owner | Directly contradicts MP.L2-3.8.8 | Report and isolate. Never insert |
| Draft policy offered as evidence | § 170.24(b)(1) rejects drafts and unapproved policies | Complete approval and version control before assessing |
| No test of allowed and denied cases | You can't demonstrate the mechanism works | Run the six-step test and keep the results |
| Sanitization clause citing SP 800-88 Rev. 1 | Cites a withdrawn document | Update to Revision 2 and map methods to media types |
One distinction worth getting right
When we say a five-point requirement "cannot go on a POA&M," we mean the assessment plan of action and milestones under 32 CFR § 170.21 — the mechanism used to obtain Conditional CMMC status. That's not the same as tracking an internal remediation task.
The rule actually gives you something useful here. Section 170.24(b)(1)(ii) says temporary deficiencies appropriately addressed in operational plans of action — ones that include deficiency reviews and show progress toward correction — shall be assessed as MET. That is narrower than simply writing down an unimplemented control. Section 170.24(b)(1)(i) separately says enduring exceptions described with mitigations in the SSP shall be assessed as MET.
So "something broke last month and we're fixing it" has a real answer inside the rule, and it isn't an assessment POA&M. That distinction is easy to miss.
If you handle FCI only
Answer capsule: If your contracts involve Federal Contract Information but no Controlled Unclassified Information, exactly one media requirement applies to you at CMMC Level 1: sanitize or destroy media containing FCI before disposal or release for reuse. MP.L2-3.8.7 and the rest of this page are Level 2 requirements and are not assessed at Level 1.
That single Level 1 rule comes from 48 CFR 52.204-21(b)(1)(vii), incorporated into CMMC Level 1 by 32 CFR § 170.14(c)(2). Worth noticing: it is also the heaviest media requirement at Level 2, where it's scored as MP.L2-3.8.3 at five points.
If that's you, you're done with this page. Go to our CMMC Level 1 self-assessment checklist instead. You can absolutely adopt a broader removable media policy as a business risk decision — plenty of Level 1 shops should — but the Level 2 requirement IDs and point values above are not how Level 1 is scored, and we'd rather you spend the afternoon on the 15 Level 1 requirements that are.
Who should not write this policy alone
Answer capsule: If your removable media rule can't be enforced by a setting you control, the policy isn't your bottleneck. Someone has to own the enforcement and produce configuration evidence, and that is a different kind of help than a document.
Three situations where writing the policy first is the wrong order of operations:
An outside IT provider owns your group policy. You can write the rule, but you cannot produce the configuration export, the denied-device events, or the test result. If the provider's service processes, stores, or transmits CUI or Security Protection Data, 32 CFR § 170.19(c)(2) brings that service into the Level 2 assessment scope; document the service, its relationship to your organization, and the responsibility split in the SSP and customer responsibility matrix. If they can't or won't hand you evidence, that's the problem to solve first. You need the readiness, managed compliance, or MSSP category.
Mixed OT where ports can't be controlled in software. The policy will be short and the architecture will be long. You need readiness plus enclave or segmentation help, and the conversation starts with the data flow, not the document.
No asset inventory. You cannot build a media register for devices you can't enumerate, and you cannot make a scope claim you can't support. Start with scoping and asset inventory — a GRC platform helps you keep the evidence organized afterward, but it will not find your assets for you.
Before you request quotes, use Who to Hire First to sequence readiness, IT, and assessment work, then compare CMMC Level 2 cost so a policy-only quote does not masquerade as implementation.
One boundary that matters, and it's not optional: readiness and remediation work must stay separate from formal assessment. Under the Cyber AB's January 2026 C3PAO accreditation requirements, a C3PAO cannot conduct your Level 2 certification assessment within three years of providing consulting, implementation, or product sales or services to the organization under assessment. During the assessment, it cannot provide advice, implementation assistance, or recommendations, and it cannot promise a certificate. If one firm offers to implement and certify you on the same timeline, slow down.
Not sure which kind of help you're actually buying?
The gap you have is one of four: a policy gap, an enforcement gap, a scope gap, or an evidence gap. Each one routes to a different provider category, and paying for the wrong one is how small contractors burn budget without moving their score.
Tell us your level, scope, environment, and timeline, and we'll map you to source-checked CMMC provider options in the right category before you request quotes. Do not submit CUI, drawings, contract numbers, credentials, or sensitive technical details.
Where CMMC stands right now
Answer capsule: As of August 21, 2026, Phase 1 remains in effect. It began November 10, 2025 and, under the original rollout, ran through November 9, 2026. The Department suspended Phase 2 — which had been scheduled to begin November 10, 2026 — along with pending and future implementation milestones. Self-assessment requirements remain in place, select government-led assessments remain available, and no replacement Phase 2 date has been announced.
What happened, precisely. On July 13, 2026, the Department of War, formerly the Department of Defense, suspended Phase 2 and launched a 60-day review by a CMMC Reform Task Force. A companion memorandum gave contracting officers implementation guidance. Program offices may now designate only Level 1 (Self) or Level 2 (Self) assessments in procurement requests. Existing third-party assessment requirements come out of active solicitations, and out of awarded contracts at the next option exercise or scheduled administrative modification — not immediately. A public request for information closed at noon Eastern on August 14, 2026, and the Task Force's report to the CIO is due within 60 days of July 13, 2026.
What did not change, and this is the part that matters for your policy:
- 32 CFR Part 170, effective December 16, 2024, still maps CMMC Level 2 to NIST SP 800-171 Revision 2 at § 170.14(c)(3).
- MP.L2-3.8.7 and MP.L2-3.8.8 are still in that requirement set, still worth five and three points.
- DFARS 252.204-7012 still requires implementation of NIST SP 800-171 under the version rule in the clause; the current CMMC suspension guidance continues Revision 2 self-assessment enforcement.
- SPRS posting and annual affirmations continue.
- A senior-level Affirming Official still attests in SPRS that the organization has implemented and will maintain every requirement aligned to its CMMC Status.
Read that list again and notice what's missing: the routine Phase 2 C3PAO gate. The suspension removed that gate, not the standard — and not the Department's ability to conduct select government-led assessments. You now score whichever of these requirements apply to your Level 2 (Self) scope, and a senior-level Affirming Official enters the affirmation in SPRS. A C3PAO does not catch your mistake before you submit it.
One point of chronic confusion worth clearing up. NIST withdrew SP 800-171 Revision 2 on May 14, 2024, superseded by Revision 3. That's real, and it creates the recurring Rev. 2/Rev. 3 confusion. But NIST publishes; DoD regulates. 32 CFR Part 170 incorporates Revision 2 by reference, and incorporation by reference does not auto-update when the publisher issues a new edition. Until the rule is amended, CMMC Level 2 is Revision 2. Nothing on this page is written to Revision 3. More on that distinction: NIST 800-171 Rev. 2 vs. Rev. 3.
Do not collapse two SPRS records into one. A NIST SP 800-171 DoD Assessment summary score posted under DFARS 252.204-7019 and -7020 is not the same record as a CMMC Level 2 self-assessment and annual affirmation under 32 CFR Part 170 and DFARS 252.204-7021. They live in the same system, but they have different triggers, fields, and legal hooks. SPRS maintains separate CMMC and NIST reporting guidance.
What to do next
Answer capsule: Start with the workflow, not the document. Determine whether removable media is genuinely needed, map whether CUI enters or leaves the path, choose the narrowest workable model, approve the policy, enforce it technically, test both allowed and denied cases, and align the SSP and evidence.
- Confirm applicability and scope. Contract clause, FCI versus CUI, required level, assessment type, affected assets.
- Inventory the workflows. Every removable media use, including backups, CNC transfers, field work, vendor exchanges, and the informal practice nobody documented.
- Choose Model A, B, or C. Write down why it fits the business.
- Approve the policy and procedure. Assign owners, exception authority, and review dates. Approved, not draft.
- Implement enforcement. Storage-class blocks, allowlists, user and system restrictions, scanning, custody, logging.
- Test and capture final evidence. Allowed, denied, revoked, expired, and known-safe but deliberately unapproved cases — never found or truly unknown media — and, for Model C, the full legacy workflow.
- Update the SSP, train people, and sustain it. Cross-reference the evidence, review exceptions before they expire, retest on a schedule.
Steps 1 through 4 can move quickly when scope and ownership are already clear. Step 5 is where the calendar and the budget actually go, and step 6 is what separates a tested program from a hopeful one.
What we actually verified
We build these pages from primary sources, and here's exactly what we read and when — so you can check our work rather than take our word for it.
Verified August 21, 2026:
- Read 32 CFR § 170.24 in full at the eCFR, including the complete 5-point and 3-point requirement lists at § 170.24(c)(2)(i)(B), and pulled every point value on this page directly from those lists. Title 32 showed as current through August 19, 2026, last amended August 17, 2026.
- Read 32 CFR § 170.21(a)(2) for POA&M eligibility, the 80% threshold, the greater-than-one-point bar, and the six requirements excluded by name.
- Read 32 CFR § 170.24(b)(1) for the evidence-finality rule and the treatment of enduring exceptions and operational plans of action.
- Confirmed all 19 assessment objectives across the eleven-requirement removable-media map, plus the assessment objects, Further Discussion, and worked examples for MP.L2-3.8.7, MP.L2-3.8.8, AC.L2-3.1.21, and MA.L2-3.7.4, against the CMMC Level 2 Assessment Guide, Version 2.13.
- Read 32 CFR § 170.19 for Level 2 asset categories and External Service Provider scoping, and § 170.22 for Affirming Official requirements.
- Read current DFARS 252.204-7012, -7019, -7020, and -7021 at Acquisition.gov and checked the separate NIST-assessment and CMMC records in SPRS.
- Read DODIG-2019-105 in full, including Table 2 and the per-contractor removable-media findings.
- Confirmed the NIST SP 800-88 Revision 1 withdrawal notice (September 26, 2025) and Revision 2's publication and scope changes at NIST.
- Confirmed NIST SP 1334's final publication date (September 30, 2025) and its procedural, physical, technical, and transport-control recommendations.
- Confirmed the CMMC-controlling editions in 32 CFR § 170.2: NIST SP 800-171 Revision 2 for Level 2 and selected NIST SP 800-172, February 2021 requirements for Level 3. SP 800-172 does not control this Level 2 removable-media page.
- Checked the Cyber AB's January 2026 R2002 C3PAO Accreditation Requirements and CMMC Assessment Process v2.0 for impartiality, conflict-of-interest, no-advice, and no-guarantee rules.
- Confirmed the current CMMC program status following the July 13, 2026 Phase 2 suspension and the continued use of self-assessments and select government-led assessments.
What is editorial rather than government-defined: the mapping of NIST SP 1334's recommendations to CMMC requirements is our crosswalk, not NIST's. The three operating models are our framework for organizing a decision, not a government classification. The quarterly configuration-drift cadence and the six-step functional test are our recommendations, not rule text.
Frequently asked questions
Does CMMC require a removable media policy? No CMMC requirement states "write a removable media policy." NIST left policy and procedure controls out of the 110 requirements because it assumed nonfederal organizations already have them. But the official CMMC Level 2 Assessment Guide directs organizations to write one, and 32 CFR § 170.24(b)(1) lists unofficial and unapproved policies as unacceptable evidence. The defensible assessment-readiness answer is an approved document that matches the implementation.
What is MP.L2-3.8.7? MP.L2-3.8.7 is the CMMC Level 2 requirement to control the use of removable media on system components, drawn from NIST SP 800-171 Revision 2 requirement 3.8.7. It carries a value of five points under 32 CFR § 170.24 and has a single assessment objective: whether the use of removable media on system components is controlled.
What's the difference between MP.L2-3.8.7 and MP.L2-3.8.8? MP.L2-3.8.7 controls which media types may be used on which systems. MP.L2-3.8.8 separately prohibits the use of portable storage devices that have no identifiable owner. They stack: a device can be an approved type and still be prohibited because nobody can say whose it is.
How many points does removable media affect on a CMMC Level 2 score? By our count, a removable-media decision can affect eleven scored requirements across Media Protection, Access Control, and Maintenance, worth 27 points total when all eleven apply under 32 CFR § 170.24(c)(2)(i)(B). Twenty-two of those points sit on requirements worth more than one point, which cannot be placed on an assessment POA&M under § 170.21(a)(2)(ii).
Can MP.L2-3.8.7 go on a POA&M? No. It is a five-point requirement, and 32 CFR § 170.21(a)(2)(ii) bars any requirement worth more than one point from an assessment POA&M, with one narrow exception for partially implemented FIPS-validated encryption under SC.L2-3.13.11 that does not apply to 3.8.7.
Does CMMC require blocking USB ports? No. NIST SP 800-171 Revision 2's discussion for 3.8.7 describes restricting or prohibiting removable media, using technical or nontechnical controls, limiting use to approved devices, and disabling write capability. A blanket block is one defensible model, not a universal requirement.
Are CDs and DVDs covered? Yes. The requirement addresses removable media generally, and the assessment guidance names CDs, DVDs, diskettes, and USB drives as examples. In DODIG-2019-105, one contractor was cited specifically because it controlled USB drives and external hard drives but left optical media uncontrolled.
Is a USB mouse, keyboard, or security key removable media? These requirements address media and portable storage devices, not every peripheral that uses a USB connector. Define your device categories explicitly in the policy so the distinction is documented rather than argued in an interview.
Does CUI on a USB drive have to be encrypted? Not as a blanket rule. MP.L2-3.8.6 requires cryptographic mechanisms to protect CUI stored on digital media during transport unless alternative physical safeguards protect it. When cryptography is what protects CUI confidentiality, SC.L2-3.13.11 requires a FIPS-validated module.
What counts as an identifiable owner? NIST gives individuals, organizations, and projects as examples. The evidence has to connect a specific device to a responsible, accountable owner or custodian — not merely establish that you know the brand or the device type.
Can employees use personal USB drives? MP.L2-3.8.8 prohibits devices with no identifiable owner; it does not by itself ban personally owned devices. Our editorial recommendation is to prohibit personal storage on systems handling CUI, because configuration, custody, malware status, sanitization, and evidence are all difficult to govern on a device you don't own. State that prohibition as your organization's decision, not as a NIST requirement.
What about a vendor's diagnostic USB drive? That's MA.L2-3.7.4, a three-point requirement to check media containing diagnostic and test programs for malicious code before the media is used. It cannot be placed on an assessment POA&M, and it is easy to miss because it sits under Maintenance rather than Media Protection.
What sanitization standard should the policy cite? NIST SP 800-88 Revision 2. Revision 1 was withdrawn on September 26, 2025 and superseded in its entirety. Revision 2 emphasizes establishing a sanitization program and, apart from cryptographic erase, points to IEEE 2883, NSA specifications, or an organizationally approved standard rather than prescribing techniques directly.
What about the copier's hard drive? It can be media in scope. Multifunction devices, printers, and copiers may retain what they process. When a leased device contains CUI and goes back at end of term, MP.L2-3.8.3's disposal-or-release-for-reuse analysis applies — and that is a five-point, non-deferrable requirement.
Does any of this apply at CMMC Level 1? One rule does: sanitize or destroy media containing FCI before disposal or release for reuse, from 48 CFR 52.204-21(b)(1)(vii). MP.L2-3.8.7 and the rest of the Media Protection family are Level 2 requirements and are not assessed at Level 1.
How often should the policy be reviewed? The rule does not set a universal cadence for this document. Set your own, and trigger an out-of-cycle review after any material change to architecture, workflow, tooling, contracts, CUI scope, or after an incident.
Has the July 2026 suspension changed removable media requirements? No. The July 13, 2026 suspension paused CMMC Phase 2 implementation milestones. It did not amend 32 CFR Part 170, did not change the Level 2 requirement set, and did not alter DFARS 252.204-7012. Level 1 and Level 2 self-assessments, SPRS posting, annual affirmations, and select government-led assessments continue.
About this page. The Defense Compliance Report is an independent trade publication on CMMC 2.0 and DIB compliance. We are not affiliated with the Cyber AB, the Department of War or Department of Defense, DCMA DIBCAC, NIST, or any U.S. government agency. Read our methodology, editorial standards, and corrections policy.
This is educational research, not legal, contractual, assessment, or compliance advice. Confirm contract applicability, CUI scope, asset treatment, and assessment requirements with a qualified CMMC readiness professional and, where legal interpretation is required, a qualified federal-contracts attorney. The contract clause and your CUI handling set your level — not a checklist.
Disclosure. We may receive compensation for qualified introductions, sponsorships, or partner referrals when disclosed. Compensation does not control our regulatory analysis, provider-category recommendations, or Cyber AB status verification. No named provider appears on this page, and none was paid to be excluded.
Need help deciding what type of CMMC provider you need? Tell us your level, scope, and timeline, and we'll map you to source-checked CMMC provider options. Find my CMMC provider category → Do not submit CUI, drawings, contract numbers, credentials, or sensitive technical details.