Articles

Your Legacy PLCs Were Never Built for This

How network segmentation protects the devices that can't protect themselves

 

You have a Modbus PLC that's been running a process for 15 years. It does its job and does it well.

But it has no authentication, encryption, or firewall. And now someone up the corporate ladder wants the data from that PLC for the ERP system, the historian, or a cloud analytics dashboard. IT won't put that device anywhere near the corporate network, and they're right. But the data still has to move.

That PLC was never designed to live on an untrusted network or to be exposed to the internet. Neither were the dozens of other legacy Ethernet devices on your plant floor, such as remote terminal units (RTUs), variable frequency drives with Ethernet ports, and older HMIs. They were designed for isolated process networks where the biggest threat was someone unplugging the wrong cable.

But the business needs the data they produce, and not connecting them is no longer an option.

That's the core tension driving network segmentation in industrial automation: the data must flow upstream, but the devices that produce it can't be exposed. You need to get data off the plant floor without turning every legacy device into an attack surface.

Your legacy devices are already a target

If this were a theoretical risk, you could file it under "someday." It's not.

In 2025, the Cybersecurity & Infrastructure Security Agency (CISA) published 508 Industrial Control Systems (ICS) advisories covering 2,155 individual vulnerabilities across products from Rockwell Automation®, Siemens®, Schneider Electric®, Mitsubishi Electric®, and others [1]. The number of internet-exposed ICS devices rose by ~13% between 2024 and 2025 and will keep growing [2]. State-linked groups and hacktivists exploited new ICS vulnerabilities within weeks of disclosure [1].

But only 22% of ICS vulnerabilities received a formal CISA advisory last year—down from 58% in 2024 [1]. The coverage gap is widening. You can't rely on someone else flagging the risk for you.

Legacy devices are the softest targets in this environment. They have no built-in defenses. They can't be patched. Many of them run protocols like Modbus®/TCP that transmit data in cleartext with no authentication. If they're reachable from an untrusted network, they're exposed.

So how do you protect devices that can't protect themselves? Network segmentation. And the industry standard framework for doing it is IEC 62443.

Zones and conduits: IEC 62443 in plain language

IEC 62443 is the international standard for cybersecurity in industrial automation and control systems. It's a large, multi-part standard, but for network segmentation, two concepts matter most: zones and conduits.

A zone is a group of assets that share common security requirements. You draw a boundary around them and enforce a consistent security policy within that boundary. A trusted OT network with your PLCs and I/O devices is a zone. Your corporate IT network is a different zone. A DMZ (demilitarized zone) between them might be a third.

A conduit is a controlled communication path between zones. It defines what traffic can pass between two zones, under what conditions, and with what level of authentication and encryption. Think of zones as rooms in a building and conduits as the doors between them. Each door has its own lock, its own access list, and you don't leave every door open all the time. Some doors you unlock only when someone needs to walk through, then lock again behind them.

The standard also defines four security levels—from SL1 (protection against unintentional misuse) up to SL4 (protection against sophisticated, well-resourced attacks). Each zone gets assigned a target security level based on a risk assessment, and the conduits connecting it to other zones must enforce that level.

The 2025 updates to IEC 62443 push further into microsegmentation—more granular control at and below security layer 3, in environments that mix TCP/IP with legacy non-IP protocols. Coarser segmentation isn't enough anymore.

IEC 62443 tells you what to do—separate assets into zones based on their security requirements, and control the conduits between them. The how depends on your equipment choices, and that's where the differences between industrial controllers become significant.

 

How most controllers handle segmentation today

Most industrial controllers approach network segmentation in one of two ways. Both work. Both have trade-offs.

The external infrastructure approach. In this model, the controller is a single-network device. Segmentation happens around it, through managed switches, VLANs, external firewalls, and deep packet inspection (DPI) appliances. Rockwell Automation's architecture is a good example. ControlLogix® uses separate ENxT communication modules on the backplane to bridge traffic between networks. To segment Level 0/1 I/O traffic from Level 2 information traffic, Rockwell recommends deploying a DPI-capable firewall between zones. The controller doesn't do the segmentation; the infrastructure around it does.

This works, but it means you're buying, configuring, and maintaining a stack of networking gear at every control node. The controller itself has no opinion about which network is trusted and which isn't.

The dual-interface-plus-appliances approach. Some controllers offer two physical Ethernet interfaces with no routing between them, which gives you basic zone separation at the device level. Siemens' S7-1500 is a good example: a multi-homed CPU with dual interfaces that are isolated by default. That's architecturally sound.

But more advanced security features—such as configurable firewall rules, VPN termination, and deep packet inspection—require separate SCALANCE® security appliances. The PLC handles basic network separation; a separate box handles the security policy. For complex topologies or untrusted external connections, Siemens recommends adding a SCALANCE S615 security router.

