Driverless USB on Windows: how MSOS 2.0 works

A "driverless" USB device isn't really driverless — it makes Windows auto-load a driver it already ships, because the device advertises itself correctly. The mechanism that makes this happen is the Microsoft OS 2.0 descriptor.

The problem: the classic .inf driver

Historically, exposing a vendor-specific USB interface to Windows meant installing a signed .inf driver package. For the end user that was friction (admin rights, an installer, signature warnings), and for the vendor it was maintenance overhead.

The fix: MSOS 2.0 descriptors

Microsoft OS 2.0 descriptors are small data blocks embedded in the device's firmware. When the device is plugged in, Windows reads these blocks via a BOS (Binary Object Store) descriptor and learns: "use the WinUSB driver for this interface." WinUSB is a generic USB driver that ships with Windows; nothing is installed.

The result: the moment the device is plugged in, with no extra software, the vendor interface becomes available to an application (or to the browser via WebUSB). On a composite device the CDC-ACM interfaces also match by class code and automatically get the standard serial-port driver.

Its relationship to WebUSB

For WebUSB to work on Windows, the vendor interface must be bound to WinUSB — because that's how the browser reaches it. So MSOS 2.0 is also a prerequisite for driverless access from the browser. The Salixus family uses this pattern: a composite WebUSB vendor interface plus two CDC-ACM, recognized driverless on Windows 10/11 through MSOS 2.0 and class-code matching.

What it means in practice

• A field engineer plugs in and uses the device with no driver CD or download step.
• On a locked-down corporate machine, there is no install that needs admin rights.
• The same device can be used at the same time by the browser (WebUSB) and by classic serial software (the CDC ports).