Removable Media

Removable Media (Device Control)

CMMC Control Mapping Matrix

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. Together, the chapter and this appendix cover the full flow: 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. The enforcement happens at the Device Control policy entry (Allow / Deny / AuditDeny), and per-user or per-group binding happens via a SID condition on that entry. Three patterns are common; pick the one that matches your operational model before you start clicking.

Pattern 1: Class allowlist (loosest)

One Reusable Setting for the entire organization, identifying an approved vendor and model. Any individual drive of that vendor/model is accepted, on any device, by any signed-in user.

Reusable Setting name	Filter fields	Resulting scope
Approved SanDisk Ultra USB 3.0	VID_PID only	Any SanDisk Ultra USB 3.0 on any tenant device

Use when: the organization buys USBs in bulk for general workforce use and a vendor-line allowlist is sufficient (e.g., commercial environments, low-sensitivity data).

Don't use when: you're handling CUI. A user buying their own SanDisk Ultra at Best Buy and plugging it in defeats this control — there's no per-individual-drive audit trail and no proof that 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 by vendor/model + serial — usable by any signed-in member of a named Entra ID security group. The pool inventory lives in N Reusable Settings (one per pool drive, each with VID_PID + SerialNumberId, Match all); the user-group binding lives on the Allow rule's entry Sid field, set to the group's Entra Object ID.

Reusable Setting name (one per pool drive)	Filter fields	On the Allow rule's entry	Resulting scope
Pool USB — SanDisk Ultra 32GB SN BM24080023944	VID_PID + SerialNumberId, Match all	Sid = Entra security group Object ID (e.g., USB Users)	Each pool drive works on any tenant device, but only when a USB Users member is signed in

The mechanism is the entry's Sid field, which accepts an Entra group's Object ID identically to a user's Object ID — see Device control policies → Entries ("For user groups and users that are stored in Microsoft Entra ID, use the object id in the condition") and the device control walkthroughs → "Allow different levels of access to devices for specific users or groups" ("Device control also supports group SIDs… the rules are the same for User 2 or any other user in that group"). One Sid per entry — a single rule scopes to exactly one group; layered access (e.g., one group read-only, another read/write) requires multiple entries.

Use when: a defined population of users (a CUI-handling team, a research subgroup, an engineering subset) shares a pool of company-issued drives. 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 drive-to-user assignment for a given session is recorded in your asset register or sign-out ledger rather than the policy itself.

Don't use when: your CMMC media-protection (MP.L2-3.8.x) evidence requires the per-issuance drive-to-user binding to live in the policy itself rather than in an out-of-band ledger. Some C3PAOs accept a sign-out log as equivalent evidence; some don't. When in doubt, default to Pattern 3. Microsoft also notes that user/group conditions referencing Entra ID should only be used in environments with reliable Entra ID connectivity — generally fine for GCC High, but the SID resolution path depends on a reachable Entra endpoint 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. For larger pools, split into multiple policies assigned to the same device groups.

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

One Reusable Setting per drive AND a SID condition on the Allow rule's entry that references it. The drive only works when the named user is signed in.

Reusable Setting name	Filter fields	On the Allow rule's entry	Resulting scope
SanDisk Ultra 32GB — Alice Cohen — issued 2026-04-28	VID_PID + SerialNumberId, Match all	SID condition matching Alice's Entra ID Object ID	This specific drive, on any tenant device, but only when Alice is signed in

The user name and date in the Reusable Setting name are labels for your audit trail — Intune doesn't read them. They're there so a future operator looking at a list of 50 Reusable Settings can tell which physical drive belongs to whom and when it was issued.

Use when: handling CUI with cleared-personnel media issuance, and your assessor expects the per-issuance binding to be visible in the policy itself. This is the strongest audit trail. Pairs naturally with a written issuance log in your asset-management system.

Don't use when: the user population is in the hundreds and a Reusable Setting + entry update per issuance becomes operationally untenable. Drop to Pattern 2 in that case and treat the asset-management system's issuance log as the user-to-drive mapping.

Recommendation for CMMC L2

