SentinelOne Device Control Configuration

SCENARIO

USB drives, external hard drives, and Bluetooth peripherals represent significant security risks in enterprise environments. Malicious actors use USB devices to deploy malware (BadUSB attacks), exfiltrate sensitive data, or bypass network security controls. Employees inadvertently introduce malware via infected USB drives or lose company data through unencrypted external storage. Bluetooth devices can be exploited for eavesdropping (BlueBorne) or unauthorized data access.

Use this guide when you need to:

• Prevent data exfiltration via USB drives, external hard drives, or Bluetooth file transfers
• Block BadUSB attacks (malicious USB devices that emulate keyboards or network adapters)
• Enforce read-only access for USB mass storage (allow reading files but prevent copying data out)
• Restrict Bluetooth connectivity to approved peripherals (headsets, mice) while blocking file transfer
• Comply with data protection regulations (PCI-DSS, HIPAA, GDPR) requiring removable media controls
• Allow approved USB devices (corporate-issued drives, licensed software dongles) while blocking unknown devices
• Reduce attack surface by disabling unused device classes (webcams, microphones, network adapters)

Business Impact:

• Data loss prevention: Block unauthorized USB drives from copying sensitive data
• Malware prevention: Prevent BadUSB attacks where malicious devices inject keystrokes or deploy payloads
• Compliance requirements: Meet audit requirements for removable media control (PCI-DSS 8.2.1, HIPAA 164.310)
• Intellectual property protection: Prevent employees from copying source code, customer data, or trade secrets to personal drives
• Insider threat mitigation: Limit data exfiltration capabilities for malicious insiders

SentinelOne Device Control provides centralized policy-based management of USB and Bluetooth devices on Windows and macOS endpoints without requiring additional agents or kernel drivers.

REQUIREMENTS & ASSUMPTIONS

Prerequisites:

• SentinelOne Singularity Control or Complete license: Device Control is included in Control tier and above
• Minimum agent version: 21.6 or later (verify with sentinelctl.exe status)
• Console access: Admin role with Policy Management permissions
• Supported operating systems:
  • Windows 10/11 (all editions)
  • Windows Server 2016/2019/2022
  • macOS 10.15 (Catalina) and later
  • Note: Linux device control is limited to basic USB mass storage blocking

License Verification: Check your console for Device Control availability:

Console > Settings > License > Modules: "Device Control" should be listed

Supported Device Types:

Assumptions:

• Administrators have identified business-critical USB devices (licensed software dongles, corporate-issued drives)
• Approved device allow-list is documented (vendor IDs, product IDs, serial numbers)
• Users have been notified of device control policies before enforcement
• Helpdesk is prepared to handle device approval requests

PROCESS

Step 1: Review current device usage before enforcement

Before deploying restrictive device control policies, audit current device usage to avoid blocking legitimate business tools.

1. Navigate to Console → Activity → Device Control Logs

2. Review device connection history (last 30 days):

   • What USB devices are users connecting?
   • Which devices are used frequently vs. once?
   • Are there any unexpected device types (USB network adapters, unknown keyboards)?

3. Identify business-critical devices:

   • Licensed software dongles (CAD software, CNC controllers, encryption keys)
   • Corporate-issued USB drives
   • Approved peripherals (webcams for video conferencing, headsets)
   • Authorized external drives for backups

4. Document device identifiers: For each approved device, record:

   • Vendor ID (VID): Manufacturer identifier (e.g., 0x04B4 for Cypress Semiconductor)
   • Product ID (PID): Specific product model (e.g., 0x5ABC for CyberKey dongle)
   • Serial Number: Unique device identifier (optional, most secure)
   • Device Class: Mass Storage, HID, Audio, etc.

5. Communicate policy changes to users:

   • Send email notification explaining:
     • Why device control is being implemented (security, compliance)
     • What devices will be blocked (personal USB drives, unauthorized Bluetooth)
     • What devices remain allowed (corporate-issued drives, approved peripherals)
     • How to request exceptions (helpdesk ticket process)

Result: You have an inventory of approved devices and users are aware of upcoming policy changes.

