A recurring theme in technical communities: aging business systems that cannot adopt modern single sign-on, so IT teams keep relying on traditional access methods, and credentials end up scattered across browsers. Factories face a harder version of the same problem — ten-year-old PLCs, discontinued SCADA software, meters that only speak serial. Firmware updates stopped years ago, and even changing a password requires a scheduled shutdown. The equipment cannot be replaced overnight, yet the risk still needs to come down. The workable direction is network segmentation: instead of fixing the legacy system's own vulnerabilities, wrap it inside a controlled network segment. Seen from the outside, a legacy system's exposure comes down to three surfaces: entry points, paths, and credentials. This article walks through each surface and what iot gateway devices can close off.
The common setup is familiar: to "check the data remotely", legacy devices get plugged into the office switch, and the office network connects to the Internet. Some sites go further and map public ports straight onto devices, leaving management pages visible to the entire Internet. Unpatched vulnerabilities in old firmware are left to hold this line on their own.
Closing off this surface starts with moving the legacy systems into a dedicated equipment segment — no direct Internet connection, no shared subnet with the office network. This step needs nothing more than switches and subnet planning; not a single line of configuration changes on the legacy systems, which makes it the cheapest move with the earliest payoff. All outbound communication is then concentrated on a single industrial gateway, whose firewall allows only the platform address and designated ports and rejects everything else. Once the segment is in place, the outside world no longer sees individual legacy devices — only the few ports the gateway chooses to expose.
After the equipment moves into its own segment, the second surface is the path. In the old flat network, office and production traffic shared one network, so a single compromised office PC gave an attacker a lateral route to the production line; one password leaked from a browser did not stop at the office network but reached the shop floor.
Two things happen at the gateway here. The first is protocol confinement: serial meters and legacy PLCs speak Modbus RTU, which the gateway converts to Modbus TCP or MQTT before anything leaves the segment. Between the legacy system and the gateway, only industrial protocols run, which keeps the attack surface small. The second is read/write separation: data keeps flowing to the cloud, while write operations to legacy devices are off by default, enabled per whitelist when needed, and logged for audit. The direction of traffic is the point — readings are allowed to travel out, but nothing on the outside gets to send commands in unless it matches a rule someone wrote down in advance. After this layer, the production line publishes data without accepting arbitrary commands from outside.
The third surface is the least visible and the most common in legacy environments. The systems themselves do not support modern authentication — many of them only offer a handful of local accounts, which is exactly why sharing one login among several people became the default in the first place. Passwords then live in browsers and remote-access tools on individual computers. When someone leaves the job, the account stays; when equipment rotates out, the old credentials are never revoked. Without control over credentials, the first two layers of segmentation can be undone by a single "legitimate" login.
Closing off this surface means centralizing both the access path and the credentials. All remote access goes through a VPN tunnel initiated by the gateway back to the platform or the operations side, with no ports exposed to the public Internet. Accounts and passwords are distributed and rotated centrally on the tunnel side, with no plaintext copies stored locally. When personnel change, revocation happens in one place, and login and configuration-change logs are collected for central audit.
Mapped to the three surfaces, the selection checklist reads: firewall and access control, plus VPN tunneling, for entry points and credentials; Modbus RTU/TCP conversion with common PLC protocols, plus read/write whitelisting, for paths; 4G or wired uplink options for the backhaul. The USR-M300 iot gateway device sits inside this range: a dual-core 1.2GHz processor running Linux; one RS232/485 port plus one RS485 port, one WAN/LAN port plus one LAN port, plus DI/DO/AI interfaces; parallel collection across serial, Ethernet, and I/O devices with up to 2,000 data collection points; Modbus RTU/TCP conversion; Node-RED graphical programming for building local data rules; dual 4G and wired uplinks with routing, VPN, and firewall support; wide-range power input, an operating temperature of -25 to 75 °C, and wall-mount or DIN-rail installation. On certification, beyond the standard 3C, CE, FCC, and ROHS items, the device has also passed the EU's EN 18031 cybersecurity standard — a baseline aimed specifically at the security of connected devices, which makes it a directly relevant reference point when the selection task is "using new equipment to protect old systems".
Replacement schedules exist; risk exposure does not wait for them. All three surfaces — entry points, paths, credentials — are addressed at the iot gateway devices layer: segment isolation and the firewall for entry points, protocol conversion and read/write separation for paths, VPN tunneling and centralized credentials for access. None of it requires any cooperation from the legacy systems themselves, which is exactly why a segmentation approach deploys quickly.
