A fleet of connected devices needs credentials. What does secure provisioning require, and what is the failure that ends the programme?

What it requires

• A unique credential per device, provisioned during manufacture into hardware-backed storage where the private key never leaves the device.
• Rotatable and revocable remotely, since a device's lifetime is years and a credential's should not be.
• Bound to the device's identity, so a credential extracted from one device is not usable from another — which requires hardware attestation to be meaningful.
• Provisioned in a manufacturing environment that is itself controlled, since the provisioning system is now the highest-value target in the supply chain.
• A revocation path that reaches devices quickly, and a server-side check that a revoked device's credential is rejected regardless of what it presents.

The failure that ends the programme

A shared secret across the fleet. It is simpler to provision, it works, and one extracted key compromises every device — with no way to revoke without disabling everything.

Extraction is not hypothetical: a physical device in a customer's possession is available for analysis, and any secret in flash storage will eventually be read.

The related failures

• A credential that cannot be rotated, so a suspected compromise has no remedy short of physical recall.
• Attestation not verified server-side, making the hardware backing decorative.
• Provisioning records not retained, so a device's identity cannot be traced to its manufacture — which matters for both security investigation and warranty.
• The provisioning system reachable from the corporate network, making it a target reachable by an ordinary compromise.

The operational requirement that follows

Per-device revocation must be usable at scale. A fleet with a compromise affecting a batch needs to revoke that batch and re-provision, which requires knowing which devices were in it — a manufacturing data problem that is solved before it is needed or not at all.

The architectural framing

The device is untrusted. Whatever it presents may have been extracted or forged, so the server authorises based on cryptographic identity and its own record of what that device may do — never on what the device claims about itself.

That framing produces the right decisions automatically, and it is the difference between a fleet where a compromised device is contained and one where it is a foothold.