Step 2: Create a Device Control policy

1. Navigate to Console → Settings → Policies

2. Select a Site or Group to apply the policy (recommend testing on pilot group first)

3. Click on the policy name (e.g., "Corporate Office Policy")

4. Scroll to Device Control section and click Configure

5. Enable Device Control:

   • Toggle Device Control to ON

6. Select enforcement mode:

   Mode	Description	Recommended For
   Monitor Only	Log device connections but don't block anything	Initial deployment, policy tuning
   Enforce	Actively block devices based on policy rules	Production enforcement after testing

   Best Practice: Start with Monitor Only for 1-2 weeks to identify false positives, then switch to Enforce.

7. Configure default device behavior (what happens when a device is plugged in):

   Default Action	Description	Use Case
   Allow All	All devices are allowed unless explicitly blocked	Permissive environment (low-security)
   Block All	All devices are blocked unless explicitly allowed	High-security environment (recommended)
   Allow with Approval	Device is temporarily blocked, admin can approve in console	Moderate security, user flexibility

   Recommended: Select Block All (default deny) for maximum security, then create allow rules for approved devices.

8. Save policy configuration

Result: Device Control is enabled in monitoring mode for the selected site/group.

Step 3: Configure USB mass storage controls

USB mass storage (thumb drives, external HDDs) is the most common data exfiltration vector.

1. Navigate to Device Control policy → USB Devices → Mass Storage

2. Set default mass storage access:

   Access Level	Description	Use Case
   Block	Completely disallow USB mass storage	High-security environments, PCI-DSS cardholder data systems
   Read-Only	Allow reading files but block copying to device	Allow users to access files from USB but prevent data exfiltration
   Read-Write	Full access (default unsafe)	Low-security environments, approved corporate drives only

   Recommended: Set default to Block or Read-Only, then create allow rules for approved devices.

3. Create allow rules for approved USB drives:

   Rule Type A: Allow by Vendor + Product ID (device model)

   Rule Name: Corporate_Kingston_USB_Drives
   Description: Allow corporate-issued Kingston DataTraveler USB drives
   
   Match Criteria:
   - Device Class: Mass Storage
   - Vendor ID: 0x0951  (Kingston Technology)
   - Product ID: 0x1666  (DataTraveler model)
   
   Action: Allow Read-Write
   Scope: All sites
   

   Rule Type B: Allow by Serial Number (specific device instance - most secure)

   Rule Name: Approved_Backup_Drive_Accounting_Dept
   Description: Seagate external drive used for accounting file backups
   
   Match Criteria:
   - Device Class: Mass Storage
   - Vendor ID: 0x0BC2  (Seagate)
   - Product ID: 0x2320  (Expansion Portable)
   - Serial Number: NA8F2V9X  (unique device serial)
   
   Action: Allow Read-Write
   Scope: Site: Corporate HQ > Group: Accounting Department
   

   Rule Type C: Allow by Device Class (all USB drives for specific group)

   Rule Name: IT_Admin_Full_USB_Access
   Description: Allow IT administrators full USB drive access for troubleshooting
   
   Match Criteria:
   - Device Class: Mass Storage
   - (No vendor/product restrictions)
   
   Action: Allow Read-Write
   Scope: Group: IT Administrators
   

4. Configure read-only access for unknown devices (allow reading but block writing):

   Rule Name: Unknown_USB_ReadOnly
   Description: Allow users to read files from personal USB drives but prevent copying data to them
   
   Match Criteria:
   - Device Class: Mass Storage
   - Vendor ID: * (any)
   - Product ID: * (any)
   
   Action: Allow Read-Only
   Scope: All sites
   Priority: Low (only applies if no higher-priority rules match)
   

Result: USB mass storage is restricted to approved devices or read-only access, preventing data exfiltration.

Step 4: Configure USB device class controls

Beyond mass storage, USB devices can be exploited for attacks or data leakage.

1. Navigate to Device Control policy → USB Devices → Device Classes

