Stop Buying Unsecured Industrial Switches: Demand 62443 Now

Imagine you are a plant manager at a mid-sized automotive parts manufacturer. One Monday morning, you walk in to find the assembly line frozen—not because of a mechanical fault, but because a ransomware attack has encrypted the PLCs controlling the robotic welders. The IT team is scrambling, but they can't even see the OT network. This scenario is not hypothetical. It's the reality for too many factories that have layered modern IT connectivity onto legacy industrial protocols that were never designed with security in mind.

I've spent years in this industry, and I've seen the same mistake repeated: buying the cheapest switch, the fastest controller, the most popular protocol—without a single security requirement in the RFP. We treat industrial networking as if it's still 1995, when the biggest threat was a loose wire. But the threat landscape has changed, and our approach must change with it.

The Legacy Protocol Trap

Let's be blunt: the protocols we rely on are old. Modbus, developed in the late 1970s, uses a master-slave model and transmits data in cleartext with no authentication (OPC Foundation). PROFIBUS, a serial fieldbus, is equally unencrypted. Even EtherNet/IP, which runs the Common Industrial Protocol (CIP) over standard Ethernet and TCP/IP, doesn't include security by default—it's only secure if you specifically implement CIP Security, which adds encryption and authentication (ODVA EtherNet/IP). These protocols were built for reliability and real-time performance, not for defending against malicious actors. And yet, we continue to install them in brownfield and greenfield sites alike, often with no security layer at all.

The result? As CISA notes, many legacy ICS devices continue to use outdated operating systems and older protocols that lack encryption or authentication (CISA Industrial Control Systems). This is a recipe for disaster.

The Security Standards We Already Have

But here's the thing: we don't need to reinvent the wheel. We have robust standards—if we choose to use them. The ISA/IEC 62443 series is the gold standard for industrial automation and control systems (IACS) cybersecurity. It defines requirements for asset owners, product suppliers, integrators, and service providers, and it's endorsed by the United Nations (ISA/IEC 62443). NIST SP 800-82 Rev. 3 provides guidance for securing operational technology, and CISA offers a Known Exploited Vulnerabilities catalog to prioritize patching (CISA Industrial Control Systems). These aren't theoretical documents; they're practical frameworks that can be applied today.

Yet, when was the last time you saw a datasheet for a PLC or an industrial switch that bragged about its 62443 compliance? Exactly. It's rare, because buyers don't ask for it. We're stuck in a cycle: vendors don't offer security because we don't demand it, and we don't demand it because we assume it's not possible.

The Counter-Argument: Performance vs. Security

I know what the skeptics will say: “Security will slow down my motion control or break my real-time communication.” And they have a point—at least for some protocols. Take EtherCAT, which achieves cycle times of ≤100 µs and synchronization jitter of ≤1 µs (EtherCAT Technology Group). Adding encryption to that data stream could introduce latency that disrupts production. Similarly, Sercos offers synchronization accuracy well below 1 µs over Fast Ethernet (Sercos International). These are hard real-time systems where every microsecond counts.

But that's an excuse, not a justification. For one thing, not every device on your network needs that level of performance. The sensors monitoring temperature or the HMIs displaying dashboards don't require sub-microsecond jitter. And modern security measures like CIP Security can be selectively applied to non-real-time communications while leaving the time-critical data on a separate, secure VLAN (ODVA EtherNet/IP). Moreover, the ISA/IEC 62443 standard explicitly addresses the need to segment networks and protect the most critical functions without sacrificing performance (ISA/IEC 62443). So yes, you can have both—if you design it properly.

What Procurements Must Change

Here's my specific recommendation: make ISA/IEC 62443 compliance a mandatory requirement in every RFQ for industrial networking equipment, from sensors to controllers to switches. And don't accept a vague “we follow best practices” response. Ask for a Statement of Applicability (SOA) that lists which 62443-3-3 requirements are met. Demand that CIP Security be enabled on EtherNet/IP devices, or that MQTT connections use TLS and OAuth (MQTT.org). And for brownfield sites, where you can't replace everything overnight, at least deploy a demilitarized zone (DMZ) between the IT and OT networks, and use OPC UA or MQTT for secure data extraction to the cloud, as both protocols support encryption (OPC Foundation; MQTT.org).

I'm not saying it's easy. Some legacy protocols, like Modbus, simply cannot be made secure without a gateway or a wrapper. But that's no excuse to ignore security for new installations. The market is already moving: the global industrial automation market is projected to reach $326.48 billion by 2032 (Maximize Market Research), and the IIoT market is growing at a CAGR of 12.2% (Maximize Market Research). With that growth comes more connectivity, and more connectivity means more attack surface. If we don't set the bar now, we'll be paying for it later.

Some might argue that this is overkill, that we're overreacting to rare attacks. But CISA's Known Exploited Vulnerabilities catalog is a stark reminder that attackers are actively exploiting ICS vulnerabilities, and the consequences can be physical, not just financial (CISA Industrial Control Systems). We can't afford to be complacent.

What I'd Actually Do

If I were specifying a new automation line today, I would insist on the following, in order:

• Mandate ISA/IEC 62443 compliance for all new equipment.
• For EtherNet/IP networks, require CIP Security to be enabled.
• For remote monitoring and cloud connectivity, use OPC UA or MQTT with TLS and client authentication.
• Segregate real-time and non-real-time traffic using VLANs or a DMZ.
• Conduct a security assessment using NIST SP 800-82 Rev. 3 as a guide.

And I would walk away from any vendor that can't demonstrate 62443 compliance. It's not about being paranoid; it's about being professional. The cost of a breach—downtime, reputational damage, potential lawsuits—far outweighs the cost of secure equipment. The standards exist. Let's use them.

Sources

• OPC Foundation - https://opcfoundation.org/
• ODVA EtherNet/IP - https://www.odva.org/technology-standards/key-technologies/EtherNet-ip/
• 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
• EtherCAT Technology Group - https://www.ethercat.org/en/technology.html
• MQTT.org - https://mqtt.org/