Removable Media

Removable Media (Device Control)

CMMC Control Mapping Matrix

Field note: an "Excluded Devices" entry opens the drive to every user, not just the one you scoped it for. Use the two-rule Block-then-Allow pattern below instead.

NIST 800-171 Control Mapping

This appendix walks through the modern Intune Reusable Settings UI for Device Control. For the threat model and the underlying XML rule format that Intune generates from your form input, see Open Intune Baseline Deployment § USB Device Control & SOC Alerting. Intune defines what's blocked and allowed; Defender for Endpoint provides the SOC alert when an unapproved device is plugged in.

The implementation has two parts:

1. Reusable Settings: one identifying the broad class the rule applies to (all removable storage), one identifying your approved hardware (the allowlist). Built once per organization, referenced by every Device Control policy.
2. A Device Control policy that blocks all removable storage write/execute access except for the allowlist, with AuditDenied actions to surface alerts to Defender.

Pick the matching pattern before you start

A Reusable Setting is a tenant-level identifier list: a named bucket of hardware identifiers. By itself it doesn't enforce anything or bind to any user or device. Enforcement happens at the Device Control policy entry (Allow / Deny / AuditDeny); per-user or per-group binding happens via a SID condition on that entry. Pick one of three patterns before you start clicking.

Pattern 1: Class allowlist (loosest)

One Reusable Setting for the whole organization, filtering on VID_PID only. Any drive of that vendor/model is accepted, on any device, by any signed-in user.

Use when: the organization buys USBs in bulk for general workforce use and a vendor-line allowlist is sufficient. Don't use for CUI: a user buying the same model at Best Buy defeats the control; there is no per-drive audit trail and no proof the drive came through your issuance process.

Use when: the organization buys USBs in bulk for general workforce use and a vendor-line allowlist is sufficient. Don't use for regulated or sensitive data: a user buying the same model at Best Buy defeats the control; there is no per-drive audit trail and no proof the drive came through your issuance process.

Pattern 2: Per-drive pool, scoped to an Entra security group

A pool of physically issued drives, each identified individually (VID_PID + SerialNumberId, Match all, one Reusable Setting per drive), usable by any member of a named Entra ID security group. The group binding lives on the Allow rule's entry Sid field, set to the group's Entra Object ID: the Sid field accepts a group Object ID identically to a user's (Entries; walkthroughs). One Sid per entry: layered access (one group read-only, another read/write) requires multiple entries.

Drive churn and user churn are decoupled: adding a drive = one new Reusable Setting plus an update to the Allow rule's Included Devices; onboarding/offboarding a user = one Entra group edit. The per-session drive-to-user assignment lives in your asset register or sign-out ledger, not the policy.

Don't use when: your CMMC media-protection (MP.L2-3.8.x) evidence requires the per-issuance drive-to-user binding in the policy itself. Some C3PAOs accept a sign-out log as equivalent evidence; some don't; when in doubt, use Pattern 3. Microsoft also notes user/group conditions require reliable Entra ID connectivity for SID resolution at sign-in.

Don't use when: your media-protection evidence requires the per-issuance drive-to-user binding in the policy itself rather than an out-of-band ledger; when in doubt, use Pattern 3. Microsoft also notes user/group conditions require reliable Entra ID connectivity for SID resolution at sign-in.

Scale ceiling: Intune caps a Device Control profile at 100 reusable groups per profile, so one policy holds up to ~100 pool drives; split larger pools into multiple policies assigned to the same device groups.

Pattern 3: Per-drive bound to a specific user (strongest)

One Reusable Setting per drive (VID_PID + SerialNumberId, Match all) AND a Sid condition on the Allow rule's entry set to the named user's Entra Object ID. The drive works only when that user is signed in. Embed the user and issuance date in the Reusable Setting Name (e.g., SanDisk Ultra 32GB — Alice Cohen — issued 2026-04-28): Intune doesn't read the name, but it's the audit trail that ties the policy to a physical drive and person.