2. Configure controls for each device class:

   Keyboards (BadUSB Protection):

   Device Class: Keyboards (HID)
   Default Action: Block
   
   Reason: Prevent BadUSB attacks where malicious devices emulate keyboards to inject commands
   
   Allow Rule:
   - Vendor ID: 0x046D (Logitech)
   - Product ID: 0xC52B (Logitech K120 keyboard)
   - Action: Allow
   - Scope: All sites
   

   Network Adapters (Data Exfiltration & Rogue Networks):

   Device Class: Network Adapters
   Default Action: Block
   
   Reason: Prevent:
   - Rogue WiFi adapters bypassing corporate network controls
   - USB Ethernet adapters used to bridge air-gapped networks
   - USB LTE modems for unmonitored internet access
   
   Allow Rule (if needed for IT troubleshooting):
   - Vendor ID: 0x0BDA (Realtek)
   - Product ID: 0x8153 (USB Ethernet adapter)
   - Action: Allow
   - Scope: Group: IT Administrators
   

   Webcams (Privacy & Surveillance Risks):

   Device Class: Video (Imaging Devices)
   Default Action: Block
   
   Reason: Prevent unauthorized recording or surveillance in secure areas
   
   Allow Rule (for conference rooms with video conferencing):
   - Vendor ID: 0x046D (Logitech)
   - Product ID: 0x0825 (Logitech Webcam C270)
   - Action: Allow
   - Scope: Site: Corporate HQ > Group: Conference Room Devices
   

   Audio Devices (Headsets, Speakers):

   Device Class: Audio
   Default Action: Allow
   
   Reason: Business-critical for video conferencing and communication
   
   Block Rule (specific unauthorized devices if needed):
   - Vendor ID: 0xXXXX (suspicious vendor)
   - Action: Block
   

   Smart Card Readers (Access Control):

   Device Class: Smart Cards (CCID)
   Default Action: Allow
   
   Reason: Required for PIV/CAC authentication in government/DoD environments
   

   Printers:

   Device Class: Printers
   Default Action: Allow
   
   Reason: Business-critical for printing documents
   
   Block Rule (unauthorized personal printers):
   - Device Class: Printers
   - NOT (Vendor ID IN (0x03F0, 0x04B8, 0x04A9))  # HP, Epson, Canon
   - Action: Block
   

Result: Device classes are restricted based on security requirements, blocking BadUSB attacks and unauthorized peripherals.

Step 5: Configure Bluetooth device controls

1. Navigate to Device Control policy → Bluetooth Devices

2. Set default Bluetooth behavior:

   Default Action	Description	Use Case
   Allow All	All Bluetooth devices permitted	Low-security environments
   Block All	All Bluetooth disabled	High-security, air-gapped networks
   Allow Specific	Block all except approved device types	Recommended for most environments

   Recommended: Select Allow Specific (allow Bluetooth HID devices like mice/keyboards, block file transfer)

3. Configure Bluetooth device type restrictions:

   Bluetooth HID (Keyboards, Mice) - Allow:

   Device Type: Bluetooth HID (Human Interface Device)
   Action: Allow
   
   Reason: Business-critical for wireless keyboards and mice
   

   Bluetooth Audio (Headsets, Speakers) - Allow:

   Device Type: Bluetooth Audio
   Action: Allow
   
   Reason: Required for wireless headsets during video calls
   

   Bluetooth File Transfer (OBEX) - Block:

   Device Type: Bluetooth File Transfer (OBEX Push Profile)
   Action: Block
   
   Reason: Prevent data exfiltration via Bluetooth file sharing to smartphones/tablets
   

   Bluetooth Tethering - Block:

   Device Type: Bluetooth Personal Area Network (PAN)
   Action: Block
   
   Reason: Prevent users from bypassing corporate network via smartphone tethering
   

4. Restrict Bluetooth protocol versions (reduce attack surface):

   Minimum Bluetooth Version: Bluetooth 5.0 or later
   
   Reason: Older Bluetooth versions (1.x, 2.x) have known vulnerabilities (BlueBorne, etc.)
   Action: Block Bluetooth devices using protocols older than 5.0
   

