By Yair Knijn · February 13, 2026
The edge devices have certificates that can't be renewed remotely. The clock is still ticking.
A device sits in a substation cabinet, or bolted to a rooftop HVAC unit, holding a client certificate burned in on the factory line. Ten-year validity, no renewal service, no plan for re-enrollment. Not a lazy call: long lifetimes mean fewer moving parts, and nobody wants a field meter phoning home just to stay alive.
But the decision bets that certificate lifetimes will outlast the hardware, and the industry is settling that bet the other way. CA/Browser Forum ballot SC-081v3 passed in April 2025: public TLS validity drops to 200 days in March 2026, 100 days in March 2027, and 47 days from March 15, 2029. The clock on every cert you ship today is shorter than the clock on the box it lives in.
Why embedded and OT fleets dodge normal cert automation
Web servers renew with certbot and a cron line because they have an operator, an outbound network, and a writable disk. Embedded and OT devices have none of that. They sit on isolated segments, behind NAT they cannot traverse outbound, on read-only root partitions, watched by a security team that logs any new outbound connection as an incident. So the cert gets provisioned once, on the line, and renewal gets pushed to "we'll handle it before it expires." You will not, because at fleet scale there is no manual path. Tens of thousands of devices on annual certs is tens of thousands of renewal events a year; cut to 90 days and that quadruples, against endpoints you cannot reach.
Shrinking lifetimes vs devices you can't reach
The dangerous gap is between cert lifetime and device service life. A meter stays in the field for 10 to 15 years; a public cert issued in 2027 lasts roughly three months. If renewal means a technician with a laptop and a site visit, the math fails the moment the first cert lapses, and it fails all at once, because devices from the same batch expire in the same window. The 47-day floor makes it explicit: short enough that manual management is hopeless, long enough that a weekly cadence still leaves slack to retry.
Build EST, SCEP, or ACME into the device, not the spreadsheet
The renewal channel has to live in the firmware and ship before the device does. Retrofitting an unreachable fleet is the exact failure this post is about. Pick the protocol against your network reality, not habit:
- EST (
RFC 7030) succeeds SCEP: HTTPS with TLS client auth and automated re-enrollment, using the existing cert as proof of identity. Default to it for new designs. - SCEP is still everywhere in OT and network gear. Use it when your CA and device stack already speak it, knowing its challenge-password model is weaker than EST's mutual TLS.
- ACME suits devices that can reach a CA and own a routable identifier, but
http-01anddns-01rarely map onto an OT segment;RFC 8995BRSKI handles the bootstrap EST leaves open.
Whatever you pick, the device needs a secure key store, an identity that survives a failed renewal, and a retry loop that does not brick the unit when the CA is briefly unreachable. Renew at half the lifetime, never on the last day.
Private PKI and longer-lived internal trust
Most device-to-device and device-to-gateway traffic never touches a public CA, and it should not have to. A private PKI lets you set internal lifetimes that match your own cadence instead of the public ballot schedule. You still automate renewal; you just own the validity policy. Keep publicly trusted certs for the surfaces a browser validates, everything internal on your own roots.
Automate Certificates issues, tracks, and renews fleet identities from one Environment, so EST and SCEP enrollment, expiry monitoring, and private-CA policy live in one place instead of a spreadsheet with a date on it. Scoping a connected-product line now? Design the renewal path before the first unit ships, and see how enrollment and renewal fit your fleet.