Share via

USB flash drives

abdo elbarbary 65 Reputation points
2026-06-01T12:26:12.6066667+00:00

we are experiencing problems with the approval and usage of newly purchased through Microsoft Defender Attack Surface Reduction (ASR) device control policies.

Affected Devices:

  • SanDisk Cruzer Glide 32GB
  • SanDisk Cruzer Glide 64GB
  • SanDisk Cruzer Glide 256GB

Observed Behavior:

  • The new USB drives are being approved/allowed based on their device identifiers through the existing ASR device control configuration.
  • Despite being added to the allow list, access to the devices is still blocked.
  • Upon connecting the USB drives, users receive an "Access Denied" message and cannot use the devices.

Comparison with Working Devices:

  • Older SanDisk Cruzer Glide USB drives (manufactured approximately 2–3 years ago) function correctly under the same policy configuration.
  • The older devices have shorter serial numbers and are successfully recognized and allowed by the policy.
  • The newly manufactured devices have significantly longer serial numbers, and these devices are not being permitted despite being explicitly approved.

Potential Area of Investigation:

  • Verify whether the longer serial number format is causing a mismatch with the device control policy conditions.
  • Compare the hardware IDs, serial numbers, and device instance paths between working and non-working devices.
  • Validate whether there are any character length limitations, formatting differences, or policy matching issues related to serial number-based device control rules.

Business Impact: Users are unable to use newly procured SanDisk USB storage devices, preventing the organization's standard USB device approval process from functioning as expected.

Expected Behavior: Once the USB device is added to the ASR/Device Control allow list, the device should be recognized and accessible regardless of serial number length.Issue Description:

The customer is experiencing problems with the approval and usage of newly purchased USB flash drives through Microsoft Defender Attack Surface Reduction (ASR) device control policies.

Affected Devices:

  • SanDisk Cruzer Glide 32GB
  • SanDisk Cruzer Glide 64GB
  • SanDisk Cruzer Glide 256GB

Observed Behavior:

  • The new USB drives are being approved/allowed based on their device identifiers through the existing ASR device control configuration.
  • Despite being added to the allow list, access to the devices is still blocked.
  • Upon connecting the USB drives, users receive an "Access Denied" message and cannot use the devices.

Comparison with Working Devices:

  • Older SanDisk Cruzer Glide USB drives (manufactured approximately 2–3 years ago) function correctly under the same policy configuration.
  • The older devices have shorter serial numbers and are successfully recognized and allowed by the policy.
  • The newly manufactured devices have significantly longer serial numbers, and these devices are not being permitted despite being explicitly approved.

Potential Area of Investigation:

  • Verify whether the longer serial number format is causing a mismatch with the device control policy conditions.
  • Compare the hardware IDs, serial numbers, and device instance paths between working and non-working devices.
  • Validate whether there are any character length limitations, formatting differences, or policy matching issues related to serial number-based device control rules.

Business Impact:
Users are unable to use newly procured SanDisk USB storage devices, preventing the organization's standard USB device approval process from functioning as expected.

Expected Behavior:
Once the USB device is added to the ASR/Device Control allow list, the device should be recognized and accessible regardless of serial number length.

Windows for business | Windows Client for IT Pros | Devices and deployment | Configure application groups
0 comments

