I think the best practice is to keep the policies separate by OS

Great question, dfuell​ 

The overall recommendation is to let Autopatch own drivers and firmware through its ring-based deployment. Start with Manual approval mode for BIOS/firmware so you can review each update and use Automatic mode for standard drivers.

1. Autopatch Driver/Firmware vs. OEM Tools (e.g., Dell Command Update)
2. The recommended approach is to pick one primary authority per device population for the same driver/firmware categories and avoid running both Autopatch and an OEM tool managing the same content on the same devices simultaneously.
3. Running both can cause conflicts: overlapping driver content from Windows Update and the OEM catalog, duplicate reboots, and inconsistent change-control tracking.
   
   

That said, a hybrid pattern can work:

• Windows Quality & Feature Updates, use Windows Autopatch
• General drivers (chipset, network, GPU, etc.), use Autopatch Driver Updates (Automatic or Manual mode)
• BIOS: Autopatch does not deploy BIOS updates, this remains an OEM-tool responsibility.
  
  

1. On Targeting Specific OEM Devices within Autopatch Rings:
   1. Yes, absolutely. You can achieve OEM-specific targeting through a combination of:
      1. Intune Assignment Filters: Create a filter using the device.manufacturer property (e.g., device.manufacturer -eq "Dell Inc.") to ensure driver policies or Dell Command Update only apply to Dell devices. You can also use device.model to target specific model families (e.g., Latitude vs. OptiPlex).
      2. OEM-specific Entra ID groups: Create dynamic device groups per-OEM (manufacturer = Dell, HP, Lenovo), then map those groups to dedicated Autopatch deployment rings.
      3. Dedicated Autopatch groups per-OEM: You can create separate Autopatch groups for different OEM fleets, each with their own ring topology and driver approval strategy. For example, a Dell-specific group with rings like Test - Ring 1 - Ring 2 - Last.

Hope this helps!

Another great question, dfuell​

Great question, and the short answer is: device-based compliance is the recommendation for shared-use Windows devices. A couple of points:

• There’s no persistent user affinity: Kiosks, conference rooms, and manufacturing workstations don't have a dedicated owner. User-based compliance ties the compliance state to a specific user context, and when that user doesn't log back in, the compliance context becomes stale, leading to devices being flagged as non-compliant and affecting Conditional Access and reporting.
• There are a few Device-level settings are what matter on shared devices, for instance, you're checking things like BitLocker encryption, Secure Boot, OS version, firewall status, and antivirus, all of which are device properties, not user properties. These persist regardless of whom signs in. Not to mention Windows updates.

• Don't mix user and device targeting for the same policy, we’d recommend you to pick one. For shared devices, always go with device group.
• Say you assign a compliance policy to your user group but exclude your Shared-Kiosks (device group). You'd expect kiosks to be excluded, but Intune evaluates group membership asynchronously. The user group inclusion processes first, and by the time the device group exclusion catches up, the policy has already applied. The kiosk gets the policy anyway, potentially marking it non-compliant and blocking access via Conditional Access.
• Instead, you can assign to your user group but add an Intune assignment filter in Exclude mode (e.g., (device.model -contains "Kiosk”). Intune Filters evaluate in real time at check-in.
• Or better yet, create a separate compliance policy assigned directly to your shared devices device group with rules tailored to those devices
• Bottom line: user group + device group exclusion = race condition. Use Intune Filters or separate policies instead.

My Intune friends can add some colors into this.

Hope this helps.