Both approaches implement the IEC 62443 zone and conduit model. Both require additional hardware beyond the controller itself to get there. The question is whether there's a way to consolidate more of the segmentation architecture into the controller—fewer boxes, fewer configurations, fewer things to manage and patch.
 

Segmentation built into the controller

Opto 22's groov EPIC® and groov RIO® edge controllers and I/O take a different approach. Instead of relying on external infrastructure to create zones and conduits, the segmentation architecture is built into the device itself, in four ways:

Dual independent network interfaces: physical zone separation

groov EPIC includes two independent Gigabit Ethernet interfaces, each with its own IP address. ETH0 connects to your trusted OT network, where your PLCs, I/O, and field devices live. ETH1 connects to the untrusted network—IT, the internet, and cloud services. There's no default routing between them. The device keeps the two networks apart.

groov RIO matches this capability. With firmware 4.1.0 and higher, you can configure RIO's two Ethernet ports as independent, segmented interfaces—the same architecture as EPIC. Both products handle segmented networking the same way.

Add an optional WiFi adapter and an OpenVPN tunnel, and a single groov device can separate up to four network zones.

Per-application configurable firewall

In groov Manage, the browser-based software tool for commissioning groov EPIC and groov RIO, you configure firewall settings separately for each application and its associated ports. For example, you can enable or disable the Modbus/TCP server on port 502 for each network interface (ETH0, ETH1, VPN, WiFi).

On the trusted interface (ETH0), you keep the necessary industrial application ports open—Modbus/TCP, OptoMMP, PAC Control™ or CODESYS® control programming—because the devices on this network need to communicate using these applications.

On the untrusted interface (ETH1), only port 443 (HTTPS) opens by default. Everything else stays blocked. Authenticated, encrypted connections to groov Manage, groov View® HMI, Node-RED, and RESTful APIs come through that single secure port. groov denies unsecure protocols like Modbus/TCP on the untrusted interface.

You can view and modify the firewall configuration for each interface and application directly in groov Manage. Close ports you're not using. Open specific ports only on the interfaces that need them. The configuration is visible and auditable—not buried in command lines or spread across multiple devices.

Port redirect: on-demand conduits between zones

Sometimes you need a controlled path between zones for a specific purpose. Maybe you need to reach a legacy PLC on the trusted OT network from a remote VPN connection to update its program. IEC 62443 calls this a conduit, and groov devices implement it through port redirect.

With port redirect, you forward traffic arriving on one interface's network port to an IP address and port on another interface. You create a conduit between zones: in this example, from the VPN tunnel interface to the trusted network where the legacy PLC sits.

Enable it only when you need it. Disable it when you're done. You can configure port redirects directly in groov Manage or programmatically through the REST API, Node-RED, or Ignition Edge®. These conduits are temporary and auditable—exactly what IEC 62443 calls for.

Device-originated connections: a unifying security principle

Two of groov's most important networking features—MQTT and the built-in OpenVPN client—both follow a key security principle: the groov device initiates outbound connections. The device requires no inbound ports.

MQTT handles data. Your groov device publishes data outbound to an MQTT broker—authenticated, encrypted, device-originated. The broker can run on premises, in the cloud, or wherever the data needs to go. Because the connection is outbound, you don't need to open any inbound ports on the groov device or punch holes in your firewall. Compare that with poll-based architectures, where upstream systems reach into the OT network to pull data—every poll requires an open inbound port. That's your attack surface growing.

The built-in OpenVPN client handles access. The groov device initiates an authenticated, encrypted tunnel outbound to a VPN server. Remote users connect through the VPN server to access applications on the EPIC or RIO—including applications that don't support secure communication on their own, such as PAC Control. You get authenticated remote access without opening any ports on the device itself.

The principle is the same in both cases: outbound, device-originated connections are more secure, because the device controls when and where the connection is made. No listening ports means no attack surface for unsolicited inbound traffic. As shown below left, outbound connections are more secure because the device is in control. Below right shows the opposite: allowing inbound traffic opens the device to attacks.
This security principle is also key outside the field of automation. For example, Starlink® terminals have no public-facing, routable IP address—inbound connections are impossible. Many cellular carriers now put subscribers behind carrier-grade Network Address Translation (NAT) with no path for unsolicited inbound traffic. If your remote sites depend on satellite or cellular links, device-originated outbound connections are the only option.

Protecting the devices that can't protect themselves

With network segmentation built into the controller, legacy devices are more easily made secure while their data is made available. Your legacy Modbus PLC—the one with no authentication, no encryption, and no firewall—remains on the trusted OT network, connected to groov EPIC or groov RIO's ETH0 interface. It's never exposed to the IT network or the internet. It doesn't need to be.

