Why do certificates matter so much in OT security?

Certificates matter because they give industrial devices a verifiable identity that survives across network zones and long asset lifecycles. Without them, teams often fall back to shared credentials, default access, or unencrypted protocols, all of which make spoofing and lateral movement much easier.

Why This Matters for Security Teams

In OT environments, certificates are more than a transport layer control. They are the practical proof that a controller, gateway, historian, or engineering workstation is what it claims to be. That matters because industrial systems often run for years, cross multiple trust zones, and still need machine-to-machine authentication that survives reboots, maintenance windows, and vendor support changes. The difference between a valid certificate and a shared password is the difference between verifiable device identity and assumptions.

Security teams get into trouble when certificate strategy is treated as a PKI project instead of an operational control. When certificates expire, are reused, or are issued without ownership and inventory discipline, outages and spoofing risks increase quickly. NHI Management Group research on the Critical Gaps in Machine Identity Management report shows that certificate expiry is the leading cause of outages for 45% of organisations, and 53% have already experienced a machine-identity-related security incident. In practice, many security teams encounter certificate failure only after an HMI, PLC, or remote access path has already stopped trusting the device, rather than through intentional lifecycle governance.

How It Works in Practice

Certificates matter in OT because they bind identity to cryptographic trust in environments where usernames and passwords are weak, shared, or technically impractical. A certificate lets one device prove possession of a private key, while a trusted CA validates that the device was enrolled correctly. This supports device authentication, encrypted sessions, and policy enforcement between assets that may never be directly exposed to the internet.

For OT teams, the real work is lifecycle management. That includes issuance, approval, renewal, revocation, inventory, and recovery when assets are offline or vendor-managed. Best practice is to treat certificates as machine identity artifacts, not just security tokens. Current guidance from the NIST Cybersecurity Framework 2.0 supports asset visibility and protective controls, but OT implementation usually requires a tighter operating model:

• Maintain a complete inventory of devices, certificate owners, and trust chains.
• Use short-lived certificates where operationally feasible, with automated renewal before expiry.
• Segment trust domains so one compromised certificate cannot authenticate everywhere.
• Track revocation and replacement procedures for systems that cannot tolerate downtime.
• Prefer device-specific certificates over shared credentials or shared secrets.

That approach aligns with the broader machine identity problem described in the Ultimate Guide to NHIs — What are Non-Human Identities, where identity is tied to the workload or device rather than to a human administrator. Certificates also support stronger segmentation and mutual authentication patterns that reduce reliance on flat OT trust models. These controls tend to break down when legacy PLCs, vendor appliances, or isolated plants cannot support automated renewal, because manual renewal becomes the single point of failure.

Common Variations and Edge Cases

Tighter certificate governance often increases operational overhead, requiring organisations to balance stronger identity assurance against uptime and maintenance constraints. That tradeoff is especially sharp in OT, where some assets cannot be patched frequently, cannot phone home for renewal, or use vendor-controlled trust stores. Best practice is evolving, and there is no universal standard for certificate rollover in every industrial protocol stack.

Edge cases usually appear in three places. First, legacy devices may support certificates only partially, forcing teams to wrap them with gateways or compensating controls. Second, certificate sprawl can create hidden risk when separate plant, vendor, and enterprise CAs all issue trust roots without central oversight. Third, outage risk rises when certificate renewal is manual, because a missed change window can stop a production line even when the certificate was otherwise secure. The gap between identity policy and uptime reality is why NHI teams should align OT certificate controls with revocation handling, ownership, and recovery testing, not just encryption requirements. NHI Management Group research on the Schneider Electric credentials breach and the Sisense breach both reinforce a simple lesson: once machine credentials or certificates are poorly governed, attackers and outages often exploit the same weakness.

Related resources from NHI Mgmt Group

• How should security teams prepare for Certificate Transparency across public certificates?
• Why do cross-certified certificates matter in federated environments?
• What do security teams get wrong about EV certificates?
• Why does OCSP stapling matter for machine identity security?