For CUI-handling drives, the choice is between Pattern 2 (pool + group, with an out-of-band sign-out ledger as the per-issuance audit trail) and Pattern 3 (per-drive bound to one named user, with the binding in the policy itself). Pattern 2 is operationally lighter and decouples drive churn from user churn; Pattern 3 produces the strongest per-issuance evidence — drive identity, user identity, and issuance date all visible in the policy — at the cost of a Reusable Setting + entry edit per issuance event.

Pattern 1 is appropriate only for data that is explicitly out of scope for CMMC.

The walkthrough in Step 1 below populates the same Reusable Setting fields for Patterns 2 and 3 — VID_PID + SerialNumberId with Match all. What differs is operational: the Reusable Setting Name convention, how many Reusable Settings you create, and what goes on the Allow rule's entry Sid field. Pattern 1 fills only VID_PID; the rest of the procedure is identical.

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 (e.g., Custom - Device Control - Approved SanDisk Ultra USB 3.0).
   • Description: include the date, approved vendor and model, and the device-issuance owner team.
3. Configuration settings tab:
   • Expand the Device Control group, click Add, and choose Removable storage as the Object type.
   • Match type: for Patterns 2 and 3 (per-drive identification), set to Match all so every populated identifier must match. For Pattern 1 (class allowlist) only VID_PID is populated, so Match any vs Match all is moot — leave at the default.
   • The row Intune just added will show a yellow ⚠ "Configure settings" link. Click it; the Configure removable storage instance panel opens on the right.
4. In the right-hand panel, populate the fields determined by the pattern you chose above — VID_PID only for Pattern 1, VID_PID + SerialNumberId for Patterns 2 and 3. Leave the remaining fields blank unless your reference device's USB descriptor is non-standard and VID_PID doesn't uniquely identify it (see "Where to find the values" below).

For Pattern 2 (pool with group binding), repeat Step 1 once per drive in the pool — each pool drive gets its own Reusable Setting. The pool inventory is the list of these Reusable Settings; in Step 3 below, all of them are referenced from the Allow rule's Included Devices, and the group SID lives on the Allow rule's entry.

Field reference for the Configure removable storage instance panel

Examples below assume Pattern 3 (per-drive, bound to a specific user — the strongest audit trail) and use a real SanDisk Ultra USB 3.0 32 GB drive (model SDCZ48-032G, printed serial BM24080023944) issued to a hypothetical Alice Cohen. Note that the Windows-enumerated serial bears no resemblance to the printed serial — see the warning below the table. Replace these values with what your own reference device actually reports — the format is what matters.

Field	What it matches	When to use it	Example value (Pattern 3)
Name (required)	Friendly label inside the Reusable Setting only — not used for matching. Pattern 1: vendor/model. Pattern 2: Pool USB — prefix + vendor/model + printed drive serial. Pattern 3: vendor/model + user + issuance date + printed drive serial	Always	SanDisk Ultra 32GB — Alice Cohen — issued 2026-04-28 — printed SN BM24080023944
VID_PID	Combined Vendor ID + Product ID, format VVVV_PPPP (with underscore). Wildcards supported: _PPPP matches any vendor's PID, VVVV_ matches any product from one vendor	All three patterns. Identifies the model line from one vendor	0781_5581
SerialNumberId	The specific device's serial number as enumerated by Windows (the trailing segment of the device instance path, after the second \). Read the warning below — this is often not the serial printed on the device label.	Patterns 2 and 3 — pins the rule to one physical drive	090161F88D8B3409C34C61DDA0200626A2A884369497347CAE0D2ECAC68771998BBC00000000000000000000CE312D0E00862C20815581078A30C705
InstancePathId	Full Windows device instance path: {BusId}\{DeviceId}\{SerialNumberId}. Wildcards supported (recommended — append * to handle the trailing slot indicator)	Rarely used directly — SerialNumberId is more specific and VID_PID is more general	USB\VID_0781&PID_5581\090161F88D8B3409*
VID	Vendor ID alone (4 hex chars)	Approve every device from a specific vendor (broader than VID_PID; not usually appropriate for CMMC)	0781
PID	Product ID alone	Rarely useful on its own — pair with VID for model-line matching	5581
PrimaryId	Microsoft's primary device-class identifier	Class-level matching (e.g., any removable storage device)	RemovableMediaDevices
DeviceId	The middle segment of the device instance path — vendor/product/revision string. Format varies by manufacturer; SanDisk Ultra reports Disk_USB_____SanDisk_3.2Gen1 while generic flash drives report USBSTOR\DISK&VEN_…&PROD_…&REV_… form	Filter by USB device class without binding to a specific VID/PID hex pair	USBSTOR\Disk_USB_____SanDisk_3.2Gen1
HardwareId	Vendor/product hardware ID string from Device Manager (top of the Hardware Ids list, including revision suffix). Format varies by manufacturer	Equivalent to DeviceId for most flash drives. Note: HardwareId values aren't unique — different physical devices can share the same string	USBSTOR\Disk_USB_____SanDisk_3.2Gen11.00
FriendlyNameId	The user-visible name Windows reports for the device	Useful for matching devices Windows tags as "Generic Mass Storage" or vendor-named generics	SanDisk 3.2Gen1 USB Device
BusId	Physical bus interface	Filter by interface — USB, SD, 1394 (FireWire)	USB

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

