A proactive approach to OT Security

Introduction: The Devices You Don't See

Your organization has the latest tools to manage its IT landscape. Mobile Device Management (MDM) software secures your phones, laptops, and PCs, controlling access and enforcing strict security policies. But what about the other devices?

In every facility, there's a universe of connected technology operating just beyond the traditional IT umbrella. Managed switches, IP cameras, specialty printers (ex, bar code), point-of-sale systems, HVAC controllers, wearable computers, and PLCs—these devices make up the Operational Technology (OT) and Industrial IoT (IIoT) space.

Are the same, strict policies and procedures in place for these devices? What if one is attacked? A casino's high-roller database was once famously hacked through a smart thermometer in a fish tank. A major telecom provider suffered an outage because the same root of trust was used to manage both its IT and OT networks. These aren't theoretical risks; they are real-world breaches caused by unsecured operational devices.

The goal of this e-book is to provide a clear, actionable guide to securing your OT environment. We will move beyond the problem and focus on the practical solutions.

What You'll Learn

This guide will walk you through the essential best practices for OT security. We will cover how to:

Know and categorize every device on your network.
Properly segment networks that contain legacy devices.
Separate your IT and OT network backbones and Public Key Infrastructure (PKI).
Select the right vendors and enforce modern security standards like secure boot, secure updates, and proactive CVE notifications.

Chapter 1: Building Your Foundation

Know Your Devices

You cannot secure what you cannot see. The first and most critical step is to conduct a complete inventory of every device communicating on your infrastructure. While spreadsheets have been a traditional tool, they are often out-of-date and fail to capture the full picture of cryptographic risk.

Modern discovery tools are superior, helping you identify everything connected to your Wi-Fi and Ethernet networks. The data from these tools reveals what cryptographic algorithms are in use, pinpoints high-risk identities like self-signed certificates, and flags dangerously long-lived certificates that violate security best practices.

Categorize Your Devices

Once identified, you can categorize devices by how they establish and manage their trusted identities. This framework will define your security strategy for each type of asset.

Devices Lacking Native Secure Communication

Devices implementing protocols like Modbus (RTU or TCP/IP), Profibus, Profinet, and HART were not originally designed with modern security in mind. They lack native encryption and authentication, preventing a zero-trust relationship. These devices and their networks must be secured through compensating controls like network segmentation and external security appliances.

Devices Using Symmetric, Pre-Shared Keys

Devices implementing protocols such as LoRaWAN, Zigbee, Z-Wave, and Bluetooth Mesh establish trust using a system of symmetric keys. While not a single key for the entire ecosystem, devices on a given network share a common network key that is derived from a pre-shared root secret during a secure joining process. The compromise of this root secret can allow a rogue device to join and be trusted at the network layer, making secure provisioning and regular key rotation critical hygiene.

Devices with Manual Certificate-Based Identity

These devices use modern security protocols like Transport Layer Security (TLS) but lack automated methods for identity renewal. They require an operator to generate a key and certificate offline and then manually load them onto the device. To avoid operational downtime, these devices are often configured with extremely long-lived certificates and, in worst-case scenarios, share the same certificate across multiple devices, creating significant risk if a key is ever compromised.

Devices with Programmatic Certificate Management Endpoints

Representing a move toward automation, these devices expose an API (e.g., REST, SSH) that allows for external certificate management. This enables a centralized orchestration tool to automate the renewal and provisioning of identity certificates, forming a key component of a managed zero-trust network.

Devices Supporting Automated Certificate Enrollment Protocols

These devices natively support standard enrollment protocols like SCEP (Simple Certificate Enrollment Protocol), EST (Enrollment over Secure Transport), CMPv2 (Certificate Management Protocol), and ACME (Automated Certificate Management Environment). This allows the device itself to securely request, renew, and install its own identity certificate from a Certificate Authority with minimal to no human intervention.

Devices Supporting Identity Management via Software Agents

