A lot of plants spent the last year or two doing the right thing: turning on OPC UA security, requiring signed certificates instead of anonymous auth, locking down endpoints per IEC 62443 guidance and vendor hardening checklists pushed hard by CISA advisories. Good work. Then, twelve months later, the certificates those deployments were built on start expiring — quietly, on no particular schedule anyone documented — and the same plants discover that hardening a system and operating a system are two different disciplines. A PLC that stops trusting its MES connector because a cert lapsed looks, to the operator on the floor, exactly like a PLC that’s broken.
This is now a predictable failure mode. Here’s how to get ahead of it before your first mass expiration cycle turns into a scramble.
Why this catches plants off guard
OPC UA’s security model relies on X.509 certificates for both servers and clients — every PLC-side OPC UA server, every gateway, every MES or historian connector acting as a client needs its own certificate, typically with a lifetime somewhere around one to two years depending on how your CA or self-signed process was configured. That’s a sane security default. The problem is organizational, not technical: certificate issuance usually happens once, during a commissioning project, handled by an integrator or controls engineer who may not be the person still on staff when renewal comes due. Nobody puts “cert expires” on a maintenance calendar next to lubrication schedules and firmware patches, because it doesn’t feel like plant floor work. It feels like IT work. And IT doesn’t know your OT network has forty of these things scattered across PLCs from three different vendors.
When a cert expires, the behavior isn’t always a clean error message. Depending on the stack, you get a secure channel that silently fails to establish, a client that falls back to a lower security mode (if it’s allowed to, which defeats the point of hardening in the first place), or a connector that retries in a loop while your historian shows a flat line and nobody notices until a shift supervisor asks why the dashboard hasn’t updated since midnight.
Step 1: Build a real certificate inventory
You can’t manage what you haven’t mapped. Before anything else, build an inventory that captures, for every OPC UA server and client endpoint on the floor:
- Device or software identity (PLC model and station, gateway, MES connector, historian client, SCADA node)
- Certificate subject, issuer (self-signed, internal CA, or third-party CA), and thumbprint
- Issue date and expiration date
- Where the private key lives and who/what has access to rotate it
- Whether the endpoint trusts a specific peer certificate directly or trusts a CA chain
Some OPC UA server implementations expose certificate metadata through their configuration UI or via the GDS (Global Discovery Server) if you’re running one — use it. If you’re not running a GDS, this inventory will likely be manual the first time, built by walking engineering workstations, gateway configs, and MES integration platform certificate stores. That’s tedious, but it only has to be painful once. Put it in a spreadsheet or, better, a lightweight CMDB-style tracker with an expiration column that someone actually owns. The goal is a single source of truth that answers “what expires when” without anyone needing to log into forty devices to check.
Don’t forget the client side
Teams instinctively think about server certificates — the PLC, the gateway — because that’s the thing that “provides” OPC UA. But every client (your MES connector, your historian, any SCADA client establishing a secure session) also holds its own certificate, and many of those are trusted individually on the server side via an explicit trust list rather than through a CA chain. That means renewing a client certificate isn’t just a client-side operation — it requires re-establishing trust on every server endpoint that whitelisted the old cert. Miss that step and the client renews cleanly but every PLC it talks to rejects the new identity.
Step 2: Stop planning a big-bang cutover
The instinct, once you’ve built the inventory and realized how many certs are clustered around the same commissioning date, is to schedule one large renewal event — a maintenance window where everything gets swapped at once. Resist that. A big-bang renewal concentrates risk: one misconfigured trust list or one CA hiccup and you’ve got a plant-wide outage instead of a contained one.
Instead, build a rolling renewal calendar:
- Stagger expiration dates deliberately when you issue new certificates — don’t let a batch renewal recreate the same cliff-edge twelve or twenty-four months out.
- Group renewals by production line or cell rather than by device type, so a mistake affects one line’s downtime window, not the whole plant.
- Set alert thresholds well ahead of expiration — 90, 60, and 30 days out — tied to an actual owner, not a shared inbox.
- Renew during planned downtime for that asset wherever possible, not during production.
If your CA or GDS tooling supports it, deliberately vary certificate lifetimes across the fleet during your first remediation pass specifically to break up the clustering. It feels counterintuitive to make things less uniform, but uniform expiry dates are exactly what creates the mass-failure scenario in the first place.
Step 3: Automate what you can, formalize what you can’t
Full certificate lifecycle automation across a heterogeneous fleet of PLCs and gateways from different vendors is genuinely hard — this isn’t a web server fleet where ACME and short-lived certs are the norm. Automatic renewal support varies a lot by vendor and firmware version, and some legacy OPC UA server implementations still require manual certificate installation through a local config tool. Be honest about which devices support automated renewal (via a GDS pushing new certs and updated trust lists) and which don’t.
For anything that can’t be automated, the fallback is process, not technology: a documented runbook per device class, a named owner, a change ticket tied to the renewal, and a rollback plan if the new certificate doesn’t establish trust cleanly. Write down exactly which trust stores need updating and in what order — server trusts client, client trusts server, and if there’s an intermediate gateway in the path, it needs both.
Step 4: Test trust, not just issuance
Issuing a new certificate is not the same as confirming the secure channel actually establishes. After every renewal, verify the session comes up at the intended security policy (not a silent downgrade), check application logs for certificate validation warnings, and confirm the MES side is actually receiving fresh data — not just that the connection status light looks green. A connector can report “connected” while quietly failing to read updated tag values if a certificate mismatch triggers unexpected fallback behavior in a permissive client configuration.
What “done right” looks like
A mature setup has three things a rushed hardening project usually lacks: a living inventory with expiration dates visible in one place, renewal dates deliberately spread across the calendar instead of clustered around a single commissioning date, and alerting that fires at 90 days out to a named owner rather than being discovered when a line stops talking to the historian. None of that requires exotic tooling. It requires treating certificate expiration as a maintenance schedule item with the same seriousness as a firmware patch cycle or a backup verification — because functionally, that’s exactly what it is.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