The groov device handles the security boundary. The per-application firewall blocks unsolicited traffic from the untrusted side. MQTT publishes the PLC's data outbound to wherever it needs to go—no inbound ports, no direct access to the OT network. If you need to update the PLC's program, you connect via VPN, open a temporary port redirect conduit to the PLC's address on the trusted network, and close it when you're done.

The legacy PLC stays exactly as it is. The architecture protecting it changes. And the device providing that architecture—the zoning, the firewall, the VPN, the conduits, the secure data transport—is the same device that's also running your control program, your HMI, and your edge applications.

A practical segmented architecture

Imagine a manufacturing site with multiple OT zones: legacy PLCs and drives on one, groov RIO remote I/O modules on another, each connected to the groov EPIC's ETH0 interface, which faces the trusted OT network where these devices live. ETH1 faces the untrusted IT network and potentially the internet for upstream data delivery.

Data moves upstream through MQTT. Each groov EPIC and RIO publishes process data outbound via MQTT/Sparkplug B to a broker on premises or in the cloud. Historians like Canary®, SCADA platforms like Inductive Automation®’s Ignition®, and cloud analytics services like Amazon Web Services® (AWS) all subscribe to that data. No groov device opens inbound ports. No upstream system reaches into the OT network to pull data.

Remote engineers connect through OpenVPN. A technician who needs to update a PLC program at the site connects to the VPN server, reaches the groov EPIC's applications through the VPN tunnel, and—if they need direct access to a legacy PLC—uses a port redirect conduit they enable for the duration of the maintenance window and close when the work is done.

You manage user access on the device through groov Manage. Each groov EPIC and RIO has local account management with user authentication and permissions-based access, and can integrate with your corporate LDAP server for centralized authentication. You configure session timeouts, account lockouts, and password policies per device. groov Manage handles security certificates on-device.

The groov device implements every layer of this architecture—zoning, firewall, conduits, data transport, remote access, user management, certificate handling. No external security appliances. No additional managed switches for segmentation. No separate VPN concentrators. The controller is the segmentation architecture.

Where to start

Network segmentation is a design principle you apply to every system you build or retrofit. You don't have to segment your entire plant at once. Start where the risk is highest: the points where unsecure legacy devices meet upstream networks that need their data.

Put a security boundary between those legacy devices and everything upstream. Give the data a secure path out—outbound, encrypted, device-originated—and keep the devices themselves isolated from traffic they were never designed to handle.

If you're designing a new system, build segmentation in from the start. If you're retrofitting an existing one, the right edge device can add zone separation and secure data transport without replacing the equipment that's already working.

For a deeper dive into the cybersecurity features built into groov EPIC and groov RIO, read the full technical note: groov Products Cybersecurity Design and Best Practices.

To explore how segmented networking applies to your specific application, talk to an Opto 22 engineer.

 

Sources:

[1] Forescout, "ICS Cybersecurity in 2026: Vulnerabilities and the Path Forward," https://www.forescout.com/blog/ics-cybersecurity-in-2026-vulnerabilities-and-the-path-forward/ — Primary source for the 508 advisories / 2,155 CVEs, 22% CISA coverage gap, and threat actor exploitation timeline statistics.

[2] BitSight, "The Growing Exposure of ICS/OT Devices," https://www.bitsight.com/blog/the-growing-exposure-of-ics-ot-devices — Research on internet-exposed ICS/OT device growth trends.


About Opto 22 Products

Opto 22 industrial automation products include the latest groov EPIC edge programmable industrial controllers and groov RIO edge I/O, as well as field-proven legacy products like SNAP PAC and solid state relays (SSRs).

With groov products, you can collect, process, view, and exchange data where it's produced—at the edge of the network—and securely share data among databases, cloud platforms, web services, PLC systems, and other systems and equipment. groov products give you built-in cybersecurity and multiple control programming options including CODESYS, plus Node-RED, Inductive Automation's Ignition Edge, and MQTT communications.

Opto 22 products are ideal for OEMs and machine designers, process control, machine monitoring, power and energy monitoring, predictive maintenance, remote installations like water-wastewater and oil & gas, SCADA, and industrial internet of things (IIoT) applications. 

Join us at industry events.


Built for the future, with experience from the past

For over 50 years customers like you have counted on Opto 22's reliable, open standards-based products for industrial automation, remote monitoring, and data acquisition. We offer a unique product philosophy: Here Today, Here Tomorrow. That means:

  • We design new products for the long term, with features you’ll need tomorrow.
  • We provide upgrade paths, so your existing systems will work with new ones. 
  • We keep building older products as long as we can find required components. 
  • And we support all our products for FREE as long as you have them.
Learn more about Opto 22
See what customers say about Opto 22
   
   
   

Questions? Contact an Opto 22 engineer. 

  • No bots, just real people
  • ​Call us at 800-321-0PTO
  • Chat now or complete a contact form

 

Order your groov edge device!