How do you handle certificate expiration for devices deployed in the field?

Certificate expiration is one of the most challenging operational problems for IoT devices. Unlike servers that are actively managed, embedded devices may be deployed in remote locations for 10-15 years with limited connectivity. If a device's client certificate or its stored CA certificate expires, TLS connections fail and the device goes offline — potentially with no way to recover remotely.

Prevention starts at provisioning. Issue device certificates with long validity periods (10-20 years) matching the expected product lifetime. Use intermediate CA certificates (not root CAs) for device issuance so you can rotate the intermediate without touching the root. Store the root CA certificate on the device with a very long validity (25+ years). Some deployments use certificates with no expiration at all, relying on revocation lists instead — but this requires the device to check CRL or OCSP, which adds complexity.

Certificate rotation (renewing certificates before they expire) requires a secure update mechanism. The standard approach is EST (Enrollment over Secure Transport, RFC 7030) or a proprietary cloud-based protocol: the device uses its current (still-valid) certificate to authenticate to a renewal service, generates a new key pair, sends a Certificate Signing Request (CSR), receives a new certificate, and stores it in flash. This must happen well before expiration — build in alerts when a certificate is within 10-20% of its lifetime. For the CA certificate, include it in firmware updates (OTA updates carry the new CA certificate signed by the old one).

Recovery from expiration is the hardest case. If the device certificate has already expired and the server rejects the connection, you need a fallback authentication mechanism — PSK-based TLS using a factory-provisioned key, or a special bootstrap endpoint that accepts expired certificates for the sole purpose of certificate renewal. Without such a fallback, the only recovery is physical access to the device for re-provisioning — which may be impractical for devices deployed on cell towers, in pipelines, or inside sealed enclosures.