5. Create allow rules for approved Bluetooth devices (if needed):

   Rule Name: Approved_Logitech_Bluetooth_Mouse
   Description: Corporate-issued Logitech MX Master 3 wireless mouse
   
   Match Criteria:
   - Device Type: Bluetooth HID
   - Vendor ID: 0x046D (Logitech)
   - Product ID: 0xB023 (MX Master 3)
   
   Action: Allow
   Scope: All sites
   

Result: Bluetooth devices are controlled, allowing business peripherals while blocking data exfiltration via file transfer.

Step 6: Test device control policies in Monitor mode

Before enforcing policies, validate rules work as expected.

1. Verify policy is in Monitor Only mode:

   • Console → Settings → Policies → [Policy Name] → Device Control
   • Enforcement Mode: Monitor Only

2. Test USB mass storage blocking:

   • On a test endpoint with SentinelOne agent, plug in:
     • Approved USB drive (matches allow rule)
     • Unapproved USB drive (should be blocked when enforced)
     • Unknown USB drive (should be read-only if configured)

3. Review device control activity logs:

   • Console → Activity → Device Control Logs
   • Verify events are logged:

     Example Log Entries:
     - Device Connected: Kingston DataTraveler (VID:0x0951, PID:0x1666) → ALLOWED
     - Device Connected: SanDisk Cruzer (VID:0x0781, PID:0x5567) → BLOCKED (would be blocked in Enforce mode)
     - Device Connected: Generic USB Drive (VID:0xXXXX) → READ-ONLY (would be read-only in Enforce mode)
     

4. Test Bluetooth device connections:

   • Pair a Bluetooth mouse → Should be allowed (HID device)
   • Attempt Bluetooth file transfer from smartphone → Should be blocked (OBEX profile)
   • Check logs for Bluetooth events

5. Test device class controls:

   • Plug in USB network adapter → Should be blocked (if policy blocks network adapters)
   • Plug in USB webcam → Should be blocked/allowed based on policy
   • Check logs for device class events

6. Review logs for false positives:

   • Identify legitimate business devices that were blocked
   • Create allow rules for these devices
   • Update policy and re-test

Result: Policy is validated in Monitor mode before enforcement, reducing business disruption.

Step 7: Enforce device control policies

After testing and tuning in Monitor mode, switch to active enforcement.

1. Review and finalize allow rules:

   • Ensure all business-critical devices have allow rules
   • Document approved devices in a spreadsheet/wiki for future reference
   • Notify users one more time before enforcement begins

2. Switch to Enforce mode:

   • Console → Settings → Policies → [Policy Name] → Device Control
   • Change Enforcement Mode from Monitor Only to Enforce
   • Click Save Changes

3. Policies take effect within 60 seconds (agents receive policy update from console)

4. Monitor initial enforcement:

   • Console → Activity → Device Control Logs
   • Watch for blocked device events
   • Prepare helpdesk for user support requests

5. Expected user experience when device is blocked:

   Windows: User sees notification:

   Device Blocked by Security Policy
   
   The USB device you connected has been blocked by your organization's security policy.
   Contact IT support if you need access to this device.
   
   Device: Kingston DataTraveler 3.0
   Reason: Unauthorized USB mass storage device
   

   macOS: User sees notification:

   Device Blocked
   
   The device you connected is not allowed by your organization's security policy.
   Contact your administrator for assistance.
   

6. Helpdesk workflow for device approval requests:

   • User submits ticket: "Need access to USB drive for project X"
   • IT reviews request for business justification
   • If approved:
     • Identify device VID/PID/Serial from device control logs
     • Create allow rule in SentinelOne policy
     • Rule takes effect within 60 seconds
     • Notify user to reconnect device

Result: Device control policies are actively enforcing USB and Bluetooth restrictions.

Step 8: Handle device approval requests

1. User reports blocked device:

   • User contacts helpdesk: "My USB drive is blocked"

2. Locate device in activity logs:

   • Console → Activity → Device Control Logs
   • Filter: User = [username] OR Endpoint = [computer name]
   • Find the blocked device event:

     Timestamp: 2025-11-26 14:30:22
     Device: Generic USB Flash Drive
     Vendor ID: 0x13FE
     Product ID: 0x4200
     Serial Number: 0123456789ABCDEF
     Action Taken: BLOCKED
     Reason: Default policy - unapproved mass storage device
     

