What is Certificate Management?

Certificate Management is the management of the full lifecycle of digital X.509 certificates (requesting, issuing, deploying, renewing, revoking and removing them), so that systems can reliably authenticate one another and protect their communication with encryption and integrity checks. It is the operational side of a Public Key Infrastructure (PKI). In industrial OT networks, certificate management decides whether PLCs, SCADA, HMIs, Remote Access portals and industrial firewalls trust each other. When it goes wrong, a device either refuses the connection or is left open to spoofing and man-in-the-middle attacks.


๐Ÿง  How does Certificate Management work?

A certificate binds a public key to an identity, such as a device name, IP address or OPC UA application URI. A Certificate Authority (CA) signs that binding. A system that trusts the CA therefore also trusts the certificate. Managing it follows fixed steps, as part of the wider lifecycle management:

  1. Key pair and request - ideally the device generates its own key pair and sends only a request (CSR) containing the public key. The private key then never leaves the device.
  2. Issuance - the CA checks the request and issues a certificate with identity, public key, validity period, permitted usage and signature.
  3. Deployment and trust - the certificate is installed and the communication partners add the CA to their trust list.
  4. Validation - on every connection, for example over TLS, HTTPS, VPN or S7 Comm Plus, the peer checks the signature, the chain up to a trusted CA, the validity dates and the revocation status.
  5. Renewal - a new certificate is issued well before the expiry date, preferably automatically.
  6. Revocation and removal - after a stolen key, a decommissioned device or an error, the certificate is added to a revocation list (CRL) or reported as revoked via OCSP.

๐Ÿ” Which certificate types do you encounter in OT?

Certificate type Use OT consideration
Root CA Trust anchor for all subordinate certificates Keep offline; long validity (often 10โ€“20 years)
Intermediate CA Issuance within a domain, site or zone Limits the damage if one issuing CA is compromised
Server certificate Identifies a service such as an OPC UA server, web server or HMI The name or IP address in the certificate must match how clients connect
Client certificate Authenticates a device or user, for example in 802.1X with RADIUS One certificate per device, never shared
Application instance certificate Identity of an OPC UA application Contains the ApplicationUri; acts as both client and server certificate
Self-signed certificate Factory default on many PLCs and HMIs Not cryptographically weaker, but every device has to be trusted individually
IDevID / LDevID Factory identity and local identity under IEEE 802.1AR IDevID proves origin; the operator issues the LDevID
Code signing certificate Signing firmware and software Foundation for secure boot and safe updates

๐Ÿญ Where are certificates used in industrial networks?

  • OPC UA - every client and server has an application instance certificate. The security policies Basic128Rsa15 and Basic256 use SHA-1 and are deprecated. Choose Basic256Sha256, Aes128_Sha256_RsaOaep or Aes256_Sha256_RsaPss.
  • Siemens S7-1500 - since TIA Portal V17 and CPU firmware V2.9, PG/HMI communication runs over TLS. The CPU identifies itself with a certificate that TIA Portal generates or that you import, and the certificate manager in TIA Portal keeps track of them.
  • Web interfaces - HTTPS to HMIs, web servers in field devices, switches and Remote Access portals.
  • Network access - certificate-based authentication with EAP-TLS in 802.1X and RADIUS.
  • VPN tunnels - between sites, management centres and suppliers, preferably with certificates instead of pre-shared keys.
  • MQTT - brokers and clients using TLS with a client certificate per device.
  • Energy sector - IEC 62351-9 (second edition 2023) governs key and certificate management for power system equipment, including IEC 61850 communication.
  • Zero Trust - every connection is checked on identity, and certificates provide a highly scalable form of device identity for that.

๐Ÿ”ง How are certificates deployed automatically?

Manual management works for ten devices, not for a thousand. That is why standard protocols exist for issuance and renewal:

Protocol Standard Typical use
CMP RFC 9810 (successor to RFC 4210) Full lifecycle, popular in industrial PKIs
SCEP RFC 8894 Older network equipment; relies on a shared secret
EST RFC 7030 Modern devices and IoT; requests over TLS
ACME RFC 8555 Web servers and gateways; the same technique used for public web certificates
OPC UA GDS OPC 10000-12 (Part 12) Certificates and trust lists for OPC UA applications

