What breaks when OT teams rely on self-signed or reused certificates?

Why This Matters for Security Teams

OT environments depend on certificates to establish device trust, protect service-to-service communication, and prevent unauthorized controllers from joining the network. When teams rely on self-signed or reused certificates, that trust becomes fragile: verification is inconsistent, revocation is unreliable, and ownership is often unclear. The practical impact is not just weaker security. It is also higher outage risk when expired certificates surface late and a harder recovery path when a certificate is duplicated across multiple assets.

National guidance already treats identity and access control as core operational safeguards, not optional hardening. That is why controls in NIST SP 800-53 Rev 5 Security and Privacy Controls matter in OT too: they require stronger assurance around authentication, credential lifecycle, and accountability. NHIMG research on the Ultimate Guide to NHIs — What are Non-Human Identities shows why this is especially urgent when machine identities outnumber human ones and are poorly inventoried.

In practice, many security teams encounter certificate risk only after a maintenance window fails or a field device stops authenticating, rather than through intentional lifecycle governance.

How It Works in Practice

Self-signed certificates create a trust model that works only if every endpoint is explicitly pinned, validated, and rotated with discipline. In OT, that is difficult because assets are long-lived, vendors manage different segments of the stack, and change windows are narrow. Reused certificates are even riskier because they collapse identity boundaries. If the same certificate appears on multiple devices, compromise of one device can undermine trust for all of them.

Current best practice is to treat certificates as machine identities that need ownership, inventory, renewal policy, and revocation paths. That means mapping each certificate to a device, service, or controller, then tracking where it is installed and who can renew it. Certificate lifecycle controls should include:

• Unique issuance per device or service, never shared across assets
• Short validity periods where operationally feasible
• Automated renewal and revocation workflows
• Central inventory with clear ownership and expiration monitoring
• Validation rules that reject unknown or duplicated identities

This aligns with the broader machine-identity guidance in The Critical Gaps in Machine Identity Management report, which found that only 38% have automated certificate lifecycle management and that certificate expiry is the leading cause of outages for 45% of organisations. On the implementation side, the SPIFFE project and the CISA Zero Trust Maturity Model both reinforce the move toward stronger workload identity and continuous verification.

These controls tend to break down when OT vendors require static trust anchors or when legacy controllers cannot support automated renewal because the environment still depends on manual certificate installation.

Common Variations and Edge Cases

Tighter certificate control often increases operational overhead, requiring organisations to balance trust assurance against uptime constraints and vendor support limits. That tradeoff is real in OT, where some assets cannot tolerate frequent changes and some platforms only support self-signed certificates during initial commissioning.

There is no universal standard for this yet, but current guidance suggests a layered approach. Use self-signed certificates only in tightly bounded cases such as bootstrap, lab, or isolated commissioning workflows, then replace them with managed internal or enterprise-issued certificates before production cutover. Reused certificates should be treated as a defect, not a convenience, unless there is a documented exception with compensating controls and a retirement date.

Edge cases include air-gapped plants, vendor-managed remote access, and legacy field devices that cannot expose modern certificate metadata. In those environments, the control objective is still the same: reduce shared trust, prevent silent reuse, and detect expiry before operations are affected. The NHIMG research on the Schneider Electric credentials breach illustrates how identity weaknesses in industrial ecosystems can become business outages when trust boundaries are not managed carefully. For broader identity failure patterns, the Sisense breach shows how credential exposure and weak identity hygiene can cascade beyond the original compromise.

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?