3. Verify business need:

   • Ask user: Why do you need this USB drive?
   • Acceptable reasons:
     • Project deliverable for client (encrypted drive)
     • Backup for critical files
     • Licensed software dongle
   • Unacceptable reasons:
     • Personal convenience ("I want to copy files to my home computer")
     • Bypassing network file shares

4. Create temporary or permanent allow rule:

   Temporary Approval (for one-time use):

   Rule Name: Temp_Approval_User_JDoe_USB_Drive
   Description: Temporary access for John Doe's client deliverable project
   
   Match Criteria:
   - Vendor ID: 0x13FE
   - Product ID: 0x4200
   - Serial Number: 0123456789ABCDEF  (specific device)
   
   Action: Allow Read-Write
   Scope: Group: [User's group] or Endpoint: [User's computer]
   Expiration: 7 days (auto-delete rule after expiration)
   

   Permanent Approval (for ongoing business need):

   Rule Name: Approved_User_JDoe_Backup_Drive
   Description: Seagate external drive for John Doe's weekly backups
   
   Match Criteria:
   - Serial Number: NA8F2V9X  (unique device)
   
   Action: Allow Read-Write
   Scope: Endpoint: JDoe-Laptop
   Expiration: None
   

5. Save rule and notify user:

   • Click Save Changes
   • Policy updates to endpoints within 60 seconds
   • Notify user: "Your USB drive is now approved. Please reconnect it."

6. Document the approval:

   • Update helpdesk ticket with approval details
   • Log device serial number and user in approved device inventory

Result: Legitimate business devices are approved while maintaining security controls.

Step 9: Monitor and audit device control activity

1. Daily: Review blocked device events:

   • Console → Activity → Device Control Logs
   • Filter: Action = BLOCKED
   • Identify patterns:
     • Repeated blocks of same device = user needs approval
     • Unusual device types (network adapters, keyboards) = potential BadUSB attack

2. Weekly: Generate device control compliance report:

   • Console → Reports → Device Control Activity
   • Metrics to track:
     • Total devices connected (last 7 days)
     • Blocked devices count
     • Approved device usage
     • Most common blocked device types
     • Users with most block events (may need training)

3. Monthly: Audit approved device list:

   • Review all device allow rules
   • Remove stale rules (expired temporary approvals, decommissioned devices)
   • Verify business justification for permanent approvals

4. Quarterly: Policy tuning:

   • Analyze false positive rate (legitimate devices blocked due to misconfigured rules)
   • Update vendor/product IDs for new approved devices
   • Adjust default access levels if needed (e.g., move from Block All to Read-Only for mass storage)

Result: Device control policies remain effective and aligned with business needs.

VERIFICATION

Verify Device Control is active:

1. Check policy status:

   Console → Settings → Policies → [Policy Name] → Device Control
   - Device Control: ON
   - Enforcement Mode: Enforce
   

2. Verify agent receives policy:

   • On a managed endpoint, run:

     # Windows
     & "C:\Program Files\SentinelOne\Sentinel Agent *\SentinelCtl.exe" policy show
      
     # Look for "Device Control: Enabled"

3. Test USB blocking:

   • Plug in an unapproved USB drive on a managed endpoint
   • Expected result: Device is blocked, user sees notification, event logged in console

4. Test Bluetooth blocking:

   • Attempt Bluetooth file transfer from smartphone to managed endpoint
   • Expected result: File transfer fails, event logged in console

5. Test approved device:

   • Plug in an approved USB drive (matches allow rule)
   • Expected result: Device works normally, event logged as ALLOWED

TROUBLESHOOTING

Issue: Device control policies not applying

Symptoms: USB devices are not blocked despite policy set to Enforce

Solutions:

1. Verify agent version:

   & "C:\Program Files\SentinelOne\Sentinel Agent *\SentinelCtl.exe" status
   # Agent version must be 21.6 or later

2. Check agent connectivity:

   & "C:\Program Files\SentinelOne\Sentinel Agent *\SentinelCtl.exe" status
   # "Management connectivity: Connected"

