USB VID, PID and serial numbers: an OEM flash-drive production guide

Custom logo printing is the visible part of an OEM USB flash drive. The host never sees the printed shell. It sees firmware descriptors: Vendor ID, Product ID, device release, manufacturer/product strings and, when present, a serial number.

If those fields are copied carelessly during mass production, the drives may still store files, but fleet inventory, driver matching, compliance and traceability can fail later.

VID identifies the responsible USB vendor

The USB Vendor ID (VID) is a 16-bit identifier assigned by USB-IF. USB-IF offers a VID through membership or as a separate purchase and states that assignment is for the company's use [1]. Its member agreement describes the VID and associated PIDs as assigned to one company for sole and exclusive use; unauthorized use is prohibited [3].

That creates a clear OEM question: whose company is the USB integrator of record?

USB-IF compliance policy says the VID used by a product should match the company producing the integrated product, not simply the silicon vendor's VID. If permission to use another company's VID exists, written permission is required in the compliance submission [2].

Practical routes include:

• the brand owner obtains and manages its own VID;
• the manufacturing partner remains the integrator and uses its VID under a written product/compliance arrangement;
• another arrangement is approved in writing where USB-IF policy allows it.

“The controller arrived with this number” is not a licensing strategy.

PID identifies a product under the VID

The Product ID (PID) is another 16-bit value managed under the VID. It lets the vendor distinguish products or firmware identities. The same VID can have many PIDs.

A controlled product map might separate:

• mass-storage product families;
• security-enabled versus ordinary drives;
• bootable or read-only variants;
• firmware branches with different host behavior;
• devices that require different drivers.

Do not create a new PID for every color when the USB behavior is identical without a reason. Do create a separate identity when the host, driver or compliance behavior differs. USB-IF's compliance policies require product/model identification to clearly represent the certified product and do not allow ambiguous variables for compliance-affecting features [2].

The bcdDevice field commonly represents the device release. Define how it changes with firmware or hardware revision and keep it tied to the approved BOM.

The serial number identifies the physical unit

VID and PID identify a product family, not an individual drive. The optional USB serial-number string can identify the physical instance.

Microsoft states that if a USB device has a serial number, it must uniquely identify each instance of the same device. If VID, PID and bcdDevice are identical, the serials must differ [4]. Windows uses these fields when building device identity and container relationships.

Duplicating one serial across a production lot can cause:

• asset systems to merge different drives;
• per-device allowlists or audit trails to become unreliable;
• cached policies and device instances to attach to the wrong physical unit;
• support teams to lose unit-level traceability.

If a serial is not required, reporting none can be better than reporting one fake “unique” value on every drive. If traceability matters, generate stable unique serials, validate them during production and store the mapping to lot and test result.

Microsoft also documents valid byte restrictions for USB serial strings; invalid characters can cause Windows to discard the serial and treat the device as if it had none [4].

Descriptor identity is not security

VID, PID, product strings and serial numbers can be queried by the host. A programmable controller can copy them. Therefore they can support inventory and device matching, but not strong authenticity.

Do not use a matching VID/PID as proof that:

• the NAND capacity is genuine;
• the drive came from an authorized factory;
• firmware has not been modified;
• the person holding it is authorized;
• the stored data is encrypted.

Security-sensitive deployments need cryptographic authentication, signed firmware, controlled key injection or backend enrollment designed for the threat model. Descriptor fields can be inputs to policy, but they are not secrets.

Put these fields in the OEM specification

Tie descriptor changes to the same controlled-change process used for NAND, controller and firmware. See fixed BOM for flash storage.

Mass-production acceptance test

Test more than one golden sample. Pull units across lots and capacities, then verify:

1. VID, PID, bcdDevice and strings match the approved table.
2. Every serial is valid, unique and stable across unplug/replug and reboot.
3. Several units connected at once enumerate as separate devices.
4. Windows, macOS and Linux identify the intended device class without unexpected drivers.
5. Sleep/resume, safe removal and surprise removal behave as specified.
6. Firmware revision and lot code map to the production record.
7. Full usable capacity passes write-and-verify testing; use our fake-capacity test procedure.
8. Any USB logo or certification claim matches the exact product and authorization.

Bottom line

An OEM USB drive needs an identity plan before mass production. Use a VID you are authorized to use, assign PIDs deliberately, version releases consistently and make every reported serial truly unique. Keep those fields tied to BOM, firmware, lot and test records. They make support and fleet control possible — but they do not replace cryptographic security or full-capacity validation.