PKI matters because legacy OT environments often lack segmentation, run unsupported software, and need a way to establish trust without depending on shared passwords or ad hoc exceptions. Certificates and digital signatures let teams authenticate endpoints, validate software integrity, and control access between systems even when the environment is difficult to standardize. That reduces exposure while preserving operational continuity.
Why PKI Becomes the Trust Layer in Legacy OT
In industrial control systems, PKI is not just about encrypting traffic. It is often the only scalable way to establish trust between systems that cannot rely on modern identity features, strong user interaction, or frequent software change. In flat, long-lived environments, certificates give operators a cryptographic basis for authenticating endpoints and validating what is allowed to talk to what.
That matters because legacy OT commonly mixes old protocols, shared accounts, and devices that cannot tolerate frequent manual reconfiguration. A certificate-based trust model can reduce dependence on passwords and exception-driven access while still supporting availability, but only if certificate ownership, issuance, and renewal are treated as operational controls rather than paperwork.
For OT teams, the key shift is to think of PKI as infrastructure governance, not an add-on security feature. The trust boundary is not created by the certificate alone; it is created by how consistently the plant, the CA, and the device lifecycle are managed across vendors, sites, and maintenance windows.
What PKI Protects When Segmentation Is Weak
Flat networks collapse many assumptions that enterprise defenders normally depend on. When devices can reach each other broadly, segmentation does less of the work, so PKI helps by adding device-level trust and by supporting controlled communication even where the network is not tightly separated. NIST SP 800-82 Rev 3, OT Security Guide is a useful reference point for this architecture problem.
PKI also helps protect integrity. Signed firmware, signed software updates, and authenticated control traffic reduce the chance that an attacker or a misrouted maintenance process can introduce untrusted code or impersonate a trusted endpoint. In OT, that integrity function is often more valuable than confidentiality because a malicious or faulty control action can affect safety, uptime, or product quality.
It is also important to separate PKI from full access control. Certificates can prove identity or origin, but the environment still needs authorization rules, operational approval paths, and revocation processes. A valid certificate should not automatically become a blank cheque for process controllers, engineering workstations, or remote support channels.
Where PKI Fails in Real Plants
The weak point in many industrial deployments is not the cryptography, but the lifecycle. Certificates expire, private keys get copied into places they should not be, and renewal breaks during maintenance freezes or vendor delays. The result is either an outage caused by expiry or a quiet drift back to shared credentials and bypasses. Machine Identity, PKI and Certificate Lifecycle Guide is relevant here because lifecycle discipline is what keeps trust usable.
Legacy devices create a second failure mode: they may support certificates only partially, require proprietary trust stores, or lack practical automation for enrollment and renewal. In those cases, teams can end up with long-lived certificates, weak key handling, and manual exceptions that survive far beyond the original maintenance window. That is exactly how a control meant to reduce risk becomes another brittle dependency.
Operational continuity is the real constraint. If the PKI design does not account for plant shutdown windows, vendor service models, and recovery procedures, the first certificate problem may be self-inflicted downtime. Good design therefore includes inventory, ownership, renewal timelines, and tested rollback paths, not just a CA and a policy document.
Risk and Threat Considerations
PKI in OT changes the threat picture because compromise of a certificate, private key, or issuing trust chain can turn a single foothold into broad impersonation capability. In a flat network, an attacker who steals or forges trust material may be able to move laterally, spoof engineering services, or push untrusted updates without needing to defeat every endpoint individually.
Failure mechanism: Long-lived keys, copied certificates, weak issuance controls, or poor revocation handling let trusted access survive long after the original device, user, or vendor relationship should have changed.
Impact: The result can be unauthorized access, command injection, update tampering, or service disruption across multiple OT assets, especially where segmentation and monitoring are limited.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST SP 800-57 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | OT endpoints and services need cryptographic mutual trust. |
| IA-5 — Authenticator Management | PKI lives or dies on certificate and key lifecycle control. | |
| SI-7 — Software, Firmware, and Information Integrity | Signed updates and integrity checks are central to PKI in OT. | |
| Recommendation — Use IA-9 to require authenticated service-to-service trust for control communications. Apply IA-5 to manage certificate issuance, rotation, and revocation. Use SI-7 to verify firmware and software signatures before deployment. | ||
| NIST SP 800-57 | Key Management | Certificate trust depends on secure key generation, storage, rotation, and destruction. |
| Recommendation — Use key-management controls to protect private keys across the OT lifecycle. | ||
Practitioner Guidance
What to prioritise: Start with the trust relationships that can cause the most operational damage, such as remote support paths, engineering workstations, firmware signing, and high-value service links. Those are usually the places where certificate misuse has the biggest blast radius.
What to verify: Confirm that you can answer four questions for every certificate-bearing asset: who owns it, how it is issued, how it is renewed, and how it is revoked. If any of those answers depend on tribal knowledge, the PKI is not yet operationally trustworthy.
Practitioner takeaway: In industrial OT, PKI succeeds when it replaces ad hoc trust with managed trust that survives legacy constraints, not when it is bolted onto a fragile network and assumed to solve exposure by itself.
Related resources from NHI Mgmt Group
- Why does least privilege matter so much in industrial control systems and SCADA networks?
- Why does just-in-time access matter for industrial control systems?
- How should security teams approach OT cybersecurity when legacy industrial systems are tightly connected to modern IT networks?
- How should security teams implement PKI in industrial control systems to reduce cyber risk?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