Use when: handling CUI with cleared-personnel media issuance and your assessor expects the per-issuance binding visible in the policy itself. Don't use when the population is in the hundreds and a Reusable Setting per issuance becomes untenable; drop to Pattern 2 and let the asset-management issuance log carry the user-to-drive mapping.

Recommendation for CMMC L2

For CUI-handling drives, choose between Pattern 2 (pool + group, sign-out ledger as the per-issuance trail) and Pattern 3 (binding in the policy itself). Pattern 1 is appropriate only for data explicitly out of CMMC scope.

Use when: handling sensitive data with controlled media issuance and your auditor expects the per-issuance binding visible in the policy itself. Don't use when the population is in the hundreds and a Reusable Setting per issuance becomes untenable; drop to Pattern 2 and let the asset-management issuance log carry the user-to-drive mapping.

Recommendation for sensitive data

For drives that carry sensitive data, choose between Pattern 2 (pool + group, sign-out ledger as the per-issuance trail) and Pattern 3 (binding in the policy itself). Pattern 1 is appropriate only for data that needs no per-drive audit trail.

The walkthrough below populates the same fields for Patterns 2 and 3 (VID_PID + SerialNumberId, Match all); Pattern 1 fills only VID_PID. What differs is the Name convention, how many Reusable Settings you create, and the Allow entry's Sid.

Step 1: Create the Reusable Setting (the allowlist)

1. Navigate to Endpoint Security → Attack Surface Reduction → Reusable Settings → Add.
2. Basics tab: Name Custom - Device Control - Approved <Vendor> USBs; Description: date, approved vendor/model, issuance owner team.
3. Configuration settings tab: expand Device Control, click Add, choose Removable storage as the Object type. Match type: Match all for Patterns 2 and 3 (every populated identifier must match); moot for Pattern 1. Click the yellow ⚠ Configure settings link on the new row.
4. In the Configure removable storage instance panel, populate the fields per your pattern, then OK → Next → Review + create.

For Pattern 2, repeat once per pool drive; the pool inventory is the list of these Reusable Settings, all referenced from the Allow rule's Included Devices in Step 3.

Field reference for the Configure removable storage instance panel

Examples assume Pattern 3 with a real SanDisk Ultra USB 3.0 32 GB (model SDCZ48-032G, printed serial BM24080023944); replace with what your reference device actually reports.

Field	What it matches	Example
Name (required)	Friendly label only, not matched. Embed vendor/model, user, issuance date, and printed serial	SanDisk Ultra 32GB — Alice Cohen — issued 2026-04-28 — printed SN BM24080023944
VID_PID	Vendor + Product ID, format VVVV_PPPP. Wildcards: VVVV_ = any product from one vendor, _PPPP = any vendor's product	0781_5581
SerialNumberId	The drive's serial as enumerated by Windows (trailing segment of the device instance path). Often not the printed label serial: see the warning below	090161F8…C705 (≈130 hex chars in full)
InstancePathId	Full device instance path {BusId}\{DeviceId}\{SerialNumberId}; append * for the trailing slot indicator	USB\VID_0781&PID_5581\090161F88D8B3409*
PrimaryId	Microsoft's device-class identifier	RemovableMediaDevices
DeviceId / HardwareId	Vendor/product/revision strings from the instance path / Device Manager Hardware Ids. Format varies by manufacturer; HardwareId values are not unique per physical drive	USBSTOR\Disk_USB_____SanDisk_3.2Gen1
FriendlyNameId	The user-visible device name; useful for "Generic Mass Storage" devices	SanDisk 3.2Gen1 USB Device
BusId	Physical bus: USB, SD, 1394	USB

Where to find the values: plug the drive into a reference workstation → Device Manager → Disk drives → (device) → Properties → Details. Hardware Ids gives VID_PID (first line, underscore-joined) and HardwareId; Device instance path gives the whole InstancePathId, whose trailing segment is SerialNumberId, middle segment DeviceId, first segment BusId; Friendly name gives FriendlyNameId. Don't trust the serial printed on the casing: Windows enumerates the USB descriptor's serial, which many manufacturers don't print.