3. Force policy refresh:

   Restart-Service -Name "SentinelAgent" -Force

4. Verify policy scope:

   • Console → Settings → Policies → [Policy Name]
   • Check Scope: Ensure the endpoint's site/group is included

Issue: Approved device still blocked

Symptoms: Device matches allow rule but is still blocked

Solutions:

1. Verify rule priority:

   • Device Control rules are processed in order (highest priority first)
   • If a higher-priority block rule matches the device, it will be blocked
   • Solution: Increase priority of the allow rule or remove conflicting block rule

2. Check exact device identifiers:

   • VID/PID must match exactly (case-sensitive hex values)
   • Serial numbers are case-sensitive
   • Verify identifiers in device control logs match the allow rule

3. Verify rule scope:

   • Allow rule may be scoped to a different site/group
   • Expand scope to include the user's endpoint

4. Wait for policy update:

   • Policy changes take up to 60 seconds to propagate to endpoints
   • Unplug and replug device after policy update

Issue: Read-only USB not working (files cannot be read)

Symptoms: USB drive set to Read-Only but user cannot access files

Solutions:

1. Check file system permissions:

   • Windows may still enforce NTFS permissions even in read-only mode
   • Verify user has read permissions on the USB drive

2. Verify USB drive health:

   • Drive may be corrupted or have bad sectors
   • Test drive on a non-SentinelOne computer

3. macOS-specific: Grant Full Disk Access to SentinelOne:

   • System Preferences → Security & Privacy → Privacy → Full Disk Access
   • Add SentinelOne agent

Issue: Bluetooth devices not blocked

Symptoms: Bluetooth file transfer works despite policy blocking OBEX profile

Solutions:

1. Verify Bluetooth stack compatibility:

   • Some Bluetooth adapters use proprietary stacks not fully controlled by OS
   • SentinelOne controls OS-level Bluetooth, not hardware-level

2. Check macOS Bluetooth permissions:

   • System Preferences → Security & Privacy → Bluetooth
   • Verify SentinelOne has Bluetooth permissions

3. Restart Bluetooth service (Windows):

   Restart-Service -Name "bthserv" -Force

COMMANDS/SCRIPTS

PowerShell script to audit USB device connections:

<#
.SYNOPSIS
    Audit USB device connections from SentinelOne console
.DESCRIPTION
    Retrieves device control activity logs and generates USB usage report
.PARAMETER ApiToken
    SentinelOne API token
.PARAMETER ConsoleUrl
    SentinelOne console URL
.PARAMETER Days
    Number of days to audit (default: 30)
.EXAMPLE
    .\Audit-S1-DeviceControl.ps1 -ApiToken "abc123" -ConsoleUrl "https://yourtenant.sentinelone.net" -Days 7
#>
 
param(
    [Parameter(Mandatory=$true)]
    [string]$ApiToken,
 
    [Parameter(Mandatory=$true)]
    [string]$ConsoleUrl,
 
    [Parameter(Mandatory=$false)]
    [int]$Days = 30
)
 
$ErrorActionPreference = 'Stop'
 
$headers = @{
    "Authorization" = "ApiToken $ApiToken"
    "Content-Type" = "application/json"
}
 
Write-Host "=== SentinelOne Device Control Audit ===" -ForegroundColor Cyan
 
$startDate = (Get-Date).AddDays(-$Days).ToString("yyyy-MM-ddTHH:mm:ss.fffZ")
 
# Retrieve device control activity
Write-Host "[1/2] Retrieving device control activity (last $Days days)..." -ForegroundColor Yellow
 
$activityFilter = @{
    createdAt__gte = $startDate
    activityTypes = @(2001, 2002, 2003)  # Device connected, blocked, approved
}
 
$activity = Invoke-RestMethod -Uri "$ConsoleUrl/web/api/v2.1/activities" -Headers $headers -Method Get -Body $activityFilter
 
Write-Host "[SUCCESS] Retrieved $($activity.data.Count) device events" -ForegroundColor Green
 
