IoT device provisioning and fleet identity: give every device a name it cannot fake

A fleet of connected devices with no real identity is an open door with a welcome mat. If every device connects with the same shared password, or with a serial number anyone can read off a label, then one compromised unit hands an attacker the keys to the whole fleet. The fix is not more firewall rules. It is giving every device an identity it cannot fake, provisioning that identity exactly once, and being able to take it away in minutes when a device is stolen, resold, or compromised.

Device identity is the foundation the rest of your IoT security stands on. Firmware updates are only trustworthy if the device asking for them is who it claims to be. Sensor data is only worth acting on if it came from the sensor you think it did. Get identity wrong and everything downstream is guesswork.

Identity is not a serial number

A serial number identifies a device the way a name tag identifies a person at a conference: anyone can print one. Real device identity has three properties. It is unique to one device, it is a secret the device can prove without revealing, and it can be revoked without touching any other device. That combination points to one practical answer: a unique cryptographic certificate per device, with the private key stored where it cannot be copied out.

On capable hardware that means a secure element or a trusted platform module holding the key. On constrained hardware it means at minimum a key burned into write-protected flash at manufacturing time, never shipped in firmware images, and never shared across units.

Certificates: the identity that travels with the device

Each device carries an X.509 certificate signed by your fleet certificate authority, and the cloud verifies that certificate on every connection, typically through mutual TLS. The device proves possession of the private key; the server checks the certificate chains to your CA and has not been revoked. No passwords cross the wire, nothing to brute-force, and a captured certificate alone is useless without the private key.

Keep the certificate lifecycle boring and short. Device certificates should expire, ideally within a year, so that rotation is a routine operation rather than an emergency. Short-lived certificates also bound the damage of a key that leaks quietly: the window in which it is useful closes on its own.

# First boot: the device claims its identity, then proves it
# 1. Device generates a keypair in secure storage (key never leaves)
# 2. Device sends a CSR + factory claim token to the provisioning service
# 3. Service verifies the claim token against the manufacturing batch
# 4. CA issues a certificate bound to device_id + hardware revision
# 5. Device stores the certificate; the claim token is burned
#
# Every connection after that: mTLS, certificate checked
# against the fleet CA and the revocation list, every time.

Provisioning: the moment of trust

Provisioning is the single moment when a device goes from an anonymous piece of hardware to a trusted fleet member, and it is the moment attackers most want to hijack. There are two honest ways to do it, and both need the same discipline.

Factory provisioning injects the certificate during manufacturing, over a controlled line, with the claim recorded against the batch. It is the most secure option, but it couples your production line to your PKI, and rework is painful if a certificate is issued wrong.

Field provisioning, often called just-in-time provisioning, lets a device claim its identity on first connection using a one-time claim token or a bootstrap certificate. It is far more flexible for contract manufacturing and field replacements, but the claim token becomes the crown jewel: it must be single-use, short-lived, and bound to a specific batch or device. A claim token that can provision unlimited devices is worse than no provisioning at all.

Whichever route you take, the provisioning service itself deserves the same rigor as any other sensitive system. When we design IoT and hardware products for clients, the provisioning flow is specified before the first board spins, because retrofitting identity onto a shipped fleet means either a truck roll or living with shared credentials. The same discipline applies to the pipeline that moves signed binaries around: control who can push and pull, and log every transfer.

Revocation: the half everyone forgets

Issuing identities is the fun half. Revoking them is the half that saves you. Devices get stolen, resold, decommissioned, and compromised, and your system needs a revocation path that works in minutes, not in the next firmware release.

That means a revocation list or an online status check enforced at connection time, a runbook for revoking a single device and an entire batch, and a way to revoke without bricking devices that merely lost connectivity for a week. This is the same instinct behind staged OTA rollouts with automatic halt conditions: design for the failure case, and make the safe state the default.

Revocation also has to reach the places identity is cached. If a gateway caches device credentials, or a dashboard session outlives the revocation, the kill switch has a hole in it. Map every place a device identity is trusted, and make sure revocation propagates to all of them.

The provisioning checklist

Run this before the first production batch ships:

• One certificate per device — never shared, never baked into a firmware image.
• Private keys in protected storage — secure element where possible, write-protected flash at minimum.
• Single-use, short-lived claim tokens — bound to a batch, burned after use, and rate-limited.
• Short certificate lifetimes — rotation is routine, not an emergency.
• Revocation enforced at connection time — with a runbook for single devices and whole batches.
• Identity survives updates — an OTA update must never wipe or duplicate a device identity.
• Every provisioning event logged — device, batch, time, and outcome, so anomalies are visible.
• Decommissioning is a real flow — a returned or scrapped device gets its identity revoked, not just powered off.

Identity makes everything else trustworthy

Once each device has a real identity, the rest of the system gets simpler. Telemetry can be attributed to a specific unit, so raw sensor samples become trustworthy product events instead of anonymous noise. Per-device acknowledgements can be made safe to retry without corrupting fleet state. And the device registry itself — the database that maps identities to customers, batches, and firmware versions — can evolve with schema changes that never take the fleet offline.

The same provenance thinking applies to everything you ship: a deployment pipeline should prove what it ships, and a fleet should prove which device it is talking to. Identity is not a feature you add to an IoT product. It is the precondition for trusting anything the product tells you.

A fleet that can prove who it is becomes an asset you can operate: patches land on the right devices, data is attributable, and a stolen unit is a revoked certificate instead of a breach. If you are planning a connected product and want identity, provisioning, and revocation designed before the first board spins, talk to us.