Design provisioning for devices manufactured in volume and deployed by non-technical installers.

The two problems

Identity — how the device proves what it is — and configuration — how it learns what it should do and where it belongs. They are separable and are frequently conflated.

Identity at manufacture

• A unique credential per device, injected at manufacture, with the private key generated on the device and never leaving it.
• A manifest of manufactured identities delivered to the platform, so a device connecting for the first time can be recognised as genuine rather than merely well-formed.
• Never a shared credential across a production run. It is the common shortcut, it makes revocation impossible without a mass update, and one extracted key compromises the entire run.

Configuration at installation

• Zero-touch where possible: the device connects, identifies itself, and receives its configuration based on the registry — because the installer will not perform a technical procedure correctly and should not have to.
• A claiming step binding the device to a customer or site, designed for a non-technical person: a scanned code, a proximity pairing, or a code entered in an app.
• A safe default state before configuration arrives, so a device that cannot reach the platform is inert rather than misbehaving.
• Reprovisioning support, since devices are moved, resold and reassigned — and a device permanently bound to its first owner becomes waste.

What determines whether it works at scale

The failure path. Provisioning succeeds easily in a test; the question is what an installer does when it fails at a customer site with no diagnostic access. That needs clear device-side indication, a support path that does not require technical skill, and platform-side visibility of devices that attempted provisioning and did not complete — which is the signal most platforms do not collect and most need.