Removable Media on Macs Under CMMC: What MP.L2-3.8.7 and MP.L2-3.8.8 Actually Require

The short answer

Two CMMC Level 2 requirements govern removable media, and they are routinely misread in opposite directions.

• MP.L2-3.8.7 requires you to control the use of removable media. It does not require a ban. A written policy permitting organization-issued encrypted drives, with logging, satisfies it.
• MP.L2-3.8.8 requires you to prohibit portable storage devices with no identifiable owner. It is a narrow absolute ban on one scenario, and its official short name has misled a large number of people about what it covers.

On macOS, the supported enforcement mechanism changed at macOS 15. This is a different question from CUI leaving a Mac through iCloud, AirDrop or external drives, which is covered separately. The payload most guidance still points at was deprecated at macOS 11 and no longer appears in Apple's current payload list.

What do the two requirements say, exactly?

Both, verbatim, from NIST SP 800-171 Rev. 2:

3.8.7 Control the use of removable media on system components.

3.8.8 Prohibit the use of portable storage devices when such devices have no identifiable owner.

Source: NIST SP 800-171 Rev. 2, corroborated at csf.tools and DIB SCC CyberAssist.

The CMMC identifiers map directly. Under 32 CFR 170.14:

The security requirements in CMMC Level 2 are identical to the requirements in NIST SP 800-171 R2.

And both identifiers appear literally in the regulation. 32 CFR 170.24 lists MP.L2-3.8.7 among the derived security requirements.

Source: 32 CFR 170.14 and 32 CFR 170.24

Why do people think 3.8.7 requires a ban?

Because "control" gets read as "lock down," and because the two most common implementations, a full block and a full allow, are easier to describe than the middle.

NIST's own discussion text draws the line:

In contrast to requirement 3.8.1, which restricts user access to media, this requirement restricts the use of certain types of media on systems, for example, restricting or prohibiting the use of flash drives or external hard disk drives.

Source: csf.tools, 3.8.7 (authoritative secondary)

Note the phrasing: "restricting or prohibiting." A total ban is one acceptable implementation of 3.8.7. It is not the requirement. If you have a documented decision, an enforced technical state that matches it, and records showing the two agree, you are meeting the requirement whether the decision was "no removable media" or "issued encrypted drives only, tracked in the asset inventory."

Writing "3.8.7 requires us to prohibit removable media" in an SSP is an overstatement of the requirement, and it commits you to a control posture you may not want and may not be able to sustain.

Why is 3.8.8 so widely misdescribed?

Because of its name.

The official CMMC short name for MP.L2-3.8.8 is "Shared Media." The requirement has nothing to do with network file shares, shared drives, or encrypting shared storage. It is about portable storage devices of unknown provenance: the drive found in a parking lot, the branded USB stick from a conference table, the unlabeled disk in a drawer.

The name reliably leads writers to describe it as a shared-storage encryption requirement. It is not one.

A related quirk worth knowing if you are searching official documents: DoD's own Level 2 assessment guide spells the MP.L2-3.8.7 short name "Removeable Media," with the typo, in its table of contents. Searching for the correct spelling can miss it.

One more consequence of the misnaming: 3.8.8 is sometimes cited to justify disabling all USB storage. It does not support that. It prohibits only devices with no identifiable owner. A drive with a known, accountable owner is untouched by 3.8.8. The latitude to ban everything lives in 3.8.7's "control," not here.

A verification note that applies to this whole topic

While preparing this article, an automated retrieval of the official DoD CMMC Assessment Guide Level 2 returned confident, well-formatted, and entirely fabricated text for both of these requirements. It rendered 3.8.7 as "prohibit the use of removable media in organizational systems unless otherwise explicitly authorized" and 3.8.8 as "protect organizational information stored on shared media by employing an encryption mechanism." Both are false. Neither sentence appears in NIST SP 800-171 Rev. 2.

That second fabrication is instructive: it is what you would invent if you had only the section title "Shared Media" to work from.

If you are using an AI assistant to summarize CMMC source documents, verify the requirement text against NIST or the eCFR before it reaches your SSP. Requirement text is short enough to check and consequential enough to be worth checking.

What is the supported way to restrict external media on macOS?

Apple's current mechanism is a declarative configuration introduced in macOS 15.0.

Declaration type: com.apple.configuration.diskmanagement.settings

Apple's own example:

{
    "Type": "com.apple.configuration.diskmanagement.settings",
    "Identifier": "EB13EE2B-5D63-4EBA-810F-5B81D07F5017",
    "ServerToken": "E180CA9A-F089-4FA3-BBDF-94CC159C4AE8",
    "Payload": {
        "Restrictions": {
            "ExternalStorage": "Disallowed",
            "NetworkStorage": "Disallowed"
        }
    }
}

Two keys, three values each:

Key	Values	Effect
ExternalStorage	Allowed	System can mount read-write or read-only external storage
	ReadOnly	Only inherently read-only devices mount, such as DVDs and CDs. Writable devices cannot mount
	Disallowed	No external storage can mount
NetworkStorage	Allowed, ReadOnly, Disallowed	Analogous, for network volumes

Sources: Apple Developer, DiskManagementSettings, Apple's schema repository, and Storage management declarative configuration

The ReadOnly trap

ReadOnly does not mean "mount USB sticks in read-only mode."

It means only media that is already physically read-only will mount. If macOS detects that the storage is writable, it will not mount it at all.

So ReadOnly on a writable USB drive is a block, not a downgrade. If your policy says "removable media may be read but not written," this setting does not implement that policy. It implements "optical media only."

This is the single most likely place to get macOS removable-media control wrong, and it is the kind of gap that surfaces during an assessment rather than during configuration.

Apple also warns about vendor labeling

Each device management service developer implements these settings differently.

Source: Storage management declarative configuration

Your MDM's user interface will not use Apple's key names. When you document the control, record both the vendor's label and the underlying Apple key, so the SSP survives a change of MDM.

What about the older mount-controls payload?

You will find guidance pointing at com.apple.systemuiserver, titled "Media Management: Allowed Media," with a mount-controls dictionary. Its real subkeys are all-media, cd, dvd, bd, blankcd, blankdvd, blankbd, dvdram, disk-image, harddisk-internal, harddisk-external, and networkdisk, with action values authenticate, read-only, deny, and eject.

Apple's schema marks this payload introduced at macOS 10.7 and deprecated as of macOS 11. It does not appear in Apple's current device management payload list for Mac computers.

Sources: com.apple.systemuiserver.yaml and Device management payload list for Mac

State the position accurately: Apple marked it deprecated at macOS 11, it is absent from the current payload list, and it has been superseded by the macOS 15 declarative configuration. Apple has not published a statement that it was removed, and this article does not claim it stopped functioning. If you are relying on it today, test it on your current macOS version and record the result rather than assuming either outcome.

Two things you may find in older write-ups that this article will not repeat: the payload com.apple.applicationaccess.new does not contain mount controls, it is Parental Controls application restrictions. And a key named NSMountDisksWithoutUserApproval could not be verified against any Apple documentation. Do not build a control on it.

What proves it to an assessor?

Here is the part that catches people out. There is no Declarative Device Management status report item corresponding to this configuration.

Apple's disk management status namespace does contain diskmanagement.filevault.enabled from macOS 14, so FileVault status is reported. There is no equivalent status item for the external or network storage restriction. The wider macOS status catalog covers device identity and OS version from macOS 13, background tasks, FileVault, and software update from macOS 14, and battery health from macOS 14.4. Storage restriction appears nowhere in it.

Sources: Declarative status reports and Apple's declarative status schemas

You can declare the restriction. The device will not report back that the restriction is in effect. Your MDM console showing the declaration delivered is delivery evidence, not effectiveness evidence.

For this control, that means your evidence has to come from three places:

1. The written decision. A media protection policy stating what is permitted, what is prohibited, who authorizes exceptions, and on what basis. This is what 3.8.7's "control" actually asks for, and no technical setting substitutes for it.
2. The configuration record. The declaration or profile as deployed, with the payload values visible, plus the MDM record of delivery per asset.
3. An endpoint check. Output taken from a sample of Macs confirming external storage does not mount, dated, with the hostname visible, retained on your defined schedule.

For 3.8.8 specifically, the evidence is different in kind: it is an inventory. If your requirement is that portable storage must have an identifiable owner, then the artifact is a record associating each authorized device with its owner. A technical block does not demonstrate 3.8.8 compliance; an ownership record does.

One nuance about the revision you are assessed against

NIST formally withdrew SP 800-171 Rev. 2 on 2024-05-14. CMMC remains pinned to it by regulation, per 32 CFR 170.14.

In Rev. 3, these two requirements were consolidated: 03.08.07 "Media Use" absorbed the ownerless-device prohibition that had been 3.8.8.

Source: csf.tools, 03.08.07 (authoritative secondary)

For CMMC work today, use the Rev. 2 numbering. If your policy library is being written to Rev. 3 because a tool defaulted to it, your control identifiers will not match what an assessor is working from.

Summary

Question	Answer
Does 3.8.7 require banning USB drives?	No. It requires a documented, enforced decision. A ban is one valid option.
Is 3.8.8 about shared network storage?	No, despite its official short name. It is about portable devices with no identifiable owner.
What enforces this on macOS today?	com.apple.configuration.diskmanagement.settings, macOS 15 and later.
Does ReadOnly mount USB drives read-only?	No. It blocks writable media entirely and permits only inherently read-only media.
Will the Mac report that the restriction is working?	No. There is no DDM status item for the storage restriction, though FileVault status is reported separately.
What satisfies 3.8.8?	An ownership record, not a technical block.

---