Long Windows-enumerated serials: verify cross-machine before committing to Patterns 2 or 3

Some USB descriptors expose 100+ hexadecimal-character composite serials (hardware-attestation features, IEEE 1667 silos, certain SanDisk Ultra firmware): real values, unrelated to the printed label. When you hit one:

1. Verify it's per-drive, not per-machine: read the instance path on a second machine. Same string = the drive's identity, Patterns 2/3 work. Different = Windows is synthesizing per-bus; fall back to HardwareId matching and accept the loss of per-drive specificity.
2. Never hand-transcribe it: copy via Device Manager → Properties → Details → Device instance path → right-click → Copy. The Intune field accepts the full string verbatim.
3. Embed the printed serial in the Reusable Setting Name so audit events (which show only the enumerated serial) cross-reference to your asset register.

Step 2: Create the class-level "all removable storage" Reusable Setting

The Step 1 setting identifies your approved hardware; the Device Control rule also needs a setting identifying the broad set the rule applies to. Create this once per tenant:

1. Endpoint Security → Attack Surface Reduction → Reusable Settings → Add.
2. Basics: Name Custom - Device Control - All Removable Media (class).
3. Configuration settings: expand Device Control → Add → Object type Removable storage → Match type Match any → Configure settings.
4. Populate only Name (All RemovableMediaDevices (class)) and PrimaryId (RemovableMediaDevices), which matches every USB flash drive, SD card, and similar removable storage regardless of vendor, model, or serial. OK → Next → Review + create.

Step 3: Create the Device Control policy

1. Endpoint Security → Attack Surface Reduction → Create Policy.

