Identity starts at the factory, not at the customer
Secure device provisioning is the process by which every unit receives a unique identity that cannot be forged or cloned, and it begins long before a customer opens the box -- it begins on the production line. A surprising number of projects arrive at pilot production with finished electronics, finished firmware, and a finished app, only to discover that nobody has answered the simplest question in the program: how does the factory give each unit its own credentials without ever handling the company's private keys?
Why identity is burned during assembly
In theory you could register a device the first time it connects from a customer's home and issue credentials then. In practice that model breaks quickly. If every unit leaves the factory carrying the same shared secret in firmware, one person extracting it from flash memory can manufacture thousands of counterfeit units that your server will welcome. Worse, you have no way to tell a genuine unit from a clone, which undermines warranty, subscription enforcement, and any security claim you have made to customers.
So the accepted approach is a per-unit identity created and installed during assembly. At the end-of-line test station each device receives a serial number, a private key, and a signed certificate, and is immediately registered in the authorized-device table in the cloud. Provisioning is therefore not a server-side operation but a chain that starts at a fixture in a factory and closes at the customer. Folding that station into a properly planned pilot production run is what makes it a process step instead of an emergency fix, and the station itself is normally specified during EVT, DVT, and PVT builds alongside functional test.
What exactly gets written to each unit
- A unique identifier that is not a predictable sequence, so nobody can guess the identifiers of other units.
- A private key generated inside the security element and never exported -- not even for backup.
- A digital certificate signed by your own certificate authority, letting the cloud verify that a device genuinely came off your line.
- Connection parameters: server endpoint, tenant identifier, and port, so the device knows where to report on first power-up.
- Firmware version and batch number, so a defect discovered in the field can be traced to the affected population instead of the whole installed base.
Two operational details matter as much as the list. First, the factory must never hold your root certificate authority key; the station should receive short-lived signing capability or pre-generated certificate batches from a system you control. Second, provisioning must be verified in the same test step, by having the unit complete a real authenticated connection before it is packed. A device that ships with a bad certificate is an expensive field return for a problem that costs seconds to catch.
Hardware-backed identity vs. keys in software
The difference between provisioning that holds up and provisioning that only looks good in a slide comes down to one question: where does the private key live? A dedicated secure element, or an integrated security subsystem inside the microcontroller, generates the key internally, performs cryptographic operations inside its own boundary, and never releases the secret. The added unit cost is typically a small number of dollars -- trivial against the cost of a cloned product line or a compromised fleet.
A software-only approach, where the key sits in flash, is defensible only when combined with hardware-enforced readout protection, secure boot and firmware encryption, and a threat model where physical attack is genuinely unlikely. Either way, this decision has to be made together with microcontroller selection, because retrofitting a security element after the board is in production means a new layout, new firmware, and new certification testing.
What happens at first power-up
When the device first comes online it opens an encrypted connection and presents its certificate. The server validates it against the certificate authority, confirms it is not on the revocation list, checks that the unit is in the authorized table and has not already been claimed, and only then permits communication. Most managed IoT services support exactly this flow, including just-in-time registration of certificates signed by your own authority -- the mechanics differ between providers, as compared in AWS IoT vs. Azure IoT.
The next step is claiming: associating the device with a specific user account, usually through the app using a printed code or QR label on the product. This is where provisioning meets onboarding, and where the network connection is established -- see Wi-Fi provisioning from an app. Design the claim flow so a device can be released and re-claimed, because resale, RMA replacement, and a customer changing accounts are all normal events, and a device permanently bound to its first owner becomes a support problem.
The lifecycle after provisioning
Identity is not a one-time event. Certificates expire, keys are rotated, and units are decommissioned. Plan for revoking a compromised device, rotating credentials over the product's service life, and re-provisioning a unit after a board repair. All of it depends on being able to update firmware in the field, which is why OTA firmware updates and provisioning are designed as one system. The visibility layer that makes this manageable at volume is the device management dashboard, where revocation, batch tracing, and credential status all have to be visible to whoever operates the fleet.
Plan provisioning before the first production run
Provisioning touches hardware selection, firmware, cloud configuration, factory tooling, and the app onboarding flow at once, which is why it falls through the gaps when those are handled by separate suppliers. Projects House designs the identity chain across all of them, from the security element on the board to the test station script to the cloud registry. Contact us through the form before your production run to review how your devices will get their identities.