How Do You Design USB Composite Device Descriptors for Multiple Interfaces?

Detailed Explanation

Most USB firmware examples start from a single-interface device — a CDC-ACM virtual COM port, or a HID device, on its own. Real products frequently need more than one interface from the same physical USB connection: a virtual serial port for logging or configuration alongside a HID interface for a control surface, or a mass-storage interface for firmware update files alongside a vendor-specific interface for the product's own control protocol. This is a composite device, and it introduces two descriptor-design concerns that don't exist for a single-interface device: telling the host which interfaces belong together as one function, and making sure interface and endpoint numbering doesn't collide across the whole device. For the enumeration sequence and general descriptor troubleshooting this builds on, see why is my USB device failing enumeration?

Why Composite Devices Need More Than Just Multiple Interfaces

A USB configuration descriptor can already declare multiple interfaces — that much is standard USB, not composite-specific. The problem composite devices actually solve is grouping: some device classes, most notably CDC-ACM, require two separate USB interfaces (a Communication Class interface for control/status and a Data Class interface for the actual byte stream) that only function correctly as a pair. Nothing in a plain configuration descriptor tells the host "interfaces 0 and 1 are not two independent things — they are one logical CDC function." Without that information, a host's driver-binding logic can attach drivers to each interface independently, which for CDC produces a broken virtual serial port even though both interfaces technically enumerated.

The Interface Association Descriptor (IAD)

The Interface Association Descriptor, added via a USB-IF Engineering Change Notice to USB 2.0, solves exactly this problem. It's a short descriptor placed in the configuration descriptor immediately before the first interface it describes, declaring: starting at interface number N, the next M consecutive interfaces are one function, with a specified class/subclass/protocol for the function as a whole.

To use IADs correctly:

• Set the device descriptor's bDeviceClass to 0xEF (Miscellaneous), bDeviceSubClass to 0x02, and bDeviceProtocol to 0x01. This specific combination is the signal to the host that it should look for IADs in the configuration descriptor rather than relying solely on the device-level class fields — using a plain bDeviceClass of 0x00 (defer to interface descriptors) alongside IADs is a common and confusing mistake that leads to inconsistent driver binding across host operating systems.
• Place one IAD immediately before each multi-interface function's first interface descriptor. For a device with a CDC-ACM function (2 interfaces) followed by a HID function (1 interface), the descriptor order is: IAD for the CDC function → CDC Communication interface → CDC Data interface → HID interface. The HID interface, being single-interface, does not need its own IAD, though some implementations add one for consistency and it is not incorrect to do so.
• Set bFirstInterface and bInterfaceCount correctly in each IAD — bFirstInterface must match the interface number of the immediately following interface descriptor, and bInterfaceCount must equal the actual number of consecutive interfaces belonging to that function. A mismatch here is a common cause of a composite device where one function enumerates correctly and the adjacent one silently fails driver binding.

Interface and Endpoint Numbering Across the Whole Device

Every interface in a composite device's configuration descriptor needs a unique bInterfaceNumber, assigned sequentially starting from 0 across the entire device, not restarting per function. Every endpoint (other than endpoint 0, shared for control transfers) needs a unique endpoint address within its direction (IN or OUT) across the entire device — reusing endpoint 1 IN in two different interfaces without deliberately intending endpoint sharing (which composite devices generally don't do) will cause one interface's data to silently interfere with the other's.

This numbering has to be planned across the whole descriptor set, particularly when composing a device from vendor SDK example code for each class — copying a standalone CDC example's descriptor block and a standalone HID example's descriptor block into the same device typically requires renumbering both interfaces and endpoints, since each example assumes it's the only interface in the device and starts numbering from 0 and endpoint 1.

String Descriptors for Interface-Level Identification

Each interface can optionally carry its own iInterface string descriptor index, which some hosts display when listing the device's individual functions (for example, Windows Device Manager showing separate entries per interface under one composite device). While not required for correct enumeration, distinct interface strings make a composite device meaningfully easier to identify and support in the field, especially once a product ships with more than one or two interfaces.

Practical Examples

An industrial data logger exposes a CDC-ACM virtual serial port (for a configuration/diagnostics terminal) and a vendor-specific bulk interface (for high-throughput logged-data download by the manufacturer's own PC application). The device descriptor uses the 0xEF/0x02/0x01 IAD signature; an IAD precedes the two-interface CDC function; the vendor-specific interface (class 0xFF) follows as a single, un-associated interface with its own bulk IN/OUT endpoint pair. On Windows, the CDC function binds automatically to the in-box usbser.sys driver, while the vendor interface requires a Microsoft OS Descriptor pointing Windows at the in-box WinUSB driver so the manufacturer's PC application can access it without shipping a custom signed driver.

A wearable device combines a HID interface (for a proprietary low-latency sensor-streaming protocol implemented as a vendor-defined HID report, avoiding the need for any custom driver at all since HID has universal OS support) with a DFU interface for firmware updates over USB. Both are single-interface functions and neither strictly requires an IAD, but the firmware still must ensure the two interfaces use non-overlapping interface numbers and endpoint addresses, and that SET_CONFIGURATION correctly activates both simultaneously as part of the same configuration rather than treating them as alternate configurations the host would have to choose between.

Design Considerations

• Validate composite descriptors against Windows first, since its composite driver (usbccgp.sys) is the strictest of the three major desktop USB stacks about IAD correctness and device-class-field consistency — a descriptor set that enumerates cleanly on Linux or macOS can still fail driver binding on Windows.
• Plan interface and endpoint numbering across the whole device up front, especially when combining descriptor blocks copied from separate single-function vendor SDK examples — each example typically assumes it owns interface 0 and endpoint 1, and both need renumbering to coexist.
• Use WinUSB via a Microsoft OS Descriptor for any vendor-specific interface, rather than shipping a custom signed kernel driver, unless there's a specific reason the interface needs kernel-level access.
• Keep wTotalLength in the configuration descriptor consistent with the full set of interfaces, IADs, and endpoints — a composite device's total descriptor length is easy to get wrong when combining descriptor blocks from multiple sources, and the resulting truncation shows up as a generic descriptor-parsing failure that's hard to trace back to the specific missing bytes.
• Zeus Design's embedded firmware team develops composite USB device firmware — combining CDC, HID, mass storage, and vendor-specific interfaces — for embedded products.

Common Mistakes

• Omitting the Interface Association Descriptor for a multi-interface function like CDC-ACM. Without it, drivers can bind to the Communication and Data interfaces independently and incorrectly, producing a virtual serial port that doesn't work even though both interfaces technically enumerated.
• Leaving bDeviceClass at 0x00 while also including IADs, or setting it incorrectly instead of the required 0xEF/0x02/0x01 signature — this inconsistency causes unpredictable, host-dependent driver-binding behaviour rather than a clean failure that's easy to diagnose.
• Reusing interface numbers or endpoint addresses when combining descriptor blocks from separate single-function examples. This is the single most common composite-device bug when assembling a new device from existing vendor sample code for each class.
• Getting bFirstInterface or bInterfaceCount wrong in an IAD. A mismatch here typically causes one function in the composite device to work while an adjacent one fails driver binding, which is confusing to debug because the failing function's own descriptors may be entirely correct in isolation.
• Assuming a descriptor set validated on Linux or macOS is complete. Test composite device driver binding on Windows specifically before considering the descriptor design finished, given how much stricter its composite driver is about descriptor correctness.