Published: September 20, 2026 | Category: Technical Guide | QSCompute
A development kit arrives, you flash an image over USB, and your first inference runs. Then a customer orders 500 of the same device, and the process that worked on your bench collapses completely. Zero-touch provisioning is the discipline of imaging, identifying and enrolling an edge AI fleet without a technician plugging into any of it: a network boot path, a signed image, a per-unit identity, and an update mechanism you still trust in year five. This guide walks the provisioning chain end to end and the hardware decisions that determine whether it is even possible.
Hand-finishing devices is viable to roughly a dozen units. Beyond that, three things break at once: labour, consistency, and the audit trail. A field engineer with a USB stick cannot prove what firmware hash was written, cannot redo it remotely, and cannot avoid cloning the same credentials into every unit. The alternatives are narrower than most BOMs assume.
| Approach | Labour per unit | What it cannot do |
|---|---|---|
| Manual flash + hand configuration | 30–90 min, plus travel | Requires physical access at the customer site; no auditable record of the written hash |
| Golden-image clone (dd, balenaEtcher) | 5–15 min, mostly waiting | Copies the same keys and host identity into every unit; no per-unit attestation |
| Network (zero-touch) provisioning | ~0 min after racking | Needs a boot service, DHCP options and a signing chain in place before the first unit ships |
The economics are not close. One technician can rack a pallet, connect power and network, and walk away; the fleet service does the rest. The same engineer hand-flashing 500 devices at 45 minutes each is 375 hours — nine weeks of work that also produces 500 identical devices holding the same secret.
Forget the PXE folklore built up around legacy x86. A modern ARM or x86 edge board boots from the network through UEFI HTTP Boot (UEFI specification 2.5 and later), which fetches the boot image over HTTPS — the same port 443 your firewall and proxy already permit. TFTP survives only because it is baked into old firmware; it has no authentication, no retry semantics worth trusting and no business moving a multi-gigabyte image across a plant network. Point DHCP option 66/67 or a boot-menu entry at an HTTP endpoint, serve a signed image, and let the board verify before it executes anything.
Two practical rules follow. First, keep the provisioning server inside the deployment VLAN so the image transfer happens at line rate rather than over a WAN. Second, ship production units with the network boot path documented and a supported way to disable it — an open boot service on a device already in service is an attack surface, not a convenience.
A cloned image is a security liability because every unit shares whatever secret the image contains. Real provisioning creates identity at first boot, rooted in silicon that cannot be copied off the die.
| Step | Mechanism | What it produces |
|---|---|---|
| Boot integrity | PK/KEK/db keys burned into OTP fuses at manufacture | Measured boot: an unsigned image refuses to start |
| Unique seed | TPM 2.0 endorsement key plus a per-unit SRK, or an SE device certificate | A key that cannot be lifted from the board |
| Network identity | 802.1X certificate or a claim code exchanged at first contact | Device-specific credentials; no shared fleet password |
| Storage encryption | dm-crypt/LUKS or TCG Opal key sealed to PCR 0–7 | An image that is useless off-device even if the NVMe is pulled |
| Registration | Device posts certificate + hardware fingerprint to the fleet service | An inventory record tying firmware hash to serial number |
If the BOM lists a TPM as "optional," this step is where the project discovers it cannot be deferred. NIST SP 800-193 frames it as platform resiliency: the firmware must be able to detect and recover from a corrupted firmware image, which requires a recovery slot and a rooted key, not just an update script.
Automated provisioning without automated rollback is a fleet-wide outage waiting for a bad build. The update framework is therefore part of the provisioning design, not a later decision.
| Framework | Slot model | Best fit | Detail that bites |
|---|---|---|---|
| RAUC | A/B, or single + recovery | Yocto / vendor BSP trees | Needs a per-machine bundle signing key and explicit bootloader hooks |
| SWUpdate | A/B, single, or rescue | Mixed embedded Linux BSPs | Handlers decide whether you get atomicity or an in-place edit |
| OSTree | Deployments + rollback | Container-led OS factories | Requires a deliberate writable /var design |
| Android A/B | Dual slot + dm-verity | Android / GKI edge targets | Painful on small eMMC: two full system copies |
| UEFI capsule | Firmware only | x86 firmware field update | Does not cover the operating system at all |
Size the second slot against a twenty-year growth assumption rather than today's image. Fleets that shave the recovery slot to save eMMC cost reliably hit the wall when the application, its runtime and its model artefacts grow past the partition three years in.
Provisioning belongs in the factory wherever possible, because the customer's network is not yours to control. When a device must be imaged on site, do the arithmetic first: a 16 GB image takes about 2.5 minutes at 1 GbE line rate, roughly 21 minutes over 100 Mb, and around 107 minutes over a 20 Mb cellular link. Per-unit provisioning over WAN is a non-starter; a local cache that holds the image once and serves it to the whole rack is the only version that fits a maintenance window.
Provisioning a pilot fleet this quarter?
Tell us your unit count, target SoC and site network constraints — our engineers return a provisioning-ready BOM with secure boot, TPM enrolment and the imaging path specified end to end.
Contact: +86 137-1464-6179 | info@qscompute.com