3 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Domic Vo 24,370 Reputation points Independent Advisor
    2026-06-07T13:32:17.3633333+00:00

    Hi abdo elbarbary,

    Has your issue been resolved yet? If it has, please consider accepting the answer as it helps others sharing the same problem benefit too. Thank you :)

    Domic V.

    Was this answer helpful?

    0 comments
  2. Domic Vo 24,370 Reputation points Independent Advisor
    2026-06-01T13:24:52.55+00:00

    Hi abdo elbarbary,

    The access restriction you are encountering occurs because the Attack Surface Reduction engine is struggling to parse the unusually long serial numbers embedded within the Device Instance Path of your newly manufactured drives. When you insert a USB device, the Windows Plug and Play subsystem generates a unique identifier string stored in the registry at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR, which combines the vendor, product, and serial number. Because your new drives exceed the expected string length or contain unexpected characters in the serial number suffix, the Device Control policy evaluation fails and defaults to blocking access.

    To resolve this, you must modify your Defender Device Control configuration to match these specific devices based on their Hardware ID rather than their exact Instance Path. You can extract the correct hardware string by connecting one of the blocked SanDisk drives to a test machine, opening an elevated PowerShell session, and running the Get-PnpDevice command filtered by the USB class. Once you have this base identifier, locate the authorized USB group definition in your primary Device Control XML file or Intune OMA-URI payload, replace the InstancePathId property with the HardwareId property, and paste in your extracted value. Deploying this updated configuration instructs the policy engine to authorize the drives based strictly on their manufacturer and product model signatures, completely neutralizing the parsing failures caused by the elongated serial numbers.

    Domic V.

    Was this answer helpful?

    0 comments

  3. AI answer

    2026-06-01T12:26:44.32+00:00

    The described behavior aligns with a policy‑matching or layering issue in device control rather than a documented serial‑number length limit.

    Use the following checks and adjustments:

    1. Confirm the devices are in scope of Defender device control
    • Ensure the new SanDisk drives are recognized as removable media devices that create a disk (for example, E:). Device control in Microsoft Defender for Endpoint only applies to devices that present as removable media and create a drive letter.
    • If they do not create a disk, they are out of scope for MDE device control and must instead be controlled via device installation restrictions or other mechanisms.
    1. Verify default enforcement and scope
    • If using Intune/OmaUri for device control, confirm:
      • ./Vendor/MSFT/Defender/Configuration/DeviceControlEnabled = 1
      • ./Vendor/MSFT/Defender/Configuration/DefaultEnforcement = 2 (DefaultDeny)
      • ./Vendor/MSFT/Defender/Configuration/SecuredDevicesConfiguration = RemovableMediaDevices
    • On an affected endpoint, run Get-MpComputerStatus and verify:
      • DeviceControlState : Enabled
      • DeviceControlDefaultEnforcement : DefaultDeny
    • This ensures that the deny‑all baseline is active and that removable media devices are the secured class.
    1. Validate allow list entries using actual device properties
    • For each new SanDisk device, collect the exact identifiers from Device Manager:
      • Open Device Manager → locate the USB disk → Properties → Details.
      • Capture Device instance path / InstancePathId, hardware IDs, and any other properties used in the allow rules.
    • Compare these values between:
      • Older (working) SanDisk devices.
      • New (blocked) SanDisk devices.
    • Ensure the allow group (for example, an “Authorized USBs” group) uses the correct property and full value for the new devices. If using InstancePathId, copy it exactly from Device Manager for the new drives.
    1. Check policy grouping and exclusions
    • Confirm that the group containing the new SanDisk devices is configured similarly to the working “Authorized USBs” example:
      • The authorized group is defined using a supported property (such as InstancePathId).
      • That group is explicitly excluded from the global deny‑all policy.
    • If the deny‑all policy is not excluding the authorized group, the devices will remain blocked even when they match the allow rule.
    1. Inspect policy layering and GPO conflicts
    • If Group Policy is also used for removable storage control:
      • Use gpresult /h gpresult.html and rsop.msc to verify which GPOs apply to the affected machines.
      • Check for user‑level “Removable Storage Access” policies that might be blocking access regardless of Defender device control.
    • If allowlisting is done via device instance ID while a “Deny all removable storage” GPO is present:
      • Move block policies to computer‑level GPO.
      • Remove user‑level “Removable Storage Access” policies.
      • Create a new computer‑level GPO and enable “Apply layered order” for allow/deny device installation.
      • Block by setup class for USB drives and ensure allow rules are evaluated correctly.
    1. Use Advanced Hunting and logs to confirm matching
    • Use Advanced Hunting in Microsoft Defender for Endpoint to check for events such as PnPDeviceAllowed or device control events when the new drives are inserted.
    • Confirm whether the devices are being:
      • Evaluated and explicitly denied by device control, or
      • Blocked earlier by device installation restrictions or GPO.
    • If PnPDeviceAllowed appears but access is still denied, this indicates that device installation is allowed but another layer (removable storage policy or device control default deny) is blocking access.
    1. Re‑test with a minimal policy
    • For one test machine:
      • Apply a simplified device control configuration: a deny‑all removable media policy plus a single allow group containing the new SanDisk device’s exact InstancePathId.
      • Ensure that group is excluded from the deny‑all policy.
      • Reinsert the device and verify access.
    • If the device works under this minimal policy, the issue is likely due to additional GPOs or overlapping device control policies in the production configuration.
    1. Consider device installation restrictions if needed
    • If the organization also uses device installation restrictions (via GPO or Intune ADMX) to control USB devices:
      • Verify that the new devices’ IDs and setup class GUIDs are not inadvertently blocked.
      • Ensure that any allowlisting by device ID or instance ID is correctly configured and that “Apply layered order” is enabled so allow rules can override broad deny rules.

    These steps focus on confirming that the new devices’ exact identifiers are used, that they are properly excluded from the deny‑all policy, and that no overlapping GPO or device installation restriction is overriding the Defender device control allow list.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.