PKI for IoT Devices

PKI for IoT assigns a unique cryptographic identity to each device — a certificate bound to a private key stored in the device’s secure element or TPM. This certificate authenticates the device to cloud platforms, gateways, and other devices without passwords or shared secrets. Unlike server PKI where you manage hundreds or thousands of certificates, IoT PKI operates at millions of devices with constrained hardware, intermittent connectivity, and 10-20 year lifespans.

Why it matters

• Device authentication — certificates prove a device is genuine hardware from your manufacturing line, not a counterfeit or compromised clone. Cloud platforms (AWS IoT Core, Azure IoT Hub) use client certificates for device authentication.
• No shared secrets — pre-shared keys (PSK) don’t scale. If one device is compromised, the shared key is exposed for all devices in that group. Per-device certificates isolate compromise to a single device.
• Encrypted communication — TLS/DTLS between device and cloud requires certificates. Without PKI, you’re sending sensor data in plaintext or relying on network-level security that doesn’t exist in the field.
• Firmware integrity — code signing certificates verify that firmware updates are authentic. Without this, an attacker with network access can push malicious firmware to devices.
• Regulatory compliance — IEC 62443 (industrial), ETSI EN 303 645 (consumer IoT), and Matter (smart home) all require device identity based on asymmetric cryptography.

How it works

1. Secure element provisioning — during manufacturing, a private key is generated inside the device’s secure element (ATECC608, TPM, or TrustZone). The key never leaves the hardware.
2. Certificate request — the device (or manufacturing station) generates a CSR containing the device’s unique identifier (serial number, MAC address) as the Subject/SAN.
3. CA signs the certificate — a dedicated IoT Issuing CA signs the device certificate. This CA is subordinate to the organization’s Root CA.
4. Certificate stored on device — the signed certificate is written to the device’s secure storage alongside the CA chain.
5. Device connects — on first boot, the device presents its certificate to the cloud platform via mTLS. The platform validates the chain against its trusted CA bundle.
6. Lifecycle management — certificate renewal, revocation, and re-provisioning must be handled over the device’s operational lifetime (potentially 10-20 years).

In real systems

AWS IoT Core — device certificate registration:

# Register a CA with IoT Core
aws iot register-ca-certificate \
  --ca-certificate file://iot-ca.pem \
  --verification-certificate file://verification.pem

# Register a device certificate (just-in-time registration also available)
aws iot register-certificate \
  --certificate-pem file://device-cert.pem \
  --ca-certificate-pem file://iot-ca.pem \
  --set-as-active

EST (Enrollment over Secure Transport) for IoT:

# Device requests certificate via EST endpoint
POST /.well-known/est/simpleenroll
Content-Type: application/pkcs10
Authorization: Basic <device-bootstrap-credentials>

<base64-encoded CSR>

EST is preferred over ACME for IoT because it supports client certificate authentication for re-enrollment (the device uses its current certificate to authenticate the renewal request).

Microchip ATECC608 secure element: The private key is generated inside the chip during manufacturing and can never be read out — only used for signing operations. The chip performs ECDSA P-256 signatures in hardware. Certificate storage is limited to ~3 compressed certificates (using a Microchip-specific format to fit in 1KB of secure memory).

Azure IoT Hub DPS (Device Provisioning Service):

{
  "enrollmentGroupId": "factory-floor-sensors",
  "attestation": {
    "type": "x509",
    "x509": {
      "signingCertificates": {
        "primary": { "certificate": "<intermediate-ca-pem>" }
      }
    }
  }
}

DPS uses group enrollment — any device with a certificate signed by the specified intermediate CA is automatically provisioned to the correct IoT Hub.

Where it breaks

Certificate renewal on offline devices — a fleet of 50,000 sensors deployed in remote locations has certificates expiring in 2 years. The devices connect intermittently (once per day for 30 seconds). Renewal requires generating a CSR, sending it to the CA, receiving the new certificate, and installing it — all within a brief connectivity window. If renewal fails, the device can’t authenticate on its next connection. Without a robust retry mechanism and grace period, devices go dark permanently after certificate expiry.

CRL explosion at scale — you revoke 10,000 compromised device certificates. The CRL now contains 10,000 entries. Every device that checks revocation must download this growing list over constrained bandwidth (cellular, LoRaWAN). OCSP is better but requires the device to be online and adds latency to every connection. Short-lived certificates (hours/days) are the cleanest solution — compromised devices simply can’t renew — but require reliable connectivity for frequent renewal.

Secure element not used — to save $0.50 per unit, the hardware team stores the private key in flash memory instead of a secure element. An attacker with physical access to one device extracts the key, clones the device identity, and authenticates as a legitimate device. At scale, this enables fleet-wide impersonation. The cost savings on hardware creates an unrecoverable security gap.

Operational insight

The fundamental tension in IoT PKI is between certificate lifetime and device reachability. Server certificates can be short-lived (90 days) because servers are always online and can renew anytime. IoT devices may be offline for months, deployed in inaccessible locations, or running on battery with no compute budget for cryptographic operations. The practical solution is tiered validity: devices get long-lived certificates (5-10 years) for authentication, combined with short-lived session tokens for authorization. The long-lived certificate proves identity; the session token (refreshed when online) controls what the device can actually do. This way, a compromised certificate without a valid session token is useless.

Related topics

• What is a Certificate Authority
• Cloud-based PKI
• What is mTLS
• Certificate Renewal and Revocation
• What is EST