A certificate is not a permanent fixture. Every device certificate in an OT network has a birth, a working life, and a hard expiry date, and if that date passes unnoticed the device can drop off the network overnight. Certificate lifecycle management is the discipline of tracking and acting on every stage of that life across a whole fleet of field assets, so that no certificate expires unwatched and no decommissioned device is left holding a valid one. This guide walks through the full cradle-to-grave workflow, explains why an expired certificate can take a substation or pump station offline, and shows why manual tracking breaks down once the fleet grows.
Certificate Lifecycle Management in one line: Certificate lifecycle management in OT is the end-to-end process of handling device certificates from creation to retirement: enrolling and provisioning them, keeping an accurate inventory, monitoring for approaching expiry, renewing them before they lapse, and revoking or removing them when a device is decommissioned. Its goal is to make sure certificates are always current on the assets that need them and never left valid on assets that should no longer have them, so that expiry never causes an unplanned outage.
Lifecycle management begins at enrollment, where a device obtains its first certificate from the certificate authority, and provisioning, where that certificate and the associated trust anchors are installed onto the device so it can authenticate on the network. Getting this stage right matters because the certificate's validity period, its identity fields, and its allowed uses are all fixed at issuance and travel with the device for years. Once a certificate is in service, it needs to be recorded in an inventory that captures which device holds it, when it was issued, when it expires, and what it is used for. Without that record, the organization has no reliable way to answer the one question that prevents outages: what expires next, and where.
The middle of the life is monitoring and renewal. As a certificate approaches its expiry date, it has to be renewed, meaning the device obtains a fresh certificate to replace the aging one, ideally before the old one lapses and with enough overlap that service is never interrupted. The end of the life is decommissioning: when a device is retired, replaced, or reassigned, its certificate should be revoked so that no one can reuse it, and any local trust it carried should be cleaned up. Skipping this final step is a common and quiet failure, because a decommissioned RTU pulled from a site can leave behind a still-valid certificate that an attacker could repurpose.
The reason expiry is dangerous in OT is that certificate checks are usually pass-or-fail with no grace. When a certificate expires, the devices that were authenticating against it simply stop accepting the connection, because an expired certificate is, by design, no longer trusted. A polling server that refuses an RTU's now-expired certificate stops receiving that RTU's data, and from the control room it looks exactly like the site went dark. Nothing physically failed, no cable came loose, no radio dropped, but supervision of a substation or pump station is lost until someone gets a fresh certificate onto the affected devices. In a system where certificates were issued in a batch at commissioning, many assets can share a similar expiry window, so a single missed date can knock out a cluster of sites at once.
What makes this especially painful in OT is that the fix is often physical. Many field devices cannot renew themselves automatically, so restoring service means dispatching a technician to a remote location, sometimes hours away, to re-provision a certificate by hand. The outage is therefore not measured in the seconds it takes to notice, but in the travel time to reach the asset. That asymmetry, a lapse that happens instantly but a recovery that takes hours, is exactly why lifecycle management treats expiry as something to be prevented well in advance rather than reacted to.
A handful of certificates can be tracked in a spreadsheet, and for a small pilot that may be enough. The trouble is that OT fleets do not stay small, and every added site, gateway, and controller multiplies the number of expiry dates a team has to watch. Certificates issued at different times drift out of any tidy schedule, technicians replace devices without updating the record, and the spreadsheet quietly diverges from reality until the first surprise expiry proves it wrong. Manual tracking also depends on a person remembering to look, which is precisely the kind of vigilance that erodes over months of no incidents. The failure mode is not a dramatic breach but a slow loss of accuracy that surfaces as an outage nobody saw coming.
Automation attacks the problem from both ends. Automated discovery keeps the inventory honest by finding certificates in use rather than trusting a hand-maintained list, and automated monitoring raises alerts well ahead of each expiry so renewals happen on a schedule instead of in a panic. Where devices support it, automated enrollment and renewal can obtain and install fresh certificates without a site visit at all, collapsing the recovery time that makes OT expiry so costly. A cloud SCADA platform is a natural place for this to live, because it already maintains a live view of every connected asset. Merobix, for instance, sees each gateway and RTU as it reports in, which means the certificate state of the fleet can be observed centrally rather than reconstructed from records, and approaching expirations can be surfaced to operators alongside the rest of the fleet's health instead of tracked in a separate document that no one opens until it is too late.
The device's connections stop being trusted, so authentication fails and the device effectively drops off the network even though nothing physically broke. From the control room it looks like the site went offline: telemetry stops arriving and supervision is lost. Service does not return until a fresh certificate is provisioned onto the affected device, which for remote field assets often means a technician has to travel to the site.
A certificate authority is the thing that issues and signs certificates, which is one step in the overall process. Lifecycle management is the broader discipline that surrounds issuance: keeping inventory, monitoring for expiry, renewing certificates on time, and revoking or removing them at decommissioning. The CA answers who signs a certificate; lifecycle management answers how the whole population of certificates is kept current and cleaned up over years of operation.
Because the number of expiry dates grows with every site and device, and a hand-maintained list drifts out of sync with reality as technicians swap hardware without updating records. Manual tracking also relies on someone remembering to check, which fades over long stretches with no incidents. The result is usually not a breach but a surprise expiry that takes assets offline because the spreadsheet was quietly wrong.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.