2. Platform: Windows. Profile: Device Control (not "Attack Surface Reduction Rules", a sibling profile type that doesn't expose Device Control). Create.

3. Basics: Name Win - Custom - ES - Device Control / Removable Media; Description Blocks all removable media except allowed USB drives used by approved users.

4. Configuration settings tab, in two categories:

   1. Expand Defender and set Device Control Enabled to Enabled: without it, the rules below don't take effect.
   2. Expand Device Control. The pattern is two rules: one blocking all removable storage for everyone, and a second allowing approved drives, scoped via the Allow entry's Sid. This is Microsoft's documented Block-then-Allow pattern. Don't put approved drives in Excluded Devices on the Block rule: Excluded Devices removes a drive from the rule's scope for every signed-in user, defeating any per-user or per-group binding. The carve-out lives in the second rule.

   Rule A: Block all removable storage (applies to everyone)

   3. Click + Add under the ID section.
   4. Name (appears in end-user toast notifications and in RemovableStoragePolicyTriggered events): Block removable storage — all users.
   5. Included Devices: + Set reusable settings → the class-level setting from Step 2. Excluded Devices: empty for all patterns.
   6. Access: click Configure access (yellow ⚠ until completed). Two entries are required, one to enforce and one to audit; add the second row with + Add at the top of the panel:

   Setting	Entry 1: Deny	Entry 2: AuditDenied
   Options	None. The other choice, Disable, suppresses any matching AuditDenied entry: a silent block with no toast and no Defender event, defeating the audit pipeline	Send notification and event: shows the toast AND fires the RemovableStoragePolicyTriggered event that drives the SOC alert (other choices: None, Send notification, Send event)
   Access mask	Check all 7 boxes (reads "7 selected"; Print is a no-op for storage but keeps the rule simple)	Same 7 boxes: a mask mismatch produces blocks that never get audited
   Sid	Empty: a Sid here would scope the deny to specific users, the inverse of "block everyone" (per-user scoping lives on Rule B's Allow entry)	Empty
   Computer ID	Empty: per-device targeting is the policy assignment layer's job	Empty

   Without the AuditDenied entry, SOC alerting in Step 4 will not fire: the Defender detection listens for RemovableStoragePolicyVerdict == "Deny" events, which come from AuditDenied entries, not from Deny entries directly. Click Save; the ⚠ clears.

   Rule B: Allow approved drives (scoped to the right user/group)

   7. Click + Add again. Name: Allow approved removable storage — <scope> (Pattern 1: all users; Pattern 2: group name; Pattern 3: user name).
   8. Included Devices: the Step 1 allowlist setting(s): Pattern 1's single vendor/model setting, Pattern 2's full set of pool-drive settings, or Pattern 3's per-issuance setting. Excluded Devices: empty.
   9. Access: for Patterns 2 and 3, two entries are required; Pattern 1 can skip the AuditAllowed entry. NIST 800-171 3.3.2 (uniquely trace actions to users) requires a system-of-record audit of who used which drive when, not just an out-of-band sign-out ledger.Audit evidence of who used which drive when requires the system-of-record event, not just an out-of-band sign-out ledger.

   Setting	Entry 1: Allow	Entry 2: AuditAllowed (Patterns 2 & 3)
   Options	None	Send event: produces the Defender event with RemovableStoragePolicyVerdict == "Allow" without a per-access toast (use Send notification and event only if users should see "approved drive in use" toasts)
   Access mask	All 7 boxes for full access on approved drives; check only the read bits for a read-only tier	Same boxes as the Allow entry. If event volume from heavy file-copy workloads becomes a measured problem, narrow to file-write only: keeps the per-write trail, drops per-read noise. Decide after measuring, not pre-emptively
   Sid	The pattern binding lives here. Paste the Entra Object ID (a GUID): Pattern 2 = the security group's (Entra → Groups → <group>), Pattern 3 = the user's (Entra → Users → <user>), Pattern 1 = empty. Allow has highest precedence: a user matching the Sid gets Allow; everyone else falls through to Rule A's Deny	Same Object ID as the Allow entry: a mismatch produces users who are allowed but unaudited, or vice versa
   Computer ID	Empty	Empty

   Click Save. (Optional) Layered access (different groups, different masks) requires an additional Allow rule per tier, each with its own Sid; see the walkthroughs.

   XML import is the alternative for advanced policies

   For multi-rule policies, complex condition logic, or migrations from existing MDE XML rule sets, paste the Policy Rule XML directly into Intune instead of the form-based path. Sample XML, including the AuditDenied action, is in Chapter 29 § USB Device Control & SOC Alerting.

5. Scope tags: accept Default unless you use RBAC scope tags.

6. Assignments: the workstation device group plus any non-datacenter servers (branch-office, retail, industrial-floor) where physical USB access is a real risk; datacenter rack servers are usually out of scope. See Chapter 12 § Server Endpoint Security set for when a separate Svr - variant is justified.

7. Review + create.

Step 4: SOC alerting via Defender for Endpoint

The policy enforces the block; real-time alerting requires a separate Defender custom detection rule watching RemovableStoragePolicyTriggered events with a Deny verdict. Full KQL and detection-rule steps: Chapter 29 § USB Device Control & SOC Alerting → Defender for Endpoint.

Verification

After deployment to a pilot device:

Check	Where	Expected
Policy reached the device	Intune → Devices → <device> → Endpoint security configuration	Device Control profile shows Succeeded
Approved device works	Plug in the approved drive on the pilot device	Read/write works as before
Unapproved device is blocked	Plug in any other USB drive	Write attempts fail; toast notification "Your IT administrator…"
MDE recorded the deny	Defender portal → Hunting → Advanced hunting, run the Chapter 29 KQL query	Row with RemovableStoragePolicyVerdict == "Deny"
MDE recorded the allow (Patterns 2 & 3)	Same query	Row with Verdict == "Allow" and AccountSid matching the user (or a group member)
Custom detection fires	Defender → Incidents	New incident at the configured severity within 5 minutes of the deny event