Is a custom Windows deployment USB worth building for Autopilot?

I’d separate the clean-install problem from the enrollment problem. A custom USB can make a wipe consistent, but it still leaves you maintaining install media and handling device registration.

For new devices, check whether your supplier can register them to your organization’s Autopilot tenant before delivery. If that works for your purchasing process, you may be able to keep the OEM image and use Autopilot pre-provisioning instead of rebuilding every machine. I’d keep the USB process as a recovery option rather than making it the main route.

Your USB work sounds useful as a repeatable recovery and testing tool. Just be careful about making the install image responsible for every stage. Windows setup, drivers, device registration, and Intune app deployment each have different failure points, so logs and clear checkpoints will save time when one step breaks.

I’d also test the complete flow on a small set of models before calling it zero-touch. Firmware settings, storage drivers, network availability, and enrollment timing can vary by model or device. If a technician still has to sign in to upload a hardware hash, that is still a manual step worth targeting separately.

If you keep building the USB workflow, an OSDCloud-style approach with an answer file may be worth evaluating for Windows setup and driver handling. It can reduce the amount of work embedded in a custom task sequence, though it still needs testing and upkeep. I wouldn’t assume it removes the Autopilot registration step by itself.

The bottleneck may be getting devices into Autopilot, not installing Windows. Look into whether your organization can automate that registration through its purchasing channel or an approved enrollment workflow. I’d avoid creating a custom service or script that handles device identifiers until your security and endpoint teams have reviewed how it authenticates and protects that data.