What this is. Opinion + Experience + Fact (15% opinion · 25% experience · 60% fact). Written in collaboration with AI — I discuss, I do not outsource.

The best onboarding has no setup screen: power the device, and moments later it is on the right tenant, trusted, configured. That "magic" is the most misunderstood few minutes in IoT. It is not magic — it is identity, arranged at the factory long before the customer opened the box. Here is how zero-touch onboarding actually works.

Every connected product has a first five minutes: the moment a factory-fresh device meets the real world and has to find its cloud, prove who it is, and start working. Most of what is written about IoT covers the years that follow — telemetry, updates, fleets. Very little covers the birth.

Which is a pity, because the birth is where the most elegant trick in connected-product engineering lives. A device that joins your cloud untouched — no serial cable, no setup app, no credentials typed by a human — looks like magic to the person unboxing it. It is not magic. It is a chain of decisions made months earlier, at design time and on the factory line. Let me walk through it.

1. Onboarding is an identity problem, not a setup screen

The first version of onboarding on almost every product is manual, and rightly so: a serial cable, Wi-Fi credentials typed in, a certificate copied over by hand. At a handful of devices this is the fastest honest path, and it teaches you what the device actually needs before it can do its job.

It also quietly answers the real question for you — because a human is standing there, vouching for the device. Remove the human, and the question stands exposed: how does your cloud know this device is yours? Not "how does it get online" — how does it prove who it is, with nobody vouching for it?

That is the reframe that unlocks the whole design. Onboarding is not a connectivity feature with a security step bolted on. It is an identity problem, and connectivity is just the transport underneath it.

▸ First principle. Trust must be pre-arranged, not improvised in the field.

2. The passport model: identity is born on the factory line

Zero-touch onboarding works like a passport, not a visa interview. A passport is issued by an authority before you travel; when you arrive at a border, the officer does not trust your story — they trust the issuer, verify the document is genuine, and check that it belongs to you.

The device version uses an X.509 certificate chain, and it is the same three-part arrangement:

The identity is created at manufacture. On the production line, a secure element — an ATECC608-class chip is the common example — generates the device's private key inside the chip. The key never leaves the silicon; it is not in your firmware image, not in a config file, not on a laptop in the factory. Provisioning of these chips happens in secured facilities using hardware security modules, so even the manufacturer's own line never sees the secret.

The passport is signed by an authority. The device receives a certificate — its public identity — signed by a certificate authority (CA). Certificates chain upward: the device's leaf certificate is signed by an intermediate, which chains to a root CA. That chain is the passport's security paper and hologram.

The border already trusts the issuer. Your cloud is told, ahead of time, which CA to trust. From that point, any device carrying a certificate that chains to that CA can be verified — including devices that have never connected before. The customer opens the box; the trust was arranged back at the factory.

▸ First principle. A device earns trust by what it carries, not where it connects from.

3. The first power-on: four steps, no hands

Here is what actually happens in the device's first minutes, in the flow that platforms like Azure Device Provisioning Service (DPS) and AWS IoT fleet provisioning are built on:

The zero-touch first power-on: discover, prove, claim, configure A factory-fresh device flows through four steps with no human touch: discover the provisioning endpoint, prove identity with its certificate and a proof-of-possession challenge, get claimed and mapped to the right tenant, then pull configuration and start working. Below, a band notes the trust was arranged at the factory: key born in the secure element, certificate signed by a CA the cloud already trusts. First power-on: four steps, no hands. 1 · DISCOVER Find the provisioning endpoint. Nothing customer-specific is hardcoded. → 2 · PROVE Present the certificate; answer the proof-of- possession challenge with the private key. → 3 · CLAIM The service maps this identity to the right tenant and hands the device its home. → 4 · CONFIGURE Pull settings. Start working. No human in the loop. The trust was arranged at the factory: key born inside the secure element · certificate signed by a CA the cloud already trusts Simplified flow — the shape Azure DPS and AWS IoT fleet provisioning are built on.
The zero-touch first power-on. Simplified, but the shape is exact: discover → prove → claim → configure.

