How do certificates and PKI give an IoT device an identity?

Every security control in an IoT system eventually asks the same question: which device is this? Encryption is useless if the other end is an impostor, authorization is meaningless without a subject, and an audit log that says “a sensor reported this” is worthless if any sensor could have said it. Device identity is the foundation everything else stands on.

The mature answer is the same one the web uses: asymmetric keys and certificates managed by a public key infrastructure. The IoT version has its own wrinkles, because devices are made in factories by contractors, have no keyboard, may live for fifteen years, and number in the millions.

This guide explains what a device certificate is, how to get one onto a device without leaking the key, how servers and brokers use it, and how to keep the system working for the whole device lifecycle.

Why not passwords or shared secrets?

A password or API token is a secret both sides know. If a device’s token leaks, from a firmware dump, a log file, or a careless support ticket, an attacker can impersonate it until someone notices and rotates it. If the whole fleet shares one token, one leak compromises every unit.

A key pair separates the two sides. The private key is generated on the device and never leaves it. The public key, wrapped in a certificate, can be published freely. The server verifies a signature made with the private key; it never needs the key itself. A compromised server reveals nothing that lets anyone impersonate a device, and a compromised device compromises only itself.

What is inside a device certificate?

An X.509 certificate binds a public key to a name and is signed by an issuer. For a device, the subject name usually carries a serial number or a hardware identifier, the issuer is the manufacturer’s or operator’s certificate authority (CA), and the validity period can be long, often years, because rotating certificates on constrained devices is costly.

Elliptic-curve keys, typically on the P-256 curve, are the norm in IoT. They are small, fast to compute on a microcontroller, and supported by every secure element and TLS stack that matters. RSA keys work but are slower and larger on constrained hardware.

A certificate chain lets a server trust many devices by trusting one root. A common structure is a long-lived offline root CA, an intermediate CA per product line or factory, and leaf certificates per device. Compromise of a factory intermediate can be contained by revoking that intermediate rather than the whole root.

What are birth certificates and operational certificates?

A useful pattern, formalized in IEEE 802.1AR, separates two kinds of identity. The manufacturer installs an initial device identity (an IDevID, sometimes called a birth certificate) at production. It proves the device is a genuine product from that maker and never changes. When the device is deployed, the operator issues a locally significant identity (an LDevID, or operational certificate) that proves membership in that operator’s system and can be rotated or revoked as needed.

Matter uses exactly this structure: a device attestation certificate from the manufacturer, verified during commissioning, followed by an operational certificate issued by the home’s controller. Cloud platforms such as AWS IoT Core and Azure IoT Hub support similar flows.

How do keys get onto devices safely?

Provisioning is where most identity schemes break. The options, from weakest to strongest:

• Inject a pre-generated key and certificate during flashing. Simple, but the key exists outside the device, on a production PC or in a file sent to the contract manufacturer, and every copy is a liability.
• Generate the key on the device at first boot and send a certificate signing request (CSR) to a CA. The private key never leaves the device, but the first connection has to be authenticated somehow, usually with a one-time token or a pre-shared bootstrap credential, and that first-time flow needs protection against replay.
• Use a secure element or SoC with a pre-provisioned key and certificate from the chip vendor. The silicon maker generates the key in a secure facility and ships the chip with a certificate already signed by its CA. The product team only needs to trust that CA. This removes the factory from the trust equation entirely and is the strongest option for high-volume products.

Whichever route is chosen, the private key should live in hardware that will not hand it over: a secure element, a TPM, or the protected key storage of the SoC. A key in plain flash leaves with the first firmware dump.

How is identity used at runtime?

The device presents its certificate during the TLS or DTLS handshake, and the server does the same. This mutual authentication is what lets an MQTT broker map a connection to a known device before any message arrives. The broker’s authorization rules then reference the certificate’s subject: device 1234 may publish to devices/1234/telemetry and subscribe to devices/1234/commands, and nothing else.

The same key can sign data at the application layer, which matters when messages pass through intermediaries. A gateway that forwards readings cannot forge them if each one is signed by the originating device, which gives end-to-end encryption and integrity through untrusted hops.

Attestation extends identity from “who is this” to “what is it running.” A device with a measured boot chain can sign a report of its firmware hashes with a key tied to its root of trust, and a backend can refuse service to devices running unknown or outdated code.

How are certificates rotated, revoked and retired?

Certificates expire, and that is a feature: an expired credential forces a check-in. Rotation should be automated through the device management channel, with a new CSR issued well before expiry. Devices that miss the window need a recovery path, usually falling back to the manufacturer identity to re-enroll.

Revocation is harder in IoT than on the web. Certificate revocation lists grow large, and OCSP checks are expensive on a constrained link. Most platforms instead handle revocation in the device registry: a revoked device is simply disabled there, and the broker rejects its connection regardless of certificate validity. That works only if every service checks the registry.

At retirement, the device’s operational certificate is revoked, its registry entry is marked decommissioned, and ideally the device itself is told to wipe its keys, so a resold unit cannot reconnect.

When is a full PKI overkill?

A hobby project with a handful of devices behind a home router can live with pre-shared keys. A product that ships to customers cannot, because the cost of an impersonation incident outweighs the engineering of a proper identity scheme. The practical middle ground for small teams is to use the certificate services built into a cloud IoT platform, which handle the CA, rotation and registry integration, and to put the private key in a secure element from day one.

Where to go next

• IoT security fundamentals sets the broader threat picture that identity is part of.
• Device management and over-the-air updates explains the channel through which certificates get rotated and firmware signed.
• MQTT explained shows how broker authorization uses certificate identity in practice.

Topics: device identity, PKI, X.509, certificates, secure element, provisioning