Flexible devices like Industrial IoT Gateways, modern switches, and Single Board Computers allow for third-party software agents to be installed. This capability can be leveraged to upgrade a device's security posture. For example, an agent could be installed on a device to give it automated enrollment capabilities (Category 5) or to expose a programmatic endpoint for management (Category 4), providing a powerful path for modernizing security. An even better approach is to use an agent in conjunction with a centralized Certificate Lifecycle Manager (CLM), enabling it to not only automate renewals but also proactively rotate keys and replace certificates in response to a compromise anywhere in the issuing chain.

Devices that leverage certificates can be shown in the diagram below:

Chapter 2: Uncovering Hidden Risks in Your X.509 Certificates

For devices that rely on X.509 certificates for their identity, not all trust is created equal. A certificate is more than just a digital file; it's a statement of trust. However, if that trust is built on a weak foundation, it can expose your entire network to significant risk.

Think of it like a building inspection. You don't just check if the doors are locked; you inspect the foundation, the wiring, and the structural integrity. Similarly, a thorough certificate review involves looking for weaknesses like poorly generated keys, improper configurations, and policy violations. Identifying these risks is the first step toward building a truly secure and resilient OT environment.

The following table highlights common certificate-related risks and explains why they pose a threat to your security posture.

The Risk	Why It Matters
Reused Identities	When the same certificate and private key are installed on multiple devices, the compromise of a single device effectively compromises every device sharing that identity. This dramatically expands the potential blast radius of an attack, allowing an intruder to impersonate numerous trusted assets at once.
Self-Signed Certificates	A self-signed certificate is one that vouches for its own identity without validation from a trusted third-party Certificate Authority (CA). This creates an unmanaged "island of trust." Attackers can easily introduce their own self-signed certificates to make rogue devices appear legitimate, completely bypassing your organization's security policies and trust infrastructure.
Excessively Long Validity Periods	Certificates with lifetimes spanning many years or even decades create a prolonged window of opportunity for compromise. Best practices dictate that keys should be rotated and certificates renewed regularly. This limits the time an undetected compromised key can be used by an attacker and ensures credentials stay fresh.
Weak or Poorly Generated Keys	Cryptographic keys must be generated with sufficient randomness (entropy). When keys are generated with poor entropy, they can be predictable and even duplicated across different devices. For RSA keys, this is often detected by finding a shared or factorable modulus. Such keys are brittle and can be broken with far less effort than a properly generated key, rendering encryption and authentication useless.
Certificates Issued Without Policy Enforcement	Devices may have certificates that were issued before modern security policies were put in place. These "grandfathered" credentials may not meet current standards for key length, algorithms, or extensions. Their trust is suspect, as they represent a gap in your security governance.
Overloaded Subject Alternative Names (SANs)	A single certificate can secure multiple identities (e.g., IP addresses, DNS names) via the SAN extension. However, a certificate with an excessive number of SANs can be a liability. If the device is compromised, its certificate could be used to impersonate a wide range of services, making it a powerful tool for an attacker moving laterally across the network.

Manually hunting for these issues across thousands of devices is an impossible task. Modern certificate risk intelligence tools can automate this discovery process, helping you categorize risk levels and prioritize remediation efforts to tackle the most critical vulnerabilities first.

Chapter 3: Segmentation

Separate IT and OT backbones

OT Networks need to operate independently of IT networks. By exposing OT networks to IT networks, attack surfaces increase. The types of attacks on IT networks differ from those on OT networks.

Attack Means on IT Networks

IT networks are often targeted through their connection to the internet and their large number of human users.

Phishing and Spear Phishing: This is a social engineering attack where an attacker sends a fraudulent email designed to trick a user into revealing credentials or deploying malware. Spear phishing is a more targeted version that uses personalized information to seem more legitimate.
Exploitation of Public-Facing Vulnerabilities: Attackers scan internet-facing systems like web servers, VPN endpoints, and remote desktops for known software vulnerabilities (CVEs). They then use publicly available exploit code to gain initial access to the network.
Credential Stuffing: After a data breach at one company, attackers take the leaked lists of usernames and passwords and systematically try them against the login portals of other companies. This attack relies on the common habit of password reuse.

