Configuring Endpoint Security Exclusions for PathCam Systems – IT Administrator Guide

Audience: hospital IT and security engineering
Goal: help you enable PathCam camera acquisition on Windows while maintaining strong endpoint controls.
Scope: Windows endpoints running CrowdStrike Falcon with Device Control, Prevention Policies, and Detection Management. No screenshots – just precise UI paths in brackets.

Executive Summary

• Most camera connection failures in clinical labs trace to USB power, port topology, Windows device policies, or competing apps. In some environments security software policies can also block or disrupt camera access and media writes.
• The right approach is a minimal, well-scoped allow strategy – not blanket disablement. Use Device Control allow rules by device class or by Vendor ID and Product ID where appropriate, and avoid broad Sensor Visibility Exclusions unless absolutely necessary and time-bounded. (CrowdStrike)

What tends to break camera connection

• USB storage class blocked globally while the camera exposes storage or PTP/MTP interfaces that labs expect to enumerate. Falcon Device Control policies block mass storage by default in many orgs. (CrowdStrike)
  

  When the PathCam camera is connected to the PathCam Host PC, it typically presents itself to Windows using PTP (Picture Transfer Protocol) or MTP (Media Transfer Protocol) rather than as a standard USB mass-storage device. These protocols allow software such as PathCam to communicate directly with the camera for live preview, capture control, and image transfer. However, endpoint protection tools like Falcon Device Control may block these interfaces when “USB storage class” devices are restricted at the policy level. In such cases, the camera fails to enumerate properly and PathCam reports a “Missing Camera” error. To prevent this, IT administrators should explicitly whitelist or allow PTP/MTP devices on the designated PathCam Host PC ports.

• Sensor visibility or prevention blocks on PathCam working folders or binaries, or ML detections on image acquisition workflows. Exclusions exist, but carry risk if scoped too broadly. (Red Canary Support)
• Canon DSLR devices enumerate under Portable Devices using MTP or similar transport on Windows. Reinstalling the MTP device or verifying it appears under Portable Devices is normal troubleshooting. (Microsoft Learn)

Minimal viable allow strategy

Start with the smallest needle-moves-first adjustments. In order of preference:

1. Device Control – allow by device class when justified
   • If your lab strictly needs read access to removable media for the camera workflow, consider class-based allow rules with the least privilege action:
     • Mass Storage: consider Read Only or No Execute instead of Full Access.
     • Keep the policy scoped to a host group rather than global. [Falcon console -> Endpoint Security -> Device Control -> Policies]. (CrowdStrike)
2. Device Control – targeted allow by VID and PID
   • Create allow rules using Vendor ID and Product ID for known-safe devices. For Canon, USB Vendor ID is typically 04A9; PIDs vary by model. Confirm the exact VID and PID from Device Manager or Canon’s developer resources, then create allow entries. [Falcon console -> Endpoint Security -> Device Control -> Rules]. (developercommunity.usa.canon.com)
   • Action: Allow, Scope: the PathCam host group only.
3. Detections Management – specific exclusions
   • For known benign PathCam operations flagged by ML or IOAs, create Machine Learning exclusions and IOA exclusions scoped to the PathCam hosts or a tag, not organization-wide. [Falcon console -> Configuration -> Detections Management -> Exclusions -> Machine Learning or IOA tabs]. (Red Canary Support)
4. As a last resort only – Sensor Visibility Exclusions
   • This stops the sensor from recording or preventing activity for that path or process. Use only if you must, with tight scoping and a short expiry, because detections and preventions will not occur in that area. [Configuration -> Detections Management -> Exclusions -> Sensor Visibility]. (Red Canary Support)

Scoping and safety rails

• Scope by host group or tag – keep clinical capture stations separate from general desktops. You can dynamically exclude or include hosts by tags to move them between stricter and looser policies. (Reddit)
• Prefer allow rules tied to the hardware identifiers – VID, PID, and if necessary, device serial – over global class allowances. (CrowdStrike)
• Avoid org-wide Sensor Visibility Exclusions – use them only as a timed bridge with strict review. (Red Canary Support)
• Document risk and rollback – record policy names, rule IDs, owners, and change windows. See the rollout checklist below.

How to gather identifiers and verify on Windows

• Find VID and PID: [Device Manager -> View -> Devices by connection -> expand to the camera -> Properties -> Details tab -> Hardware Ids]. Canon cameras generally show VID_04A9 plus a PID_xxxx value. (developercommunity.usa.canon.com)
• Confirm enumeration: [Settings -> Bluetooth and devices -> Devices] and [Device Manager -> Portable Devices] should list the Canon device. If it shows as generic MTP USB Device, uninstall and replug to force re-enumeration. (Microsoft Learn)
• Validate after policy change: confirm the PathCam app can acquire the camera and write to the working directory or approved network share.

Common exclusion patterns that work in labs

• USB Device Control:
  • Rule type: USB device vendor or model
  • VID: 04A9, PID: [your camera’s PID], Action: Allow
  • Scope: Host group “Grossing Stations” only. (Inventive HQ)
• ML or IOA exclusions:
  • Target just the PathCam binary and working paths required for capture, and only on the lab hosts. Track in an exclusions register. (Red Canary Support)

Change control in healthcare

• Use a staged rollout – test on a single host, then the lab group.
• Time changes to a maintenance window and pre-brief clinical users.
• Maintain an exceptions log with owner, reason, scope, and review date.
• Consider recent resiliency lessons from large endpoint disruptions in 2024-2025 – minimize broad policy risk to clinical operations. (PMC)

References and further reading

• CrowdStrike – Falcon Device Control overview and FAQ – rule types by class, VID, PID, serial, and actions like full block, read-only, no execute, full access. (CrowdStrike)
• Red Canary – managing CrowdStrike exclusions – where to create ML, IOA, and sensor visibility exclusions. (Red Canary Support)
• Canon developer community – USB Vendor ID and Product ID notes for Canon cameras. (developercommunity.usa.canon.com)

Rollout checklist for IT change tickets

• Problem statement and clinical impact defined.
• PathCam host group defined – asset IDs and location recorded.
• Windows verification completed – Devices and Device Manager show Canon under Portable Devices.
• VID and PID captured and documented.
• Proposed Falcon changes:
  • Device Control rule by VID/PID with minimal action needed.
  • Optional ML or IOA exclusions scoped to host group.
  • Sensor Visibility Exclusion avoided or, if required, tightly scoped and time-boxed.
• Risk assessment completed and rollback defined.
• Maintenance window scheduled with lab.
• Post-change validation steps listed and assigned.
• Exception owner and review date noted.