OPC UA Part 12 defines two models. With pull, the application itself requests certificates and trust lists from the Global Discovery Server (GDS). With push, the GDS actively installs them on the server, which requires the GDS to hold the SecurityAdmin role. For IT-based PKIs many organisations use Microsoft AD CS, linked to Active Directory.


๐Ÿ” What do IEC 62443 and legislation require?

At system level, IEC 62443-3-3 requires PKI certificates (SR 1.8) and strong public key-based authentication (SR 1.9). At component level, IEC 62443-4-2 repeats this as CR 1.8 and CR 1.9. A component must be able to validate the certificate chain up to a trusted CA and check the revocation status. At higher security levels the private key must be protected in hardware, for example with a Trusted Platform Module.

For Dutch organisations under the Cybersecurity Act (in force since 15 August 2026) and NIS2, cryptography and access control are among the mandatory security measures. The Cyber Resilience Act sets requirements for manufacturers on secure default settings and confidentiality: reporting obligations apply from 11 September 2026 and full application from 11 December 2027.


๐Ÿงญ How do you set up certificate management in an OT environment?

  1. Inventory all certificates - use the asset inventory to record per device which certificates exist, who issued them and when they expire.
  2. Design your own PKI - an offline root CA and an intermediate CA per site or zone, in line with the zones and conduits model.
  3. Choose validity periods deliberately - public TLS certificates have been limited to 200 days since 15 March 2026, dropping to 100 days from 15 March 2027 and 47 days from 15 March 2029 (CA/Browser Forum ballot SC-081). A private CA is not bound by this. In OT, organisations often choose several years for device certificates, and shorter where automatic renewal works.
  4. Ensure correct time - certificate validation needs a reliable clock. Without NTP or PTP a valid certificate appears expired or not yet valid.
  5. Make revocation practical - isolated networks often cannot reach an external OCSP server. Publish the CRL locally and set its refresh interval accordingly.
  6. Automate and monitor - use EST, CMP or the OPC UA GDS, alert well before expiry dates and send changes to monitoring, SIEM and audit logs.
  7. Plan for cryptographic ageing - RSA-2048 and ECDSA P-256 are adequate today. Under the draft NIST IR 8547 (November 2024), RSA-2048 is deprecated after 2030 and RSA and ECC are disallowed altogether after 2035. A device you buy now will often still be running by then. Include post-quantum cryptography when replacing your PKI and devices.

โ“ Frequently asked questions

What happens when a certificate expires in OT?

When a certificate expires, the peer refuses the connection, because it checks the validity dates on every connection. An HMI then loses its connection to the PLC or a historian stops receiving data, without any attack taking place. Monitoring expiry dates and renewing automatically prevents this kind of downtime.

Are self-signed certificates acceptable in OT?

Self-signed certificates are cryptographically as strong as CA-issued certificates, but every device has to trust them individually. That is workable for a few devices, but with hundreds it becomes unmanageable and the certificates cannot be revoked centrally. Replace factory certificates with certificates from your own PKI.

Do OT networks need their own CA?

An OT network usually needs its own private CA, because public CAs do not issue certificates for internal names and private IP addresses and demand ever shorter validity. Your own CA gives you control over validity, revocation and trust per zone. Many organisations place the OT CA under a separate root, apart from the IT PKI.

What is the difference between a CRL and OCSP?

A CRL (Certificate Revocation List) is a periodically published list of revoked certificates that the device downloads itself. OCSP (Online Certificate Status Protocol) queries a server for the current status of each certificate. In isolated OT networks, a locally published CRL is often the practical choice.

How long should a certificate in OT be valid?

There is no legal maximum for a private OT PKI: root CAs are often given 10 to 20 years, device certificates usually several years. Shorter periods limit the damage from a stolen key but require automatic renewal. Public TLS certificates have been limited to a maximum of 200 days since 15 March 2026.

What role does a TPM play in certificate management?

A Trusted Platform Module stores the private key of a certificate in hardware, so it cannot be copied. IEC 62443-4-2 calls for this kind of hardware protection at higher security levels. When the device is replaced, you generate a new key and request a new certificate.


๐Ÿ“Œ In summary

Certificate Management governs the full lifecycle of digital certificates, so that PLCs, SCADA, HMIs and gateways reliably authenticate each other and communicate in encrypted form. With your own OT PKI, automatic deployment via EST, CMP or the OPC UA GDS, reliable time, expiry monitoring and a plan for post-quantum cryptography, you prevent both downtime from expired certificates and attacks using forged identities.