Attack Means on OT Networks

OT networks are often attacked indirectly, using vectors that bypass traditional perimeter security.

Pivoting from a Compromised IT Network: This is the most common OT attack path. An attacker first gains a foothold in the corporate IT network (using one of the means above) and then moves laterally to the less-secure OT network, exploiting the trusted connections between them.
Infected Removable Media: A contractor or employee introduces malware into the OT environment by plugging in a compromised USB drive, laptop, or diagnostic tool. This was a key vector for spreading the Stuxnet worm.
Exploitation of Insecure Remote Access: Attackers compromise the credentials for a third-party vendor's remote access VPN. Using the vendor's legitimate, trusted connection, the attacker can bypass the firewall and directly access and manipulate sensitive industrial controllers and systems.

Therefore, segmenting the networks reduces the attack possibilities. For example, a typical non-segmented network looks like this:

After segmentation the network looks like this:

Notice that there is still communication between the OT and IT networks. However, that communication is limited to specific use cases by means of a Gateway or Firewall. This limits the sources and destinations allowed, the ports to be used, etc.

Separate legacy communications on OT networks

Further OT network segmentation is also required. Devices implementing protocols like Modbus (RTU or TCP/IP), Profibus, Profinet, and HART were not originally designed with modern security in mind. Therefore, it is critical to further segment the OT network to limit the attack surface.

Outlining an example is a PLC communicating to sensors and controllers for filtration and primary disinfection at a water treatment plant. This network segment is implemented at the plant. Due to the miles of distribution associated with water delivery and storage, remote secondary disinfection stations are also included in strategic locations. These stations also use PLCs communicating to sensors and controllers to control the level of secondary disinfection. However, both sets of systems communicate to the same SCADA system. The remote system communicates via telemetry back to the plant’s SCADA system. This looks like this:

Clearly the remote system is prone to attack, and may have a remote PLC using Modbus control. To get the telemetry back to the centralized system in a secure manner, Telemetry is used. However, that telemetry can be attacked. For example, the Free Chlorine signal can be spoofed. In this case, the residual Chlorine level can be made and recorded as in compliance while the remote control loop is told to introduce Chlorine at harmful levels.

A solution here is to use a VPN tunnel between the remote storage and the treatment plant. Securing this tunnel with x.509 certificates is a more appropriate solution than using a pre-shared key or secret.

While the remote infrastructure is easy to designate as requiring a secured connection, the same is true in a factory. In a non-distributed system, critical areas with insecure protocols should be isolated in their own subnets & firewalls placed between those subnets and the main data collection systems.

Chapter 4: Why Shared Trust is No Trust at All

Separate IT and OT Public Key Infrastructure (PKI)

Just as you separate your IT and OT networks, you must also separate their foundations of trust. A Public Key Infrastructure (PKI) is the system of Certificate Authorities (CAs) that issue and manage the digital certificates authenticating your devices. Many organizations make the critical mistake of using their corporate IT PKI to manage identities for OT devices.

This creates a single point of failure with catastrophic potential. Imagine a minor misconfiguration on an IT Issuing CA that results in a system-wide revocation. If that revocation event cascades into the OT network, it could instantly invalidate the identity certificates of every PLC, switch, and controller, bringing your entire operation to a halt.

IT and OT have fundamentally different requirements:

Certificate Lifespans: An IT web server certificate may last for 90 days. A PLC embedded in a factory wall may need a certificate that is valid for 10-20 years.
Protocols: IT CAs are built for standard protocols like SCEP and ACME. OT environments may require CAs capable of supporting specific industrial protocols or offline provisioning methods.
Risk Profile: The compromise of an IT certificate is a serious security incident. The compromise of an OT certificate could lead to a physical safety or environmental incident.

