Provisioning: how a device gets its identity at the factory or on site

The first prototype often has one set of Wi-Fi and broker credentials typed into the source code. That works for ten boards. It fails the day a unit is returned or you need to switch off one device without touching the others. Provisioning is how each unit gets its own identity, and it is much easier to design before the first production run than after.

Identity first, ownership second

Two separate questions get mixed up. Who is this device, and who owns it? Identity is set once, at manufacture: a unique device ID and a credential that only that unit holds. Ownership is set later, when the customer takes the product and ties it to their account. Keep them separate, so a unit can be built before it is sold and reassigned after a return.

Serial numbers and device IDs

Use a serial number that is unique and not guessable from the previous one if the ID is also used for access. Print it, with a QR code, on the label and store the same value in the device. Record batch, board revision and firmware version against each serial at the test station.

Per-device credentials

Shared secrets are the weak point. The options, roughly in order of strength:

• A unique X.509 client certificate per device, issued by your own certificate authority and used for mutual TLS to the broker.
• A unique token or password per device, stored in flash with read protection.
• A secure element such as an ATECC608 or similar, where the private key is generated inside the chip and never leaves it.

On ESP32 and STM32, flash encryption and read-out protection stop credentials being copied off the board, but they must be turned on in production, and some settings are one-time and cannot be undone. Test them on sample boards first.

Where credentials are made

You can inject credentials at the factory test station, over the programming port, as part of the same step that flashes firmware and runs the functional test. Or the device can generate its own private key and send a certificate signing request, so nobody else ever sees the private key. The second is safer, and needs a trusted way to approve the request.

Claiming to a customer

Claiming links a verified device to an account. A short claim code or QR on the label, plus a physical action such as pressing a button or being on the same network, proves the person holds the device. The cloud checks that the device is unclaimed, then binds it. Build the reverse too: a way to release a device when it is resold, and to revoke its certificate when it is lost or returned.

What this does not fix

Per-device credentials do not protect a device that can be opened and read. Plan for certificate expiry and rotation, because a fleet where certificates expire silently goes offline all at once. Rules on device security can change, so check current requirements for your market.

---

If you are planning how units get identity and ownership, book a discovery call, and see our cloud, apps and dashboards and production support work.