Device Identity and Zero-Touch Provisioning at Fleet Scale

The fastest way to get a fleet talking to a backend is to flash the same credential into every unit. It works immediately, it requires no infrastructure, and it creates a problem that grows quietly with the fleet: the moment that credential is extracted from any one device, every device is compromised at once, and the only remedy is a firmware update to hardware that may be unreachable.

Per-device identity is the alternative, and the cost is almost entirely up front. Each unit gets its own key pair and certificate, ideally generated on the device so the private key never exists anywhere else, including on the manufacturing line. The backend then authenticates devices individually, which means a single compromised device can be revoked in isolation without touching the rest of the fleet. That property is the whole point, and it is worth more than it looks until the day it is needed, at which point it is worth more than everything else.

Generating keys on-device requires hardware that can do it and somewhere safe to keep the result. A secure element or a microcontroller with a trusted execution environment gives a private key that cannot be read out even with physical access to the board. Without one, the key lives in flash and an attacker with the device in hand will eventually retrieve it. This is a genuine cost per unit, and it is the point where the security conversation meets the bill of materials, which is where it should happen rather than after the design is frozen.

Zero-touch provisioning is what makes per-device identity survive contact with manufacturing. The device is born with a manufacturer-issued certificate, and on first boot it presents that certificate to a provisioning service, proves it is genuine, and receives its operational credentials and configuration. Nobody types anything, no operator handles a secret, and the factory never holds material that would compromise the fleet. The build process stays simple, which matters because a provisioning scheme that complicates the production line will be quietly worked around.

The part teams postpone is rotation, and postponing it is what turns a manageable problem into an incident. Certificates expire, and a fleet whose certificates all expire in the same week is a fleet that goes offline in the same week, several years after everyone who designed it has moved on. Renewal has to be automatic, it has to start well before expiry, and it has to be tested by actually running it rather than by reading the code. Staggering initial validity periods so expiry spreads across months instead of days costs nothing at provisioning time and prevents the entire failure mode.

Revocation deserves the same scrutiny. A revocation list only helps if something checks it, and checking it on every connection means the check becomes a dependency of the whole fleet's ability to connect. Short-lived credentials that simply stop working are often more robust than long-lived ones plus a revocation mechanism, because they fail closed by default and remove an availability risk rather than adding one. Whichever approach is chosen, the question worth answering before shipping is concrete: when a single device is known to be compromised at three in the morning, what exactly does the person on call do, and how long does it take to work.