Certificates carry an expiry date, but sometimes you need to kill one long before that date arrives: a laptop is stolen, an RTU is pulled from a site, or a private key is suspected to have leaked. Certificate revocation is the mechanism for declaring a still-valid certificate no longer trustworthy, and for getting that decision out to every device that might otherwise accept it. This guide explains why and when a certificate is revoked, how the two main checking methods, CRL and OCSP, work, and why the intermittent connectivity of field networks makes revocation one of the harder problems in OT security.
Certificate Revocation in one line: Certificate revocation is the act of invalidating a certificate before its natural expiry, typically because the associated device or key has been compromised, lost, or decommissioned. Once revoked, the certificate should no longer be accepted by any relying party. Devices learn about revocations through a certificate revocation list, which is a signed roster of revoked certificates published by the CA, or through OCSP, an online protocol for checking the status of a single certificate on demand.
Revocation exists to close the gap between issuance and expiry. A certificate might be issued with a validity of a year or more, but plenty can go wrong in that window that makes continued trust dangerous. If a device's private key is exposed, whether through theft of the hardware, a compromised firmware image, or a mistake during maintenance, the certificate tied to that key can no longer be trusted, because anyone holding the key can impersonate the device. Revocation is how the operator declares that specific certificate dead so that relying parties stop accepting it, rather than waiting out the months until it would have expired on its own.
The other common trigger is a change in the device's status rather than a compromise. When an RTU is decommissioned, a gateway is replaced, or a contractor's engineering workstation leaves the project, the certificates they held should be revoked so they cannot be reused, either by an attacker who recovers the discarded hardware or by an insider who keeps a copy. Revocation and expiry work toward the same end, a certificate no one trusts, but revocation is the deliberate, immediate action for the cases where you cannot afford to wait. It is the emergency brake of the certificate world, distinct from the routine lifecycle churn of renewing certificates that are simply getting old.
The first mechanism is the certificate revocation list, or CRL. A CRL is a file, signed by the CA, that lists the serial numbers of every certificate the CA has revoked and that has not yet expired. Relying devices download the CRL periodically and check any certificate they are presented against the list before accepting it. The advantage of a CRL is that it works offline once fetched, because it is a self-contained signed document a device can carry and consult without reaching back to the CA at check time. The disadvantage is freshness: a device only knows about revocations up to the moment it last downloaded the list, so a revocation issued after that download is invisible until the next refresh.
The second mechanism is the Online Certificate Status Protocol, or OCSP. Instead of downloading a whole list, a device asks a responder about one specific certificate and gets back a signed answer saying whether that certificate is good, revoked, or unknown. OCSP gives near-real-time status because the answer reflects the CA's current knowledge at the moment of the query, and it avoids the bandwidth of pulling a large list. Its weakness is the mirror image of the CRL's strength: it requires the device to reach the responder at check time, so an unreachable responder leaves the device unsure whether to fail the connection or proceed without a definitive answer. Each mechanism trades freshness against the need for connectivity, and OT designs often blend them depending on how reliably a given zone can reach outside services.
Both checking methods quietly assume the checking device can reach a network resource, and that assumption is exactly what OT field networks break. A remote wellsite on an intermittent cellular link, a controller behind a firewall that blocks outbound traffic, or an asset in an air-gapped zone may have no reliable way to fetch a fresh CRL or query an OCSP responder at the moment it needs to make a trust decision. If revocation checking is configured to fail hard when status cannot be obtained, a link outage can block legitimate connections; if it fails soft and proceeds anyway, a revoked certificate might sail through unchallenged. Neither outcome is comfortable, and choosing between them is a real design decision in OT rather than a formality.
Getting revocation information into isolated zones is its own challenge. For a segment behind a data diode or truly air-gapped, a freshly signed CRL has to be carried in deliberately, on removable media during a maintenance window or pushed through whatever one-way path the zone allows, on a cadence that balances freshness against the cost of touching the zone. The practical upshot is that OT teams often lean on short-lived certificates and tight lifecycle discipline to reduce their dependence on revocation, since a certificate that expires quickly limits the damage window even if a revocation never reaches a device. In a cloud-connected model this pressure eases, because assets that maintain a live link to a hosted platform can have their trust status evaluated centrally as they connect. A platform such as Merobix authenticates each gateway or RTU at the point it reports in, so a compromised or retired device can be refused at the platform boundary rather than depending on that device to check a revocation list it may never have been able to reach.
A CRL is a signed list of all revoked certificates that a device downloads periodically and checks against offline, so it works without connectivity at check time but is only as fresh as the last download. OCSP asks a responder about one specific certificate and returns a near-real-time signed answer, which is fresher but requires the device to reach the responder when it makes the check. CRLs favor offline operation; OCSP favors freshness at the cost of connectivity.
Because both checking methods assume the device can reach a network resource, and OT field assets often sit on intermittent cellular links, behind restrictive firewalls, or in air-gapped zones where that is unreliable or impossible. If revocation checking fails hard when status is unavailable, an outage can block legitimate traffic; if it fails soft, a revoked certificate may be accepted anyway. Distributing fresh revocation data into isolated zones has to be planned deliberately rather than assumed.
Revoke it whenever you cannot afford to wait out the remaining validity, such as when a device's private key may have leaked, hardware is stolen, or an asset is decommissioned and its certificate could be reused. Expiry handles the routine aging of certificates, but revocation is the immediate action for compromise or status changes. Using short-lived certificates alongside revocation limits the exposure window when a revocation cannot reach a device quickly.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.