X.509 Certificates for IoT: Zero-Trust Device Authentication

📅 December 2025 ⏳ 3 min read FSS Engineering Team

X.509 Cert✓ validIoT Hub✓ mTLS

X.509 certificate hierarchy: offline root CA — factory intermediate CA — unique device certificate per unit

Symmetric keys shared across a device fleet mean one compromised device exposes all devices. X.509 certificates give every device a unique cryptographic identity — compromise one, affect one.

Certificate Hierarchy Design

// Three-tier CA hierarchy

Root CA (self-signed, offline air-gapped hardware)
  └── Manufacturing CA (online HSM, signs device certs)
       └── Device Certificate (unique per serial number)
            Key: ECC P-256 (smaller and faster than RSA-2048)

Azure IoT Hub DPS Integration

// DPS group enrollment setup

az iot dps enrollment-group create   --dps-name fss-dps   --enrollment-id fss-devices   --certificate-path manufacturing-ca.crt   --iot-hubs fss-production-hub.azure-devices.net

🔄 Certificate rotation

Plan for certificate expiry at design time. 2-year device certs are common — design the OTA system to push new device certs before expiry. An expired certificate means a bricked IoT device. We have seen it in production from vendors who did not plan ahead.

Factory Provisioning Process

The security of your entire device fleet depends on the integrity of the factory provisioning process. The Manufacturing CA private key must never leave the HSM. The programming station that flashes device certificates must be on an isolated network segment with no internet access. Every certificate issuance must be logged with the device serial number, certificate thumbprint, and timestamp — this log is your audit trail for the entire device fleet’s security posture.

For high-volume manufacturing (1,000+ units per day), automated provisioning integrated into the functional test station is the practical approach: the test jig communicates with the HSM signing service over a secure internal API, generates a CSR from the ATECC608B secure element, receives the signed certificate, and writes it to device NVS — all in under 5 seconds per device. The device never holds an unprotected private key at any point in the process.

Certificate Revocation

X.509 certificates can be revoked if a device is compromised, reported stolen, or decommissioned. Azure IoT Hub maintains a device registry where individual devices can be disabled — preventing connection even with a valid certificate. For fleet-level revocation (if a batch of devices from a specific factory run is suspected compromised), IoT Hub configuration can target devices by tag and disable them en masse.

Certificate revocation lists (CRLs) are the standard PKI mechanism for distributing revocation information, but they are impractical for IoT devices that may be offline for extended periods. The IoT Hub registry approach — check-on-connect rather than CRL distribution — is more robust for devices with intermittent connectivity.

Intermediate CA Compromise Response

If your Manufacturing CA is compromised — an unlikely but catastrophic event — you need a recovery plan. Your Root CA (air-gapped, offline) can issue a new Intermediate CA certificate and revoke the compromised one. Devices already in the field retain their valid device certificates, which were signed by the (now revoked) Intermediate CA. This requires IoT Hub to trust the new Intermediate CA and maintain a revocation record for the old one.

This scenario underscores the importance of a three-tier hierarchy rather than a two-tier (Root CA directly signing device certs): the Root CA’s isolation prevents a Manufacturing CA compromise from requiring device recalls. Design your PKI hierarchy with this threat model in mind from the beginning.