You inherit an IoT fleet of 80,000 devices whose client certificates all expire in fourteen months. What do you do?

Establish whether rotation is even possible

The first question is whether the current firmware can obtain and install a new certificate remotely. If it cannot, this is not a rotation exercise; it is a firmware update campaign with a hard deadline, and the timeline is much tighter than fourteen months.

Find out per firmware version, because a fleet of this size will have several and the oldest is usually the one that cannot.

Sequence backwards from the deadline

Rotation cannot be a single event. Devices are offline, on poor links, or in storage — and a fleet that all renews on the same day recreates the reconnection storm problem at the worst possible moment.

Plan a staged rollout over months with jitter, beginning far enough ahead that a device offline for eight weeks still gets several attempts.

Build the mechanism to be reusable

This will recur. What should exist afterwards:

• Automatic renewal well before expiry, with retry and jitter.
• Fleet-wide visibility of certificate age, so the next expiry is a dashboard rather than a discovery.
• Shorter certificate lifetimes, which sounds counterintuitive and is correct: frequent rotation exercised routinely is far safer than a three-year certificate whose renewal path has never run.

Plan for the devices that will not make it

Some proportion will be offline, bricked, or on firmware that cannot rotate. Decide in advance: a grace period with a compensating control, a manual intervention path, or accepting the loss.

Knowing the number matters — 2% of 80,000 is 1,600 devices and a support plan.

What to escalate now

This is a fleet-wide availability risk with a fixed date. It needs to be on the risk register with an owner and a plan, not managed as an engineering task — because if the mechanism does not exist, the lead time for firmware development, testing and staged deployment across 80,000 devices may exceed the fourteen months.