A shared secret baked into firmware works fine for ten devices on a bench. It's also the single most common reason a connected-product fleet has to be re-provisioned in the field after launch.
Device identity is one of those problems that's easy to defer, because the shortcut works right up until it doesn't. A single shared API key or pre-shared secret compiled into every unit's firmware is the fastest way to get a prototype fleet talking to the cloud, and it's also a design decision that becomes exponentially more expensive to unwind the more units ship with it. Getting device identity right from the start — before the first production run, not after — is one of the highest-leverage security decisions in a connected product's architecture.
A secret shared across every device in a fleet has one structural problem: extracting it from a single unit compromises every other unit that shares it. That's not a hypothetical — physical device teardown and firmware extraction are well-understood, well-documented techniques, and a connected product that ships at any meaningful volume should assume at least one unit will end up in the hands of someone motivated to try. Per-device identity — where each unit has its own unique credential, distinct from every other unit's — means a single compromised device is a contained incident rather than a fleet-wide one. The cost difference between building this in from the start and retrofitting it after a security incident isn't close.
The common, well-established pattern is giving each device its own X.509 certificate and private key, used for mutual TLS authentication when the device connects to its backend — the device proves its identity to the cloud, and the cloud proves its identity to the device, both cryptographically, without a shared secret either side. The private key ideally lives in a hardware-backed secure element rather than plain flash, so that even physical access to the device doesn't trivially yield the key material. This is the same secure-boot-and-key-storage discipline covered in our note on firmware security and secure boot, applied specifically to the device's network identity rather than its firmware integrity.
Generating and installing a unique certificate per device has to happen somewhere in the production process, and where it happens shapes the whole system's security. Provisioning at the contract manufacturer's line — injecting a unique key and certificate during final test — keeps device secrets out of any single shared build image, but requires a secure key-generation and injection process at the CM itself, with real controls over who can access that process and what's logged. An alternative pattern has the device generate its own key pair on first boot and request a certificate from a backend provisioning service, which avoids ever having the private key exist outside the device — at the cost of needing a secure, authenticated first-connection flow. Which pattern fits depends on the CM relationship and production volume; see our note on choosing a contract manufacturer for the broader set of questions that relationship needs to answer.
Issuing a certificate once and never revisiting it isn't a complete identity system — a device that's returned, decommissioned, or confirmed compromised needs a way to have its credentials revoked so it can no longer authenticate, and certificates approaching expiry need a rotation path that doesn't require a truck roll. Designing the certificate lifecycle — issuance, rotation, revocation — as part of the platform from day one avoids a much harder retrofit later, when a fleet is already in the field and the rotation mechanism itself has to be delivered as a firmware update to devices that may not all be reachable at once.
Device identity is cheapest to get right before the first production certificate is ever issued, and expensive to fix once a shared-secret fleet is already in the field. See our cloud & device platform work and firmware work for how we design provisioning and identity together across the device and backend.
Related reading: device identity is the authentication layer underneath the connectivity choices covered in our note on BLE, Wi-Fi, LoRaWAN, and cellular tradeoffs, and the same per-device credential discipline applies directly to scaling a device fleet without a security bottleneck.
