PKI and Certificates for Industrial IoT: What They Are and Why You Need Them

Cybersecurity must be a top priority for every industrial company: not only because of the increasing threat of cyber attacks, but also because compliance with security regulations such as CRA (Cyber Resilience Act) and NIS2 is more important than ever. 

And it all starts with certificate management and public key infrastructure (PKI), which provide the fundamental building blocks for implementing and complying with cybersecurity regulations. Here’s a look at what it takes.

The digitization of the industrial operational technology network is happening as we speak. Companies everywhere are opening up previously closed network environments to the world of cloud connectivity and distributed services.

Whereas the industrial network has traditionally followed a very clear and structured communication pyramid from the field to the enterprise level, these communications are now opened up to the point where each part and sensor can communicate with any other actor in the service mesh.

This new level of connection has huge advantages because of its flexibility, but it also opens up new concerns about security and trust. As a result, it’s absolutely essential to establish new security paradigm for Industry 4.0 – in which security is integrated at every step of the way. With a the foundation of solid and robust PKI (public key infrastructure) as the basis for trust in the processes and procedures.

Until recently, the standards and regulations governing the necessary PKI security for the industrial IoT have been akin to the Wild West. But fortunately, that’s changed over the last few years. And we’re only just getting started.

We now have several standards and regulations governing the industrial IoT, including:

62443 IEC standard: This standard offers a basic framework for the security and functionality of the machinery and component manufacturing environment. It’s a very solid framework on which all of the upcoming regulations and directives rely since it gives clear guidelines in terms of product development, service providers, operators, machine builders, and what’s required to reach a dedicated security level, as well as which functionality is needed to implement those guidelines. It’s important to note that PKI is one of the main building blocks of this standard.

Cyber Resilience Act, NIS2, and Machinery Directive: These EU regulations and directives provide requirements for products with digital elements, overall cybersecurity standards, and how to increase trust in digital technologies. Organizations must now consider how to fulfill these requirements within their infrastructure.

IEEE 802.1 AR Secure Identity standard: This is an older standard, but it provides a guide for issuing secure device and machine identities. It’s referenced in many other standards, such as OPC 10000-12, which governs discovery and global services, including the need for a built-in certificate management service, and OPC 10000-21, which looks at secure device onboarding.

RFC 8995 (BRSKI): This standard addresses bootstrapping remote secure key infrastructure, which takes a different angle to secure device onboarding, with the same goal as the OPC standard of bringing devices into a network in such a way that teams can trust in the network in front of them.

Since the 62443 IEC standard underpins everything else, it’s important to understand exactly what it entails. This is a suite of international standards focused on cybersecurity for industrial automation and the control system environment. It splits the market into the component manufacturer, the machine builder, and the plant operator, with the goal of establishing a trusted and secure relationship between each one. 

The 62443 standard defines several requirements that must be fulfilled, including identification and access control, use control, system integrity, confidentiality, data flow, and availability. Ultimately, companies must use PKI technology to meet these requirements. For example, you need proper identification and access control to issue certificates, you need proper code signing and over-the-air update processes to establish system integrity, and you need TLS connectivity to maintain data confidentiality.

The standard also provides security levels ranging from zero to four based on hacking scenarios, resources, skills, and motivation that dictate the necessary measures to have in place. Starting at Level 2, which covers a simple scenario for a hacker with low resources, general skills, and low motivation, PKI becomes mandatory.

How exactly do all of these guidelines come together in practice? Ultimately, digital certificates (managed through PKI) are the foundation of trust for all secure communications. 

On the authentication side, having all components certificate-enabled ensures that only authenticated communication parts can connect to the OT environment and establish a trusted communication network. On the signing side, having signing and encryption functionality based on X.509 certificates protects against data interception for all communications, including software updates, over-the-air updates, and more.

However, those requirements are only as good as the technology and governance implemented. Unfortunately, those implementations often fall short. For example, many companies face challenges around self-signed certificates, which go unmanaged and can cause outages. These situations can create serious vulnerabilities.

Understanding the problem behind this comes down to TLS, which is the foundation for many protocols in the OT environment to establish secure connectivity. It does so through two steps:

1. TLS handshake: Authenticates the communication partner by asking for a certificate
2. TLS record: Uses the symmetric key to establish a secure communication channel

But what if you use a self-signed certificate? A self-signed certificate means that someone generates a certificate on their own, similar to writing your name down on a piece of paper and presenting that to border control as your passport. There’s simply no proof of identity and no basis for trust. Beyond that, the expiration date for the certificate is completely unmanaged, which creates further challenges for future authentication.

A properly managed PKI program solves this problem by creating a trustworthy infrastructure with the necessary foundational units for:

• Issuing digital identities in the form of X.509 certificates
• Linking each identity to a cryptographic key
• Verifying the trustworthiness of the issuer

Together, this creates a trusted digital identity for devices and units such as servers and components. And, because a centralized PKI program issues the certificates, it also enables security teams to manage and track them throughout their lifecycle for more seamless renewals as certificates expire or become compromised.

We now have several regulations and guidelines that have created clear standards for using PKI and X.509 certificates in the industrial IoT and beyond. And we’ll see even more standards going forward.

Against this backdrop, every company working in the industrial IoT must have a clear and focused PKI strategy based on their use case and built on top of a scalable infrastructure.

Keyfactor Command and EJBCA Enterprise are examples of modern PKI solutions built to support this focus and scalability. A version of EJBCA is also offered as an open-source solution, available in an extensive GitHub repository, which provides a variety of samples, especially for the industrial world, of how to implement and configure certificates for device and machine identities based on today’s standards. You can also find Keyfactor in the Node-RED, where you can use EJBCA nodes in your workflow engine to design your workflows and implement PKI management and fetching mechanisms directly into the Node-RED workflow engine.

Finally, Keyfactor recently joined a new project called TrustPoint, with the goal of developing a PKI solution as an open-source stack for the machine builder and plant manufacturer. This solution is based on the understanding that, especially in the machine builder environment, you don’t need a full-fledged PKI, but rather a small, dedicated service available offline that can issue and manage certificates within your environment.

Ready to learn more? Watch our recent webinar on PKI and certificates for the industrial IoT.