Some USB descriptors expose unusually long composite serial numbers — 100+ hexadecimal characters — that look synthetic but are real, captured from the drive's USB descriptor. This is common on drives with hardware-attestation features, IEEE 1667 silos, or certain SanDisk Ultra firmware revisions. The SerialNumberId example above is one such case: a real SanDisk Ultra USB 3.0 32 GB drive whose casing prints BM24080023944 reports a ~130-character hex string to Windows, completely unrelated to the printed label.

When you encounter a long enumerated serial, three things to do:

1. Verify the serial is per-drive, not per-machine. Plug the same drive into a second Windows machine and read the device instance path's trailing segment again. If it matches the first machine, the serial is the drive's identity and Patterns 2 and 3 work. If it differs, Windows is synthesizing the serial per-bus — fall back to a class- or hardware-ID match using HardwareId instead of SerialNumberId, accepting that you've lost per-drive specificity.
2. Don't type or hand-transcribe the serial. A 130-character hex string is impossible to type accurately, and even careful copy-paste can lose characters at the edges or normalize whitespace. Always copy directly from Device Manager → Properties → Details → Device instance path → right-click → Copy. The Intune Reusable Setting SerialNumberId field accepts the full string verbatim.
3. Embed the printed (label) serial in the Reusable Setting Name so audit logs cross-reference cleanly. Future operators looking at a Defender event or an Intune policy report will see only the long Windows-enumerated serial; the Name field is the only place to record the human-readable label that ties back to your asset register. Suggested format: <Vendor> <Model> — <user> — issued <date> — printed SN <label-serial>.

This isn't a bug or a misconfiguration. It's how some firmwares and some drive families expose themselves to Windows. Always trust the InstancePathId trailing segment — that's what Intune Device Control matches against, and it's what Defender Advanced Hunting events report. The printed label serves only as a human-readable cross-reference in your operational records.

Practical guidance

Which fields to populate depends on which of the three patterns you've chosen — VID_PID only for Pattern 1, VID_PID + SerialNumberId (with Match all) for Patterns 2 and 3. The remaining fields below (InstancePathId, DeviceId, HardwareId, FriendlyNameId, BusId) are alternative or additional matchers — populate them when your reference device exposes a non-standard USB descriptor and VID_PID alone doesn't uniquely identify it (see "Where to find the values" below).

