Zero-Touch Provisioning

The device is powered on, connects, proves who it is using a credential injected at manufacture, and receives its configuration from the platform based on the registry. The installer's involvement is limited to physical installation and, at most, a claiming step.

The reason this matters is not elegance. The installer will not perform a technical procedure correctly, and should not have to — provisioning designed around a competent technician fails at the scale where an electrician, a driver or a customer is doing the installation.

The two problems it separates

Identity — how the device proves what it is — and configuration — what it should do and where it belongs. These are frequently conflated and are cleanest when kept apart: identity is established at manufacture and is immutable; configuration is assigned at deployment and changes over the device's life.

Implementation patterns

• A unique credential 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 first connection can be recognised as genuine rather than merely well-formed.
• Never a credential shared across a production run. It is the common shortcut, it makes revocation impossible without a mass update, and a single extracted key compromises the entire run.
• A claiming step designed for a non-technical person — a scanned code, proximity pairing, a code entered in an app — binding the device to a customer or site.
• A safe inert default state before configuration arrives, so a device that cannot reach the platform does nothing rather than something wrong.
• Reprovisioning support, since devices are moved, resold and reassigned, and one permanently bound to its first owner becomes waste.

Industry example

Volume-manufactured connected products consistently find that provisioning succeeds easily in testing and fails in the field for reasons nobody instrumented. The question that determines whether the programme works is not how provisioning succeeds but what an installer does when it fails at a customer site with no diagnostic access.

That needs clear device-side indication, a support path requiring no technical skill, and — the piece most platforms omit — visibility of devices that attempted provisioning and did not complete. Without that signal, the platform sees successful enrolments and has no idea how many attempts failed, which means the failure rate is unknown and unimprovable.

Failure scenarios

• Shared production-run credentials, defeating revocation and identity entirely.
• Manual configuration steps, performed inconsistently and at scale incorrectly.
• No safe default, so an unconfigured device behaves unpredictably.
• No failed-attempt telemetry, hiding the actual failure rate.
• No reprovisioning path, stranding devices when ownership changes.

Trade-offs

Factory provisioning requires supply-chain trust and manufacturing process integration, which is a real organisational cost and a dependency on a partner. The alternative — a one-time bootstrap credential exchanged for a long-lived one on first connection — narrows the exposure window to first boot and is considerably easier to arrange.

Automation also removes a human check: a device claimed to the wrong site is provisioned wrongly with no one noticing. The compensating control is that the claiming step involves a person confirming the binding, which is the one place a human adds more value than automation.

Interview question

"A hundred thousand devices will be installed by electricians who have never seen your product. Walk me through how each one gets its identity and its configuration — and what happens when one of them does not."