The solution is to establish a dedicated, often air-gapped, PKI for the OT environment. This creates a separate chain of trust, ensuring that a compromise or mistake in the IT world cannot impact critical operational systems.

Chapter 5: Raising the Bar on Security

Select the Right Vendors and Mandate Modern Security

You cannot easily add security features that a device fundamentally lacks. A proactive security posture begins at procurement. When evaluating new OT equipment, you must move beyond operational specifications and ask pointed questions about security capabilities.

Use the device categories from Chapter 1 as a guide. A device that falls into Category 1 (lacking native security) should only be chosen if there is no alternative, and you must have a clear plan for securing it with compensating controls. Ideally, you should prioritize vendors whose devices fall into Categories 5 and 6, demonstrating a commitment to modern, automated security.

Your Vendor Security Checklist:

Identity Management: Does the device support automated certificate enrollment protocols like SCEP, EST, ACME, or CMP? Can its identity be managed programmatically via an API? (See Chapter 1)
Secure Updates: Does the device require all firmware updates to be digitally signed? Can it verify that signature before installation to prevent malicious code from being loaded?
Secure Boot: Does the device implement a secure boot process? This ensures a hardware-based chain of trust, verifying that the firmware and software loaded at startup are authentic and have not been tampered with by malware.
CVE Notification: What is the vendor's formal process for notifying customers of Common Vulnerabilities and Exposures (CVEs) affecting their products? A vendor who is not transparent about vulnerabilities is a significant risk.
Algorithm Support: What set of cryptographic algorithms are supported for asymmetric encryption? Do they include modern types including advanced RSA, ECC, and PQC (Kyber &
Dilithium) in anticipation of post quantum computing emergence?

By making these features non-negotiable in your purchasing requirements, you shift the market toward more secure products and drastically reduce your long-term risk.

Chapter 6: From Chaos to Control

Achieve Visibility and Eliminate Rogue Trust

The final step is to bring all these principles together under a unified management strategy. The biggest remaining risks in many OT environments are the certificates you don't know about—specifically, self-signed certificates.

These certificates are created on the device itself, not by a trusted CA. They offer a veneer of encryption but no real trust. There is no way to verify who created them, and more importantly, no way to revoke them if they are compromised. An attacker who steals the private key from a device with a self-signed certificate can impersonate that device forever.

See and Secure Your Entire Cryptographic Landscape

This is where a Certificate Lifecycle Management (CLM) platform becomes essential. A modern CLM tool provides a single pane of glass to:

Discover: Continuously scan your entire network, integrating with the discovery tools mentioned in Chapter 1, to find every single certificate in use—whether it was issued by your new OT PKI or is a dangerous self-signed certificate.
Manage: Create a complete inventory of all keys and certificates, track their expiration dates, and enforce security policies.
Automate: Leverage software agents and automation protocols to systematically replace self-signed certificates with trusted ones from your dedicated OT PKI. It can automate the renewal process for all managed devices, eliminating both operational downtime from expired certificates and the security risks of using dangerously long-lived ones.

By centralizing control, you achieve crypto-agility—the ability to respond rapidly to a threat. If a vulnerability is discovered or a CA is compromised, you can use the platform to quickly identify and replace every affected certificate and key across your entire operational landscape, turning a potential disaster into a managed event.

Conclusion: A Proactive Approach to OT Security

Securing your operational technology is not a one-time project; it's a continuous process of maintaining visibility and control. The devices you don't see and the trust you can't manage represent the greatest risks to your organization.

By following the roadmap laid out in this guide, you can build a robust and resilient OT security program. It begins with a foundation of knowing and categorizing your devices. It is strengthened by segmenting your networks and separating your trust infrastructures. And it is maintained through intelligent vendor selection and the centralized, automated management of every device's identity.

This proactive approach allows you to move beyond reactive incident response and confidently secure the technology that runs your business.