• Where to find the values for any specific device:

  1. Plug the approved device into a Windows reference workstation.
  2. Open Device Manager → Disk drives (for USB flash drives) or Universal Serial Bus controllers (for non-storage USB peripherals).
  3. Right-click the device → Properties → Details tab.
  4. From the Property dropdown, select each of the following — what Device Manager shows maps directly to the Intune fields:

  Device Manager Property value	Maps to Intune field
  Hardware Ids (USB\VID_0781&PID_5581...)	First line gives VID (0781), PID (5581), and the underscore-joined VID_PID (0781_5581)
  Hardware Ids (USBSTOR\DiskSanDisk_Ultra... style line)	HardwareId
  Device instance path (USB\VID_0781&PID_5581\BM24080023944)	Whole string → InstancePathId. Trailing segment after the last \ → SerialNumberId. Middle segment → DeviceId. First segment (USB, USBSTOR) → BusId.
  Friendly name	FriendlyNameId

  Don't trust the printed serial number on the device label. Windows enumerates the serial via the device's USB descriptor; some manufacturers print a different SKU/lot code. Always confirm via the Device instance path's trailing segment.

5. Click OK to close the side panel, then Next through any remaining tabs, then Review + create.

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

The per-drive Reusable Setting from Step 1 identifies your approved hardware. The Device Control rule in Step 3 also needs a Reusable Setting that identifies the broad set the rule applies to — i.e., "all removable storage devices." This is what goes in the rule's Included Devices field, while the per-drive allowlist from Step 1 goes in Excluded Devices. Without this class-level setting, the rule has no scope.

You only need to create this one once per tenant; it's reused by every Device Control policy.

1. Repeat the navigation from Step 1: Endpoint Security → Attack Surface Reduction → Reusable Settings → Add.

2. Basics tab:

   • Name: Custom - Device Control - All Removable Media (class)
   • Description: Class-level identifier matching all removable storage devices. Referenced by Device Control rules' Included Devices field. Pair with per-drive allowlists in Excluded Devices.

3. Configuration settings tab:

   • Expand Device Control, click Add, choose Removable storage as the Object type.
   • Match type: Match any.
   • Click Configure settings in the row.

4. In the Configure removable storage instance panel, populate only the Name and PrimaryId fields:

   • Name: All RemovableMediaDevices (class)
   • PrimaryId: RemovableMediaDevices

   Leave every other field blank. PrimaryId is Microsoft's class-level identifier — RemovableMediaDevices matches every USB flash drive, SD card, and similar removable storage media regardless of vendor, model, or serial.

5. Click OK → Next → Review + create.

You now have two Reusable Settings: the per-drive allowlist from Step 1, and this class-level "all removable storage" set. Step 3 references both.

Step 3: Create the Device Control policy

1. Return to Endpoint Security → Attack Surface Reduction and click Create Policy.

2. Platform: Windows. (Currently the only option — Microsoft's docs note that Device Control isn't supported on Windows Server even though "This policy applies to" wording shows it.)

3. Profile: Device Control. Do not select "Attack Surface Reduction Rules" — that's a sibling profile type for ASR rules (Office macro blocks, credential stealing, etc.) and won't expose the Device Control category you need to reference your Reusable Setting. Click Create.

4. Basics tab:

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