# Parse and analyze activity
Write-Host "[2/2] Analyzing device connections..." -ForegroundColor Yellow
 
$deviceStats = @{
    TotalConnections = 0
    BlockedDevices = 0
    AllowedDevices = 0
    UniqueDevices = @{}
    BlockedByType = @{}
    TopUsers = @{}
}
 
foreach ($event in $activity.data) {
    $deviceStats.TotalConnections++
 
    if ($event.data.action -eq "blocked") {
        $deviceStats.BlockedDevices++
 
        $deviceType = $event.data.deviceType
        if (-not $deviceStats.BlockedByType.ContainsKey($deviceType)) {
            $deviceStats.BlockedByType[$deviceType] = 0
        }
        $deviceStats.BlockedByType[$deviceType]++
    }
    else {
        $deviceStats.AllowedDevices++
    }
 
    # Track unique devices
    $deviceId = "$($event.data.vendorId):$($event.data.productId)"
    if (-not $deviceStats.UniqueDevices.ContainsKey($deviceId)) {
        $deviceStats.UniqueDevices[$deviceId] = @{
            VendorID = $event.data.vendorId
            ProductID = $event.data.productId
            DeviceName = $event.data.deviceName
            Count = 0
        }
    }
    $deviceStats.UniqueDevices[$deviceId].Count++
 
    # Track users
    $username = $event.data.username
    if (-not $deviceStats.TopUsers.ContainsKey($username)) {
        $deviceStats.TopUsers[$username] = 0
    }
    $deviceStats.TopUsers[$username]++
}
 
# Generate report
$report = @"
================================================================================
SENTINELONE DEVICE CONTROL AUDIT REPORT
================================================================================
 
AUDIT PERIOD: Last $Days days ($(Get-Date $startDate -Format 'yyyy-MM-dd') to $(Get-Date -Format 'yyyy-MM-dd'))
 
SUMMARY
-------
Total Device Connections:  $($deviceStats.TotalConnections)
Allowed Devices:           $($deviceStats.AllowedDevices)
Blocked Devices:           $($deviceStats.BlockedDevices)
Unique Devices:            $($deviceStats.UniqueDevices.Count)
 
BLOCKED DEVICES BY TYPE
-----------------------
$($deviceStats.BlockedByType.GetEnumerator() | Sort-Object Value -Descending | ForEach-Object { "  $($_.Key): $($_.Value)" } | Out-String)
 
TOP USERS (by connection count)
-------------------------------
$($deviceStats.TopUsers.GetEnumerator() | Sort-Object Value -Descending | Select-Object -First 10 | ForEach-Object { "  $($_.Key): $($_.Value) connections" } | Out-String)
 
TOP DEVICES (by connection count)
---------------------------------
$($deviceStats.UniqueDevices.Values | Sort-Object Count -Descending | Select-Object -First 10 | ForEach-Object {
    "  $($_.DeviceName) (VID:$($_.VendorID), PID:$($_.ProductID)): $($_.Count) connections"
} | Out-String)
 
RECOMMENDATIONS
---------------
- Review blocked devices with high connection counts (users may need approval)
- Investigate users with excessive device connections (potential policy violations)
- Identify commonly used devices and create allow rules to reduce helpdesk load
 
================================================================================
"@
 
$reportPath = "C:\Temp\SentinelOne-DeviceControl-Audit-$(Get-Date -Format 'yyyyMMdd-HHmmss').txt"
$report | Out-File -FilePath $reportPath -Encoding UTF8
 
Write-Host "[SUCCESS] Audit report generated" -ForegroundColor Green
Write-Host "Report saved to: $reportPath"
Write-Host "`n$report"

REFERENCES

• SentinelOne Device Control Feature Spotlight
• Enhanced USB & Bluetooth Device Control
• Singularity Control Features
• How to Block USB Device Access (Addigy Guide)

Document Version: 1.0 Last Updated: 2025-11-26 Author: CosmicBytez IT Operations Reviewed By: Security Operations Team

Related Reading

• SentinelOne Control vs Complete Feature Comparison
• SentinelOne MSP Client Onboarding
• SentinelOne Policy Configuration Best Practices