diagrams
IoT

IoT Device Authentication

IoT device authentication is the process by which a physical device proves its identity to a cloud platform or gateway before being permitted to publish sensor data, receive commands, or download firmware — typically using X.509 certificates and mutual TLS rather than username/password credentials.

diagram.mmd — sequence
Edit in Graphlet →
IoT Device Authentication sequence diagram
About Source

IoT device authentication is the process by which a physical device proves its identity to a cloud platform or gateway before being permitted to publish sensor data, receive commands, or download firmware — typically using X.509 certificates and mutual TLS rather than username/password credentials.

Unlike web applications where a user can be prompted to re-authenticate, IoT devices must authenticate autonomously and continuously. This makes cryptographic identity — where the device holds a private key burned into secure storage during manufacturing — the standard approach.

Provisioning happens at the factory or during initial onboarding: a Certificate Authority (CA) operated by the device manufacturer or the cloud platform issues a unique X.509 certificate for each device. The certificate contains the device's serial number as a Common Name and is signed by the CA's private key. The device certificate and the CA's public certificate chain are flashed into the device's secure element or trusted platform module (TPM).

At runtime, the device initiates a mutual TLS (mTLS) handshake with the IoT platform endpoint. During the TLS ClientHello and subsequent handshake, both parties present certificates. The platform verifies the device certificate against the registered CA chain. The device verifies the platform's server certificate against a pinned root CA. If either verification fails, the connection is rejected.

Once the TLS session is established, the cloud platform performs a second-layer policy check: is this specific device ID authorised to connect? Is it suspended, decommissioned, or quarantined? Only if the policy evaluation returns allow does the device receive a session token or MQTT connection acknowledgement and begin publishing data. The sequence diagram captures the full exchange — from initial TCP connect through certificate validation to first data publish. For command delivery over an established session, see IoT Command Control Flow. For the firmware update flow that depends on this authenticated channel, see IoT Firmware Update Flow.

Free online editor
Edit this diagram in Graphlet
Fork, modify, and export to SVG or PNG. No sign-up required.
Open in Graphlet →

Frequently asked questions

IoT device authentication is the process by which a physical device proves its identity to a cloud platform or gateway before being allowed to publish data, receive commands, or download firmware. Unlike user authentication, it must operate autonomously without prompting a human, making cryptographic credentials the standard approach.
During manufacturing or initial provisioning, a Certificate Authority issues a unique X.509 certificate for each device, which is stored in secure hardware. At runtime the device initiates a mutual TLS handshake, presenting its certificate to the cloud platform. The platform verifies the certificate chain, the device verifies the server certificate, and a policy engine checks whether the specific device ID is currently authorised before granting a connection.
Use X.509 mutual TLS for any production deployment where device identity must be individually revocable, where devices operate on untrusted networks, or where regulatory requirements mandate strong cryptographic authentication. Pre-shared keys are acceptable in small closed deployments but do not scale to large fleets because rotating a compromised key requires updating every device that shares it.
Common mistakes include burning the same key or certificate into every device in a batch, making it impossible to revoke a single compromised device without affecting the entire fleet. Other issues are neglecting certificate expiry management, failing to pin the server certificate so a device will accept a fraudulent broker, and storing credentials in writable flash rather than a secure element where they can be extracted.
Certificate-based mutual TLS authenticates the device at the transport layer using asymmetric cryptography; the private key never leaves the device and there is no shared secret to steal. Token-based authentication issues a short-lived bearer token after an initial credential exchange; it is easier to implement but requires a secure credential store and a token refresh mechanism, and a leaked token grants access until it expires.
mermaid
sequenceDiagram participant Device as IoT Device participant CA as Certificate Authority participant Platform as IoT Platform participant Policy as Policy Engine note">Note over Device,CA: Factory provisioning (one-time) CA->>Device: Issue X.509 device certificate Device->>Device: Store cert in secure element / TPM note">Note over Device,Platform: Runtime connection Device->>Platform: TCP connect to MQTT/HTTPS endpoint Platform->>Device: TLS ServerHello + server certificate Device->>Device: Verify server cert against pinned root CA Device->>Platform: TLS ClientCertificate (device cert) Platform->>Platform: Verify device cert against registered CA chain alt Certificate invalid or expired Platform->>Device: TLS Alert — certificate_unknown Device->>Device: Log auth failure, retry with backoff else Certificate valid Platform->>Policy: Check device policy\n(device ID, status, permissions) Policy->>Platform: ALLOW / DENY alt Policy DENY Platform->>Device: CONNACK — Connection refused else Policy ALLOW Platform->>Device: TLS handshake complete Platform->>Device: MQTT CONNACK — Connection accepted Device->>Platform: Publish sensor data end end
Copied to clipboard