Stop Treating OT Security Like an IT Problem: Configuration Is the Real Battlefield

We keep hearing that the answer to OT security is more technology—more firewalls, more monitoring, more magic boxes. That's wrong. The real problem isn't a lack of tools; it's a crisis of configuration. We've bolted security onto networks designed for reliability and uptime, not for defending against adversaries. And we're paying for it every time we read about another plant forced to shut down because someone left a default password in place or relied on a protocol that was never meant to carry secrets.

Stop Blaming the Protocol, Start Owning the Configuration

There's a comfortable narrative that our legacy protocols are inherently insecure and that the only way forward is to rip everything out and start fresh. But that's a cop-out. Modbus, developed in the late 1970s, and even newer industrial Ethernet standards like PROFINET and EtherNet/IP, were built for a different era—one where trust was assumed and physical access was the only real threat. Yet we continue to deploy them without a second thought, expecting them to secure themselves. The truth is, the protocol isn't the primary vulnerability; the way we configure and deploy it is.

Consider this: the ISA/IEC 62443 series, the international standard for industrial automation and control systems security, doesn't just list technical controls. It defines requirements and processes for implementing and maintaining secure systems, explicitly bridging the gap between operations technology and IT, and between process safety and cybersecurity (ISA/IEC 62443). That's a direct acknowledgment that security is a matter of deliberate configuration and ongoing management, not a bolt-on feature. And NIST SP 800-82 Rev. 3, the guide to OT security, provides detailed guidance on securing industrial control systems, SCADA, DCS, and PLCs—again, not by recommending a single product, but by outlining a process of secure design, configuration, and maintenance (NIST SP 800-82 Rev. 3).

We see the consequences of ignoring this in the real world. CISA's advisories on industrial control systems are blunt: exploitation of vulnerabilities can lead to data corruption, exfiltration, or even significant physical consequences (CISA Industrial Control Systems). And their Secure by Demand guidance for OT specifically warns that threat actors exploit weak authentication, insecure settings, and outdated protocols—and recommends procuring products that support open standards, secure configurations, data protection, and strong authentication (CISA Industrial Control Systems). That's not a call for new protocols; it's a call for better configuration and procurement choices.

Security Is Not a Feature, It's a Configuration Discipline

Here's the thesis we need to defend: the most impactful thing we can do for OT security is to treat every device on our network as a deliberate configuration decision. That means knowing exactly what each device is, what it's supposed to do, and how it's allowed to communicate. It means applying the principle of least privilege not just to users, but to devices and protocols. It means segmenting our networks so that a compromised sensor can't reach the PLC that controls a valve. And it means enforcing strong authentication everywhere, not just at the perimeter.

We can do this today with the technology we already have. The ISA/IEC 62443 series provides a framework for exactly this kind of disciplined approach. It sets cybersecurity benchmarks for all industries that use industrial automation and control systems—from building automation to electric power generation, from medical devices to chemical plants (ISA/IEC 62443). That's not a niche standard; it's a horizontal standard recognized by the IEC in 2021, with use cases in more than 20 industries and endorsed by the United Nations (ISA/IEC 62443). If we don't adopt it, we're ignoring a proven methodology.

And for those who think we need to adopt new protocols to be secure, consider MQTT. It's a lightweight publish/subscribe messaging transport standardized in ISO/IEC 20922:2016, designed for constrained machine-to-machine and IoT environments (ISO/IEC 20922 MQTT Standard). It supports TLS encryption and client authentication via protocols like OAuth (MQTT.org). It's a modern protocol that can be used for secure data transport between OT and IT. But MQTT alone doesn't secure a network. If you deploy MQTT with default credentials and no access controls, you're just moving the problem. The protocol is a tool; the configuration is the discipline.

The Counter-Argument: “But We Need to Modernize”

Some will argue that our legacy systems are simply too old and too insecure to be fixed by configuration alone, and that we must rip and replace with modern protocols and architectures. That's a fair point—there are cases where a device is so outdated that it cannot be secured, and the only option is replacement. But that's not the situation for the vast majority of our networks. The industrial automation market is massive—valued at about $184.43 billion in 2025 and projected to reach $326.48 billion by 2032 (Maximize Market Research). Hardware makes up 50% to 60% of that market (Maximize Market Research). That means we have a huge installed base of devices that are not going away anytime soon. We can't wait for a greenfield project to secure our plant.

Furthermore, the counter-argument often ignores the fact that even modern protocols require secure configuration. OPC UA, for instance, is a vendor-neutral standard with built-in encryption and authentication, designed to be the backbone for IIoT and IT/OT integration (OPC Foundation). It's a great step forward. But if you deploy OPC UA without properly managing certificates and user roles, you're still exposed. The same applies to PROFINET and EtherNet/IP—they have security features, but they're only effective if configured correctly. So the argument that we need to modernize to be secure is really an argument that we need to configure any technology we use properly.

We also need to address the misconception that security is an IT problem. IT and OT have different priorities: IT focuses on confidentiality, integrity, and availability (in that order), while OT often prioritizes availability, safety, and integrity. The ISA/IEC 62443 standard explicitly bridges this gap (ISA/IEC 62443). We can't simply apply IT security policies to OT environments without adaptation. We need OT-specific guidance, and we have it—NIST SP 800-82 Rev. 3 is a prime example (NIST SP 800-82 Rev. 3). The challenge is that too many organizations don't have the expertise or the budget to implement these standards properly. But that's a management failure, not a technology failure.

Configuration Is a Continuous Process, Not a One-Time Project

One of the biggest mistakes we make is treating security as a project with a start and end date. We deploy a firewall, we patch a few systems, and we think we're done. But configuration is not a static state; it's a continuous process. As our networks evolve—new devices added, old ones removed, processes changed—we must re-evaluate our configurations. The ISA/IEC 62443 series emphasizes this by defining requirements for asset owners, product suppliers, integrators, and service suppliers, all of whom have ongoing responsibilities (ISA/IEC 62443). It's not a one-and-done checklist.

Let's be concrete. Imagine a mid-sized manufacturing plant with a mix of legacy Modbus serial devices and newer PROFINET equipment. The plant has a SCADA system that aggregates data via OPC UA. A well-meaning engineer decides to connect a new IIoT sensor to the network to monitor vibration on a critical pump. Without proper configuration, that sensor could be accessible from the corporate network, and its data could be intercepted or spoofed. But if the plant has a clear policy for device onboarding, network segmentation, and authentication, that sensor is just another node on a secure network. The difference is not the sensor; it's the configuration.

The same principle applies to the protocols we choose. We don't need to abandon Modbus or PROFINET; we need to deploy them with security in mind. For example, we can put Modbus TCP behind a firewall, restrict access to specific IP addresses, and use a secure gateway for remote access. We can use EtherNet/IP's CIP security features if we enable them. We can use PROFINET's authentication mechanisms. The point is that every protocol has a security posture, and it's up to us to configure it properly.

So, what is the single most important thing to remember? Security is not a product you buy; it's a discipline you practice. Every device, every protocol, every connection is a configuration decision. Own it, or be owned by it.

Sources

• OPC Foundation - https://opcfoundation.org/
• ISA/IEC 62443 - https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards
• NIST SP 800-82 Rev. 3 - https://csrc.nist.gov/pubs/sp/800/82/r3/final
• CISA Industrial Control Systems - https://www.cisa.gov/topics/industrial-control-systems
• ISO/IEC 20922 MQTT Standard - https://www.iso.org/standard/69466.html
• MQTT.org - https://mqtt.org/
• Maximize Market Research - https://www.maximizemarketresearch.com/