Self-signed or reused certificates weaken trust boundaries because they are harder to verify, rotate, and revoke consistently. In OT, that can lead to authentication gaps, hidden identity sprawl, and outages when expired or duplicated certificates are discovered late. The result is greater operational risk and less confidence that connected devices are communicating with the right systems.
What self-signed and reused certificates break in OT trust chains
Self-signed and reused certificates do not just weaken cryptography; they weaken the operational trust model that OT depends on. When a certificate is not uniquely issued, tracked, and validated, teams lose a reliable way to prove device identity, distinguish legitimate endpoints, and understand which trust relationships still exist. That matters in environments where authentication failures can interrupt production, safety monitoring, remote access, and vendor support.
In OT, the practical failure is often not a dramatic compromise but a slow erosion of confidence. Teams may accept certificates because systems still connect, even though the same certificate appears on multiple devices or was never anchored in a controlled issuance process. That creates blind spots in asset inventory, revocation, and incident response, and it makes later remediation harder because nobody can tell which connection is authoritative. The underlying problem is not just certificate hygiene, but the collapse of traceable trust boundaries across systems that were expected to remain stable. For control guidance on identity and cryptographic trust management, see NIST SP 800-53 Rev 5 Security and Privacy Controls.
In practice, many OT teams discover the problem only after an expired or duplicated certificate has already interrupted a maintenance window or broken a device-to-device dependency.
How certificate reuse turns routine maintenance into an OT reliability problem
Certificates are supposed to give each endpoint a distinct, verifiable identity. In OT, that identity is used by historians, remote access gateways, HMIs, engineering workstations, and field devices to decide whether to trust a connection. A self-signed certificate shifts trust to whatever local exception was created when the system was first deployed. A reused certificate goes further by making multiple assets look like one identity, which destroys traceability and complicates revocation.
The practical issue is lifecycle control. If every device has its own certificate issued through a managed process, teams can rotate certificates before expiry, revoke a single compromised identity, and confirm which endpoints should still be trusted. If the same certificate is cloned across assets, revocation becomes blunt: remove it and you may break several services at once; leave it in place and you preserve an identity that may already be untrustworthy. Self-signed certificates create a similar problem because the environment often lacks a stable chain of accountability for who approved them, where they are installed, and when they should be replaced.
OT also introduces tolerance constraints that IT teams sometimes underestimate. Some controllers and embedded platforms cannot absorb frequent certificate changes, and some vendor-supported workflows assume long-lived trust relationships. That makes unmanaged certificate sprawl especially dangerous because fixes are not always immediate. The real goal is not simply “use certificates,” but ensure that each certificate supports device-specific trust, predictable renewal, and clean retirement.
- Unique issuance helps preserve device identity across the OT estate.
- Rotation only works when certificate ownership and inventory are known.
- Revocation is effective only when one certificate maps to one trust relationship.
- Late discovery turns certificate expiry into an availability event instead of a routine control action.
Where this guidance breaks down is in legacy OT segments that cannot support managed trust stores or coordinated renewal without vendor changes or planned downtime.
When the usual certificate answer fails in legacy and hybrid OT environments
Tighter certificate governance often increases operational overhead, requiring organisations to balance trust assurance against maintenance constraints. That tradeoff is most visible in brownfield OT, where some devices cannot easily accept modern certificate authorities, automated rotation, or rapid revocation without service impact.
One common edge case is vendor-managed equipment that ships with a self-signed certificate and expects it to remain in place for years. Another is certificate reuse in segmented plants where teams copied a working configuration to reduce commissioning time. Those shortcuts can appear harmless until an audit, firmware update, or replacement cycle exposes that multiple systems share the same trust material. At that point, the organisation has to choose between service disruption and continued ambiguity about identity.
Guidance also differs by risk appetite. In a tightly controlled remote-access path, self-signed certificates may be an unacceptable trust shortcut because they bypass stronger assurance. In a closed, isolated segment, the immediate operational priority may be to document and contain the exposure before replacing certificates. The consensus view is clear that reuse is poor practice; the less settled question is how quickly legacy platforms can be moved to a managed model without creating a larger outage risk during transition. In OT, that migration path matters as much as the target state.
Risk and Threat Considerations
Self-signed and reused certificates create both exposure and abuse potential because they weaken endpoint authentication and make trust relationships harder to govern. That can allow unauthorized systems to blend into legitimate OT communications, or cause teams to miss the signal that a certificate has been duplicated, expired, or replaced outside process.
Failure mechanism: The breakdown usually comes from weak identity binding and poor lifecycle control. A self-signed certificate has no strong external attestation, while a reused certificate collapses multiple assets into one trust identity. That makes validation, revocation, and forensic tracing unreliable, and it increases the chance that expired or duplicated credentials remain active until they fail in production.
Impact: The result can be authentication gaps, hidden device sprawl, loss of traceability, and outages when trust material is discovered too late. In a worse case, attackers or rogue connections can exploit the ambiguity to imitate trusted OT endpoints, especially where operators assume certificate presence equals certificate assurance.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Certificate reuse weakens identity-based access control and revocation discipline. |
| Recommendation — Revoke shared certificate trust paths and enforce one identity per managed access relationship. | ||
| NIST CSF 2.0 | PR.AC — Access Control | OT certificate trust directly affects authentication and authorization of connected assets. |
| PR.DS — Data Security | Certificates protect trusted communications between OT systems and services. | |
| RC.IM — Improvements | Late discovery of reused or expired certificates requires controlled recovery and process improvement. | |
| Recommendation — Apply PR.AC controls to verify device identities and remove ambiguous trust relationships. Use PR.DS controls to protect authenticated communications and preserve integrity of OT traffic. Use RC.IM to update certificate lifecycle processes after trust failures or outages. | ||
Practitioner Guidance
What to verify: Confirm that every OT certificate maps to a single device or service, has a known owner, and sits inside an inventory that supports expiry tracking and revocation. If the same certificate appears on more than one endpoint, treat that as a trust design issue, not just an administrative cleanup task.
Escalation / exception: Escalate immediately when a reused certificate supports remote access, safety-adjacent communications, or a vendor pathway that cannot tolerate silent trust failure. For legacy assets that cannot be remediated quickly, document the exception with a replacement plan and a control owner rather than allowing the condition to persist unnoticed.
Practitioner takeaway: The real test is not whether certificates exist, but whether each one gives you a unique, governable trust relationship that can be renewed or revoked without surprise.
Related resources from NHI Mgmt Group
- How should security teams choose between self-signed and CA-signed SAML certificates?
- What breaks when manufacturing teams rely on shared credentials and legacy authentication in OT environments?
- What do organisations get wrong when they rely on self-signed SSL certificates outside testing environments?
- What breaks when government teams rely on electronic signatures instead of digital certificates?