Discover. The device wakes and reaches a provisioning endpoint. Crucially, nothing customer-specific is hardcoded in the firmware — no connection strings, no tenant URLs. The same firmware image can ship to every customer.

Prove. The device presents its certificate and is challenged to prove it holds the matching private key — a proof-of-possession challenge, answered by the secure element. This is the passport plus the photo check: the document is genuine, and it belongs to the bearer.

Claim. The provisioning service looks up which enrollment this identity belongs to, maps the device to the right tenant or hub, and hands it its long-term home.

Configure. The device pulls its configuration and goes to work. From the customer's side: they plugged it in.

▸ First principle. Every human touch you remove is a support ticket that never happens.

4. What you have to decide early

Everything above depends on decisions that are cheap at design time and painful afterwards. Where does the identity live — a secure element, or a software keystore you will want to upgrade later? How does the device discover its endpoint without hardcoding a customer? What happens on the line — who signs the certificates, and how does the factory flow inject identity at production speed? And can the identity be renewed, because certificates expire and roots rotate?

None of this requires inventing anything. The mechanism is industry standard; what it requires is deciding early that the device will carry its own identity from birth. Retrofit it after devices have shipped, and you are re-flashing hardware in the field to give it papers it should have been born with.

(The device-side hooks for this — identity, provisioning, configuration — are part of EmbedIQ, the open-source device foundation. But the mechanism described here is standard, whatever foundation you build on.)

▸ First principle. Identity is a birth attribute, not a field upgrade.

The unboxing feels like magic precisely because all the work happened earlier. A passport is boring at the border — that is the whole point of a passport. Design the identity in at the start, arrange it on the line, and the first five minutes of every device you ever ship become a non-event: power on, prove, join, work.

Sources

The provisioning flow, X.509 chain-of-trust and proof-of-possession mechanism are as documented in Microsoft Learn — Azure DPS X.509 certificate attestation. Factory key generation inside the secure element (key never leaves the chip; HSM-based provisioning in secured facilities) is as documented by AWS & Microchip — Trust Platform for AWS IoT and the Microchip ATECC608B-TNGTLS datasheet. The four-step flow diagram is a simplified illustration of this documented shape. No fleet sizes or timings are claimed.

FAQ

What is zero-touch onboarding in IoT?
Zero-touch onboarding (also called zero-touch provisioning) is the process by which a factory-fresh device connects to the correct cloud, proves its identity, and receives its configuration with no human intervention — no setup screen, no typed credentials, no manual certificate installation. It works because the device's identity was created and signed at manufacture, and the cloud was told in advance which certificate authority to trust.

How does a device prove its identity without a human?
Through an X.509 certificate chain and a proof-of-possession challenge. The device carries a certificate signed by a certificate authority the cloud already trusts, and proves it holds the matching private key by answering a cryptographic challenge. The cloud verifies the issuer and the possession — like a border check verifying both the passport and that it belongs to the bearer.

Why use a secure element for device identity?
A secure element generates the private key inside the chip, and the key never leaves the silicon — it is not in firmware, not in a file, and not visible to the factory. That means the secret cannot leak through the manufacturing chain, and the device's identity cannot be cloned by copying its flash.

When does zero-touch provisioning have to be designed in?
At design time, before production. It requires a hardware decision (where the identity lives), a firmware decision (endpoint discovery with nothing customer-specific hardcoded), and a factory decision (how certificates are signed and injected on the line). Retrofitting identity onto devices already in the field means re-flashing hardware by hand — the exact manual work zero-touch exists to remove.

Do Azure and AWS support zero-touch onboarding?
Yes. Azure IoT Hub Device Provisioning Service (DPS) and AWS IoT fleet provisioning both implement the discover-prove-claim-configure flow using X.509 attestation, and both support enrollment of devices that have never connected before, based on a pre-registered certificate authority.

The short version of this is on my LinkedIn. The device-side foundation is open source — it's called EmbedIQ — and the architecture, the code, and the links live on my profile.