Many factories still rely on equipment that has been running reliably for years: PLC, flow meters, power meters, weighing instruments, and industrial controllers that communicate through RS232 or RS485.
The equipment still works. The control logic is stable. So when manufacturers begin a digitalization project, replacing all of these devices is often unnecessary and expensive.
A more practical approach is to use aserial to ethernet adapterto connect legacy serial equipment to Ethernet networks, SCADA systems, MES platforms, or remote servers.
But this creates a new problem.
Many legacy devices were designed to communicate over a dedicated serial cable, not over an IP network that may span switches, routers, remote sites, or even the public Internet.
Their protocols may have no authentication, no encryption, and no way to determine whether a control command comes from an authorized engineer or an unknown host.
So the goal is not to make a 15-year-old PLC suddenly support modern cybersecurity features.
The goal is to build a secure boundary around it before its serial data enters the IP network.
This is the most important rule.
Public security research has found that large numbers of serial-to-Ethernet devices can be reached directly from the Internet. Even if the device itself does not have a public IP address, an attacker who gains access to the internal network may still be able to reach it.
For this reason, aserial to ethernet adaptershould normally be deployed inside a dedicated equipment network or OT network rather than connected directly to an office LAN or exposed through simple port forwarding.
A safer architecture looks like this:
PLC → Serial Device Server → OT VLAN → SCADA Server
Not:
PLC → Serial Device Server → Internet
If remote maintenance is required, users should first connect through a controlled remote-access environment before reaching the serial device server.
The main principle is simple: do not make a legacy serial device directly reachable from networks that do not need access to it.
During commissioning, engineers usually focus on basic connectivity:
Can the TCP connection be established?
Can Modbus data be received?
Can the SCADA system communicate with the device?
Once the system enters production, however, another question becomes more important:
Which hosts actually need access to this device?
For example, if an RS485 energy meter only needs to communicate with one energy management server, network policies should allow only that server to reach the required IP address and port.
An engineering workstation may need access to the configuration interface, but office PC, guest Wi-Fi devices, and unrelated production systems usually do not.
This is why network segmentation is important.
Serial device servers can be placed in a separate VLAN or subnet, while firewall or access-control rules restrict communication to approved hosts only.
This approach reduces the attack surface before any application-level security mechanism is considered.
A serial device server normally handles at least two types of communication.
The first is operational traffic: data coming from PLC, meters, controllers, or sensors.
The second is management traffic: Web configuration, parameter settings, firmware upgrades, and maintenance access.
These two traffic types should not automatically have the same access permissions.
Industrial security incidents have shown that management functions can become an attack path when attackers gain access to the network. Configuration interfaces, firmware functions, and device settings can all affect the availability of connected equipment.
A practical deployment strategy is therefore:
Allow the SCADA or application server to access the required data port.
Allow only authorized engineering workstations to access the management interface.
Default credentials should be changed, unnecessary network services should be disabled, and firmware updates should be reviewed when they become available.
For legacy-device projects, protecting the management plane is just as important as protecting the serial data itself.
If serial data stays completely inside an isolated production network, segmentation may be the first line of protection.
But when data must travel to a remote server, data center, or IoT platform, plain TCP transmission may not be enough.
Traditional RS232 and RS485 devices usually cannot encrypt their own traffic.
That means theserial to ethernet adapterbecomes a useful place to add transport security.
For example, the PUSR USR-N520 connects RS232/RS485 devices to TCP/IP networks and supports SSL/TLS encryption in TCP Client, HTTP Client, and MQTT operating modes. It also supports mutual certificate authentication.
The architecture can therefore look like this:
Legacy PLC → RS485 → USR-N520 → SSL/TLS → Server
The PLC continues using its original serial protocol.
No changes are required to the legacy device itself.
Instead, encryption and certificate-based authentication are introduced when the communication enters the IP network.
For manufacturers evaluating serial device servers, this is an important point.
Do not compare products only by the number of serial ports, baud rate, or Modbus conversion capabilities.
Also consider what security controls are available after the serial device becomes part of an IP network.
Security does not end when the serial connection starts working.
In many industrial applications, the expected communication pattern is actually very simple.
A device may normally communicate with only one SCADA server or one application server.
If it suddenly starts connecting to a new IP address, receives an unusual number of configuration requests, or shows unexpected command traffic, that behavior deserves investigation.
This is one of the advantages of monitoring networked serial equipment.
You do not necessarily need to modify the PLC program or replace the field instrument.
Instead, you can monitor network relationships around the device.
For example, you can check:
For legacy systems, this type of monitoring is often more practical than trying to add security features directly to old field equipment.
Keeping old PLC, meters, and controllers in service is not necessarily a problem.
The real risk appears when a device that was originally reachable only through a local RS485 or RS232 connection suddenly becomes accessible across an IP network.
That is why securing legacy serial equipment should follow a straightforward sequence:
Reduce exposure first. Restrict access second. Use encryption when data crosses untrusted networks. Then monitor for abnormal communication.
A serial device server should not be considered only as a tool for converting RS232 or RS485 to Ethernet.
For legacy industrial equipment, it also becomes part of the security boundary between the serial world and the IP network.
