How to Prevent Bricked IoT Devices When Certificates Expire

When the Let's Encrypt DST Root CA X3 expired in September 2021, the fallout rippled far beyond web browsers. Millions of legacy IoT devices—including smart TVs, industrial sensors, and payment terminals—were permanently knocked offline. Because these devices lacked Over-The-Air (OTA) update capabilities and had their trust anchors hardcoded into firmware, they became expensive paperweights overnight.

This incident highlighted a fatal design flaw in how the industry approaches IoT identity.

Today, IoT environments involve millions of devices deployed in physically inaccessible locations, often with lifespans exceeding 10 years. With the global fleet of connected devices expected to surpass 30 billion by 2025, the traditional "flash it at the factory and forget it" approach to Public Key Infrastructure (PKI) is no longer viable. Furthermore, as the National Institute of Standards and Technology (NIST) finalizes Post-Quantum Cryptography (PQC) standards, devices manufactured today will likely outlive the security of their current RSA and ECC algorithms.

To survive in this landscape, organizations must implement automated Certificate Lifecycle Management (CLM) that prioritizes crypto-agility, hardware-backed security, and continuous visibility.

The End of "Flash and Forget"

Historically, manufacturers injected 10-year certificates into devices on the assembly line. This approach is now a massive liability. If a private key is compromised, or if the issuing Certificate Authority (CA) is deprecated, the device loses its ability to authenticate to the cloud.

Regulatory pressures are also forcing a paradigm shift. The EU Cyber Resilience Act (CRA) and the US Cyber Trust Mark mandate that connected products maintain secure update mechanisms and handle vulnerabilities for years after purchase. Meeting these standards practically requires automated certificate management.

To build a resilient IoT PKI, engineering teams must separate the device's immutable hardware identity from its operational network identity.

The Dual-Identity Architecture: IDevID and LDevID

The IEEE 802.1AR standard provides the blueprint for modern IoT device identity by defining two distinct certificate types:

1. Initial Device Identifier (IDevID): Injected at the factory. This is a long-lived certificate tied to a cryptographic hardware root of trust. It proves the device's provenance (e.g., "I am a genuine sensor manufactured by Acme Corp").
2. Locally Significant Device Identifier (LDevID): Provisioned when the device is deployed in the customer's environment. This certificate is issued by the customer's operational PKI, is used for daily mutual TLS (mTLS) authentication, and has a much shorter lifespan.

By using the IDevID solely to securely negotiate an LDevID during the initial onboarding phase, you isolate your factory supply chain from your operational network.

Automating Certificate Provisioning at the Edge

To issue and rotate LDevIDs without human intervention, IoT fleets rely on automated bootstrapping protocols. While the ACME protocol (Automated Certificate Management Environment) dominates the web space, Enrollment over Secure Transport (EST)—defined in RFC 7030—is often better suited for constrained IoT devices.

EST uses standard HTTPS and requires less parsing overhead than ACME's JSON payloads. Here is an example of how a device might request a new certificate using EST via curl, assuming the device's private key is securely stored:

# Requesting a new certificate via EST simpleenroll
curl -v https://pki.example.com/.well-known/est/simpleenroll \
  --cacert root-ca.pem \
  --cert idevid-cert.pem \
  --key idevid-key.pem \
  --data-binary @device-csr.der \
  -H "Content-Type: application/pkcs10" \
  -o new-ldevid-cert.p7c

Once the device receives the PKCS#7 payload (new-ldevid-cert.p7c), it extracts the new X.509 certificate and begins using it for mTLS connections. Because this process is entirely scriptable, it can be scheduled to run automatically before the current LDevID expires.

Securing the Private Key: Hardware Roots of Trust

Automated rotation is useless if the underlying private key can be easily stolen. IoT devices are frequently deployed in the field (e.g., smart city infrastructure or agricultural sensors), making them vulnerable to physical attacks.

In a notable 2022 security incident, researchers bypassed signature verification on Starlink user terminals using voltage fault injection, allowing them to execute custom code. This underscores a critical rule: private keys must never be stored in plaintext firmware.

Best practices dictate generating and storing keys within a Trusted Platform Module (TPM), a Secure Enclave, or using Physically Unclonable Functions (PUFs). When a key is generated inside a TPM, it cannot be exported. The device asks the TPM to sign the Certificate Signing Request (CSR), ensuring the private key never touches the device's RAM or storage.

Using OpenSSL with a TPM 2.0 engine, a device can generate a hardware-backed CSR like this:

# Generate a primary key in the TPM
tpm2_createprimary -c primary.ctx

# Create an RSA key pair inside the TPM
tpm2_create -C primary.ctx -G rsa2048 -u key.pub -r key.priv