5. Configuration settings tab. The Device Control wizard exposes several categories — Defender, Device Control, Device Installation Restrictions, Removable Storage Access, and others. For an MDE-managed allowlist using Reusable Settings, you'll work in two of them:

   1. Expand the Defender category and set Device Control Enabled to Enabled. Without this, the rules in the Device Control category won't take effect on managed devices.

   2. Expand the Device Control category. This is where the rule rows live. The pattern is two rules: one that blocks all removable storage for everyone, and a second that allows your approved drives — scoped (via the Allow entry's Sid) to the right user, group, or "everyone," depending on the pattern you chose. This is the Block-then-Allow pattern Microsoft documents in the device control walkthroughs. Don't put approved drives in Excluded Devices on the Block rule — Excluded Devices removes a drive from a rule's scope for every signed-in user, defeating any per-user or per-group binding. The carve-out lives in a second rule whose Allow entry's Sid scopes who is allowed.

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

   3. Click + Add under the ID section to create the first rule row. The row has five columns: Name, Included Devices, Excluded Devices, Access, plus a checkbox.

   4. Name (free-form text, required): This name appears in toast notifications shown to end users when their USB attempt is blocked, and in Defender Advanced Hunting RemovableStoragePolicyTriggered events. Suggested: Block removable storage — all users.

   5. Included Devices: click + Set reusable settings → select the class-level Reusable Setting from Step 2 (PrimaryId = RemovableMediaDevices). Click OK.

   6. Excluded Devices: leave empty for all three patterns. The approved-drive carve-out lives in Rule B, not here.

   7. Access: click the cell labeled Configure access (truncated as Configure insta... in narrow column widths, with a yellow ⚠ until you complete it). The Configure Access panel opens, showing a row table with columns Type / Options / Access mask / Sid / Computer ID. Two Entries are required — one for enforcement, one for audit. Both leave Sid empty so the rule applies to everyone.

      Entry 1 — Deny:

      Column	Value	Notes
      Type	Deny	The action
      Options	None	Dropdown is Type-aware. For Deny it shows two choices: None (= no override; any AuditDenied entry you add will fire normally) and Disable (= suppress any matching AuditDenied entry — block silently with no toast and no Defender event). Leave at None so the AuditDenied entry below can generate the SOC alert. Disable would defeat the audit pipeline you're building.
      Access mask	Open the dropdown — check all 7 boxes (Read, Write, Execute, File read, File write, File execute, Print). The cell will read "7 selected" when closed	Print is technically irrelevant for storage devices (it's a no-op), but checking it makes the rule maximally simple and deferential to "block everything." No downside
      Sid	Empty	Per-user/per-group scoping lives on Rule B's Allow entry. A Sid here would scope the deny to specific users — leaving everyone else unrestricted, the inverse of "block everyone."
      Computer ID	Empty	Per-device targeting is handled at the policy assignment layer, not here

      Click + Add at the top of the Configure Access panel to add a second row.

      Entry 2 — AuditDenied:

      Column	Value	Notes
      Type	AuditDenied	When you change Type from Deny to AuditDenied, the Options dropdown refreshes to show the audit-specific choices
      Options	Send notification and event	The dropdown for AuditDenied shows four choices — typically None, Send notification, Send event, Send notification and event (UI labels; the underlying integer values are 0/1/2/3 per Microsoft's reference docs). The fourth option (= integer value 3) is what makes the toast appear AND fires the RemovableStoragePolicyTriggered event in Defender Advanced Hunting that drives your SOC alert
      Access mask	Same as Entry 1 — all 7 boxes checked. The cell will read "7 selected"	Match the Deny entry exactly — every blocked operation gets audited. Mismatch between Deny and AuditDenied access masks would produce blocks that don't get audited, defeating the SOC pipeline
      Sid	Empty	Match the Deny entry; both Rule A entries apply to everyone
      Computer ID	Empty	Same as Entry 1

      Without an AuditDenied entry, the SOC alerting in Step 4 will not fire — the Defender custom detection rule listens for RemovableStoragePolicyVerdict == "Deny" events, and those events come from AuditDenied entries, not from Deny entries directly. The None value on the Deny entry's Options dropdown is permissive (lets the AuditDenied fire) — it does not mean "no audit needed."

      Click Save to close the Configure Access panel. The yellow ⚠ on the Access cell will clear.

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

   8. Click + Add under the ID section again to create a second rule row.

   9. Name (free-form text, required): Suggested format: Allow removable storage — <scope>. Examples — Pattern 1: Allow approved removable storage — all users. Pattern 2: Allow approved removable storage — USB Users. Pattern 3: Allow approved removable storage — Alice Cohen.

   10. Included Devices: click + Set reusable settings → select your per-drive allowlist Reusable Setting(s) from Step 1. Click OK.

       • Pattern 1 (class allowlist): the one vendor/model Reusable Setting.
       • Pattern 2 (pool + group): all N pool-drive Reusable Settings.
       • Pattern 3 (per-user): the one Reusable Setting for that user × drive issuance (e.g., SanDisk Ultra 32GB — Alice Cohen — issued 2026-04-28 — printed SN BM24080023944).

   11. Excluded Devices: leave empty.

   12. Access: click Configure access. For Patterns 2 and 3, two Entries are required — one to grant access, one to audit it. Pattern 1 (no per-user binding, out-of-CMMC-scope data) can skip the AuditAllowed entry; Patterns 2 and 3 cannot, because 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.

       Entry 1 — Allow:

       Column	Value	Notes
       Type	Allow	Allow has the highest precedence — when a drive matches both Rule A's Deny and Rule B's Allow, and the user matches the Allow's Sid, Allow wins for that user. Users who don't match the Sid fall through to Rule A's Deny.
       Options	None	Standard for Allow
       Access mask	Open the dropdown — check all 7 boxes. The cell will read "7 selected"	Full read/write/execute access on approved drives. For tighter restrictions (e.g., read-only access for a specific group), check only the read bits
       Sid	Patterns 2 and 3 user/group binding lives here. Paste an Entra Object ID (a GUID, e.g., 12345678-1234-1234-1234-123456789012). For Pattern 2, this is the security group's Object ID — Entra → Groups → <group> → Object ID. For Pattern 3, this is the user's Object ID — Entra → Users → <user> → Object ID. Empty for Pattern 1 — every signed-in user gets Allow on approved drives	Microsoft accepts an Entra group Object ID identically to a user Object ID; both map to the same <Sid> element on the entry
       Computer ID	Empty	Per-device targeting is handled at the policy assignment layer, not here

       Click + Add at the top of the Configure Access panel to add a second row.

       Entry 2 — AuditAllowed: (required for Patterns 2 and 3; skip for Pattern 1)

       Column	Value	Notes
       Type	AuditAllowed	Generates a RemovableStoragePolicyTriggered event with RemovableStoragePolicyVerdict == "Allow" for every approved-drive access — the system-of-record evidence CMMC 3.3.2 expects, and the input for Pattern 2's sign-out-ledger reconciliation
       Options	Send event	Same four choices as AuditDenied (None, Send notification, Send event, Send notification and event). Send event is the audit-only choice — produces the Defender event without a user-facing toast. Use Send notification and event only if you want users to see "approved drive in use" toasts on every access (most operations don't)
       Access mask	Same 7 boxes as Entry 1	Match the Allow entry so every authorized operation gets audited. If event volume becomes a real problem (large user pool with heavy file-copy workloads, not a hypothetical concern), narrow the mask to just file-write — preserves the per-write evidence trail and drops the per-read noise. Decide after measuring, not pre-emptively
       Sid	Same Entra Object ID as Entry 1	Mismatched Sid would produce gaps where one user is allowed but unaudited (or vice versa) — defeating 3.3.2 traceability
       Computer ID	Empty	Same as Entry 1

       Click Save to close the Configure Access panel.

   13. (Optional) Layered access — different groups, different access masks (e.g., one group full read/write, another read-only) — requires its own additional Allow rule with its own Sid. Microsoft's device control walkthroughs show the canonical multi-tier example.

   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 using the form-based path above. Sample XML — including the AuditDenied action that triggers SOC alerting — is in Chapter 29 § USB Device Control & SOC Alerting. Intune accepts the XML directly; no <?xml> declaration needed.

6. Scope tags — accept Default unless you have RBAC scope tags in use.

7. Assignments — target the device groups in scope for removable media restriction. Typically that's 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 the conditions that justify forking to a separate Svr - variant (different approved-drive list, different ops group, separate alerting).

8. Review + create.

Step 4: SOC alerting via Defender for Endpoint

The Device Control policy enforces the block. Surfacing real-time alerts when an unapproved device is plugged into a managed endpoint requires a separate Defender custom detection rule that watches for RemovableStoragePolicyTriggered events with a Deny verdict. Full KQL and the detection-rule creation steps are in 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 SanDisk on the pilot device	Read/write access 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 appears with RemovableStoragePolicyVerdict == "Deny"
MDE recorded the allow (Patterns 2 & 3 only)	Defender → Advanced hunting, same query	Row appears with RemovableStoragePolicyVerdict == "Allow" for the approved-drive plug-in, with AccountSid matching the user (or a member of the group)
Custom detection fires	Defender → Incidents	New incident at the configured severity within 5 minutes of the deny event