Before an IoT fleet does anything useful, every device in it has to answer one question to the backend’s satisfaction: are you who you say you are? Get this wrong and the consequences are not abstract. A compromised device can inject false telemetry, drain a fleet’s command channel, or be used as a foothold into the rest of the platform. Get it right, and authentication becomes invisible infrastructure that nobody thinks about again. The decision that determines which of those two outcomes you get is usually made in the first few weeks of a project, often by default rather than by design.
There are three broad mechanisms in practical use: X.509 certificates, bearer tokens, and pre-shared keys. Each solves the same problem with a different set of trade-offs around hardware cost, provisioning effort, and what happens on day one when a device is lost, stolen, or cloned.
What each mechanism actually does
Certificates (mutual TLS)
Each device holds a private key and an X.509 certificate signed by a certificate authority you control. When it connects, the device and server present certificates to each other and verify the signature chain before any application data moves. Because the private key never leaves the device, a network eavesdropper gains nothing from watching the handshake. Revoking one device means revoking its certificate, not touching anyone else’s. The cost is operational: you need a certificate authority, a provisioning step that injects a unique identity into every unit before or during manufacture, and a plan for what happens when certificates expire on devices that might be in a basement with no signal for months at a time.
Tokens (OAuth2 / JWT)
A device authenticates once, using some initial credential, and receives a short-lived token that it presents on subsequent requests. The token carries scoped claims — this device can publish telemetry for this asset, nothing else — and expires on its own, which limits the damage window if one leaks. This model fits devices with an internet connection to spare and a backend built around standard web authentication, since the same identity provider can often serve mobile apps, dashboards, and devices at once. It fits less well when a device is offline for long stretches, because a lapsed token means an awkward re-authentication step, and the initial credential used to obtain the first token still needs to be provisioned and protected somehow.
Pre-shared keys
Device and server hold the same secret key, agreed in advance, and use it to authenticate and encrypt the session (TLS-PSK is the common form). No certificate authority, no asymmetric cryptography overhead, minimal flash and RAM footprint — which is why PSK still turns up on constrained microcontrollers where certificate handling is genuinely too heavy. The trade-off is blunt: if the key is extracted from one device through a hardware attack, and that key is shared across a batch or the whole fleet, every unit with that key is compromised at once. Used properly, each device gets its own unique key, which removes the blast-radius problem but reintroduces most of the provisioning burden that certificates carry, without gaining certificates’ revocation and rotation tooling in return.
The questions that actually decide it
The right choice depends on constraints specific to the fleet, not on which mechanism sounds most secure in the abstract.
- What can the hardware afford? A device built around a low-cost microcontroller with limited RAM may struggle with the TLS handshake overhead certificates require. Confirm this with the actual chip and stack you are shipping, not a generic spec sheet, before ruling certificates out.
- How is each unit provisioned? Injecting a unique certificate or key at the factory is straightforward if you control manufacturing. It is a different problem if devices are provisioned in the field by an installer or the end customer, which usually pushes teams towards a bootstrap step — a short-lived onboarding token exchanged for a longer-term credential once the device proves itself.
- What does revocation need to look like? If a device is stolen or a customer cancels, can you cut off exactly that unit without affecting the rest of the fleet, and without a manual key-rotation exercise across every other device?
- How often is the device offline? A key or certificate that lives on the device works fine through long offline periods. A token that expires while a device is out of coverage needs a defined re-authentication path that does not require a person to intervene.
- What does the backend already support? If the platform side is a standard cloud IoT service (AWS IoT Core, Azure IoT Hub, or similar), it will have a default, well-tested path — usually certificates — and deviating from it means maintaining your own tooling instead of using theirs.
Where fleets get into trouble
Most of the incidents that come up in this area trace back to a handful of shortcuts taken under deadline pressure rather than to a flaw in the mechanism itself.
- One key or certificate baked into firmware for the whole product line. It is faster to ship and it means every device in the field shares a single point of failure. Extract the credential from one unit, physically or through a firmware dump, and you have credentials for the entire fleet.
- No revocation path was built, because early on it never seemed necessary. Retrofitting per-device revocation onto a fleet that shipped with shared credentials usually means a recall or a mass re-provisioning exercise, neither of which is cheap once units are already installed.
- Credentials stored in plaintext flash rather than behind whatever secure element or protected storage the chosen silicon actually offers. If the hardware has a secure enclave, using it is usually a firmware decision, not an extra component.
- The bootstrap step is left weaker than the steady-state authentication it leads to. A device is often at its most exposed during first onboarding, when it is proving its identity for the first time — that step deserves the same scrutiny as the long-term mechanism, not less.
A decision checklist
Before committing to a mechanism, it is worth being able to answer each of these for the specific fleet in question:
- Does every device get a unique credential, or is any secret shared across more than one unit?
- Can a single compromised device be revoked without touching the rest of the fleet?
- Is the provisioning step — factory, installer, or self-service — actually defined, or assumed?
- Does the chosen mechanism fit the hardware’s real compute and memory budget, tested on the actual target, not a development board?
- What happens automatically when a device has been offline through a token or certificate expiry window?
- Does the backend platform have a native, supported path for this mechanism, or will your team be maintaining custom tooling indefinitely?
None of these questions have a universally correct answer. A fleet of cellular-connected industrial sensors provisioned at the factory has a very different optimum from a consumer device onboarded by the end user over WiFi. What matters is that the choice gets made deliberately, against the fleet’s actual constraints, rather than inherited from whichever tutorial the firmware team followed first.