Certificates that expire on a date years in the future feel like someone else’s problem. Then the date arrives. If devices cannot renew, every unit that shares the issue disconnects together, and the repair may involve a technician visit to each one. Certificate expiry is one of the few IoT failures that is entirely predictable and still catches teams out.

Why Lifetime Is a Real Design Decision

Each device usually holds a certificate that proves its identity to the cloud, issued by a certificate authority that the cloud trusts. That certificate has a validity period. After it, the cloud will reject the device.

Short lifetimes limit the damage from a stolen key, because a credential that expires soon is less useful to an attacker. Long lifetimes reduce operational burden, because there is less to renew. Neither extreme is free. Very long lifetimes mean a compromised key stays useful for years. Very short lifetimes demand a renewal mechanism that works reliably on every device in every network condition.

The right choice depends on what your devices can actually do. A gateway with a good connection and secure storage can renew often. A battery-powered sensor that connects once a day and might be offline for weeks cannot be asked to renew on a tight schedule. Check what your platform and security guidance recommend, and requirements can differ by industry and jurisdiction.

Know What Can Expire

It is not only the device certificate. Several things have dates:

• The device’s own certificate.
• The intermediate and root certificates that sign it.
• The certificate your cloud endpoint presents, which the device must trust.
• The trusted root list baked into device firmware.

The last two cause trouble in a particular way. If the cloud provider changes the certificate chain or retires a root, and your firmware’s trust store only contains the old one, devices stop connecting without any change on their side. Your inventory of expiry dates should include every link in the chain, and who is responsible for each.

Build Renewal Into the Device From Day One

Retrofitting renewal onto a shipped fleet is painful. A sound design includes:

A renewal channel. The device can request a new certificate over its existing secure connection, before the current one expires, and the cloud issues it. Many platforms and protocols have mechanisms for this; check the current documentation of yours.

A safe swap. The device keeps the old certificate until the new one is confirmed working, then replaces it. If the new one fails to connect, it falls back. A device that overwrites its only credential with a bad one is bricked from the cloud’s perspective.

A renewal window. The device starts trying well before expiry, not at the last moment. If it fails, it retries with backoff and reports the failure through whatever channel remains.

A reliable clock. Validity checks depend on time. Devices that boot with an incorrect clock can reject good certificates or accept bad ones. Make sure time is established before certificate validation is relied on.

Monitor the Calendar, Not Just the Connection

Collect certificate expiry dates in your registry. Have the device report the expiry of its current certificate in its heartbeat. Then alert on thresholds: for example, a long-lead warning, a more urgent one, and a critical one, with owners attached to each.

Watch the distribution as well as individual devices. A graph of how many certificates expire in each coming month shows a cliff before you reach it. If a whole batch was issued on the same day with the same lifetime, they will all expire together, and your renewal load will arrive as a wave. Staggering lifetimes slightly, or renewing in rolling batches, smooths this.

Planning at a Glance

Item	Who can renew it	Failure if missed	Early warning
Device certificate	Device with cloud help	Single device disconnects	Expiry in heartbeat
Intermediate or signing CA	Platform or PKI team	Whole batch fails to authenticate	Calendar and chain inventory
Cloud endpoint certificate	Cloud provider	Devices reject the server	Provider notices, trust store review
Trust store in firmware	Firmware update	Fleet cannot validate the cloud	Roadmap of provider changes

A Hypothetical Example

Suppose a company deploys a few thousand meters with certificates valid for a long period, and nobody records the expiry date because it seems far away. Years later, a new engineer notices in a security review that the first deployment batch is approaching the end of its validity. Because the firmware has no renewal feature, the options are a firmware update that adds one, delivered before expiry, or physical visits.

The team prioritises the update, tests it on a canary group, releases it in rings, and tracks the count of devices with renewed certificates against the expiry date on a simple chart. A handful of devices that have not been seen for months are flagged to the field team. The deadline is met, but narrowly, and the lesson goes into the design checklist for the next product: renewal ships in version one.

Recovery When It Goes Wrong

Have a plan for devices whose certificates have already expired. Options include a separate bootstrap credential with very limited permissions that can only be used to request a new certificate, a maintenance mode reachable locally, or, as a last resort, physical service. Whatever you choose, it must itself be secure, because a recovery path that is easier than normal authentication is an attractive target.

Document the procedure before you need it, and rehearse it on a test device.

Frequently Asked Questions

How long should device certificates last? It depends on your devices’ ability to renew and your security requirements. Follow your platform’s and your industry’s current guidance rather than choosing a number arbitrarily.

What happens to devices that miss renewal? They are rejected by the cloud until they obtain a valid credential. That is why a limited recovery path matters.

Can I use one certificate for the whole fleet? It is strongly discouraged. A shared credential means one compromised device exposes all of them, and you cannot revoke one without revoking everyone.

Why do devices fail after a cloud-side certificate change? Often because the firmware’s trust store does not include the new root or intermediate. Review provider announcements and keep your trust store updatable.

How do I test renewal? Use test devices with deliberately short lifetimes and watch the full cycle, including failure and fallback behavior.

Next Step

Export every distinct certificate expiry date in your fleet, plus the expiry of each issuing certificate in the chain. Sort by date, find the earliest one, and confirm that there is a tested renewal path and a named owner before that date arrives.