# Load the key into the TPM and generate a CSR via OpenSSL
openssl req -new -engine tpm2tss -keyform engine -key my_tpm_key \
  -subj "/C=US/O=Acme IoT/CN=sensor-8472" \
  -out hardware-backed.csr

Solving the Revocation Problem with Short-Lived Certificates

If a device is compromised, its certificate must be invalidated. In traditional enterprise IT, this is handled via Certificate Revocation Lists (CRLs) or the Online Certificate Status Protocol (OCSP).

However, IoT devices often lack the memory to store massive CRLs, and relying on OCSP introduces latency and requires constant internet connectivity—a luxury not all edge devices have.

The modern solution is to shift to short-lived certificates. Influenced by the broader industry push toward 90-day (or shorter) lifespans, IoT networks are adopting certificates that expire in days or even hours. If a device is compromised, the centralized CA simply refuses to issue the next automated renewal. The current certificate expires shortly after, naturally locking the rogue device out of the network without the need for complex revocation infrastructure.

A major European automaker successfully implemented this in their Vehicle-to-Everything (V2X) communications. To prevent vehicles from being tracked over time by a static certificate, the system provisions "pseudonym certificates" that rotate every few minutes. This requires a highly automated, high-throughput PKI, but completely eliminates the need for CRLs.

Cloud-Native Onboarding and JITP

For teams operating at scale, building a homegrown CA script is a recipe for an eventual outage. Instead, leverage cloud-native tools designed for IoT scale.

Platforms like AWS IoT Core offer Just-in-Time Provisioning (JITP). With JITP, you register your offline factory CA with AWS. When a device connects to AWS IoT for the first time using a certificate signed by that factory CA, AWS automatically recognizes it, provisions a cloud-specific operational certificate, and attaches the necessary IAM policies.

Here is an example of an AWS IoT JITP provisioning template that automatically activates the certificate and attaches a restricted policy based on the device's Common Name (CN):

{
  "Parameters": {
    "AWS::IoT::Certificate::CommonName": {
      "Type": "String"
    },
    "AWS::IoT::Certificate::Id": {
      "Type": "String"
    }
  },
  "Resources": {
    "thing": {
      "Type": "AWS::IoT::Thing",
      "Properties": {
        "ThingName": {"Ref": "AWS::IoT::Certificate::CommonName"}
      }
    },
    "cert": {
      "Type": "AWS::IoT::Certificate",
      "Properties": {
        "CertificateId": {"Ref": "AWS::IoT::Certificate::Id"},
        "Status": "ACTIVE"
      }
    },
    "policy": {
      "Type": "AWS::IoT::Policy",
      "Properties": {
        "PolicyDocument": "{ \"Version\": \"2012-10-17\", \"Statement\": [ { \"Effect\": \"Allow\", \"Action\": [ \"iot:Connect\", \"iot:Publish\" ], \"Resource\": [ \"arn:aws:iot:us-east-1:123456789012:topic/telemetry/${iot:Connection.Thing.ThingName}\" ] } ] }"
      }
    }
  }
}

This zero-touch provisioning model ensures that devices are securely onboarded the moment they are powered on in the field, bridging the gap between hardware manufacturing and cloud operations.

Visibility: Trust, but Verify Your Automation

Automating your IoT certificate lifecycle solves the provisioning problem, but automation without visibility creates blind spots. Cron jobs fail. Network partitions prevent devices from reaching the EST server. Subordinate CAs expire, causing the entire downstream fleet to fail their renewals silently.

If you don't know a device's certificate is failing to renew until it drops off the network, your automation has failed.

This is where centralized expiration tracking becomes critical. While your PKI issues the certificates, you need an independent system to monitor the endpoints and the CA chains. Using a platform like Expiring.at allows DevOps and security teams to track certificate health across distributed IoT fleets. By monitoring the actual endpoints and alerting when a certificate approaches expiration without a successful rotation, you catch the automation failures before the device is bricked.

Tracking the expiration of your intermediate and root CAs is equally vital. A dedicated IoT PKI hierarchy should have a planned rotation schedule for its intermediate CAs, ensuring that new devices are always provisioned with a trust chain that outlives their expected deployment lifecycle.

Securing the Next Decade of IoT

The sheer volume of connected devices, combined with the impending transition to Post-Quantum Cryptography, makes manual certificate management impossible.

To future-proof your IoT infrastructure:
1. Never hardcode trust: Transition from static 10-year certificates to automated rotation using EST or ACME.
2. Enforce hardware security: Mandate the use of TPMs or Secure Enclaves for private key generation and storage.
3. Adopt short-lived certificates: Bypass the complexities of CRLs and OCSP in constrained environments by issuing certificates that expire quickly