Root CA (offline, air-gapped)
  └── Intermediate CA (factory HSM)
       └── Device Certificate (unique per device)
            • private key in ATECC608B secure element
            • public cert burned into NVS at factory
            • authenticates to Azure IoT Hub via mTLS

esp_mqtt_client_config_t cfg = {
    .cert_pem        = azure_root_ca_pem,
    .client_cert_pem = device_cert_pem,
    .client_key_pem  = device_key_pem,
};

Secure Device Lifecycle Management

Security does not end at shipment. A device in the field has a lifecycle: it receives firmware updates, its certificates expire and must be rotated, its owner may change, and eventually it reaches end-of-life and must be securely decommissioned. Each phase has security requirements that must be designed into the system from the beginning.

Certificate rotation requires a secure OTA channel to deliver new certificates before the old ones expire. If a device has been offline for an extended period and its certificate expires while offline, it will be unable to authenticate on reconnect — essentially bricking itself from a connectivity perspective. Design a bootstrap mechanism that allows devices to re-enrol with a new certificate using a secondary credential, such as a device serial number signed by a factory key stored in the secure element.

Threat Modelling for IoT Products

Before finalising your security architecture, conduct a formal threat model using the STRIDE methodology: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. For each threat, identify the attack surface, likelihood, and impact, then define mitigations. This exercise consistently surfaces security gaps that were not obvious during initial design — particularly around physical access scenarios and supply chain attacks.

Common IoT threat scenarios that threat modelling surfaces: a malicious actor extracting firmware from a production device to reverse-engineer your IP (mitigated by flash encryption); a rogue device injecting false telemetry by impersonating a legitimate device (mitigated by per-device X.509 certificates); a supply chain compromise where components are substituted with tampered parts (mitigated by factory provisioning procedures and secure element hardware binding).

Incident Response Planning

When a security incident occurs — and for any product deployed at scale, it eventually will — your response plan determines whether it is a controlled disclosure or a crisis. Define your incident response procedures before launch: how to identify compromised devices, how to remotely revoke certificates, how to push emergency patches, and how to communicate with affected customers. Azure IoT Hub provides per-device certificate revocation via the device registry — a compromised device can be disconnected and its certificate invalidated within seconds from the cloud dashboard.