Serial servers let serial data from meters, instruments, or PLCs enter Ethernet, but “being able to connect to the network” does not mean “already secure.” A reliable solution must answer three questions at the same time: who can connect to the device, whether the link the data passes through needs encryption, and whether problems can be discovered in time and safely recovered. You cannot just set a password, and you cannot assume that because a device says “industrial grade” it can automatically resist network attacks.
1. First understand how the data actually travels
Suppose a meter outputs readings via RS485. RS485 specifies how electrical signals travel on wires; it is not responsible for verifying network user identity. After the serial server receives serial bytes, it sends them into a TCP or UDP connection according to the configured framing conditions, and the host computer then interprets the readings according to the meter’s application protocol. Transparent transmission usually moves bytes; it does not judge whether each command is suitable to execute. Read requests and parameter modification commands may enter field devices along the same channel.
TCP can help the receiver obtain bytes in order, but it does not automatically turn the content into ciphertext. A device’s login password usually protects the management interface, and it does not mean business data is already encrypted. The serial side, the field LAN, the cross-plant link, and the platform entrance should each be checked separately: one segment being protected does not mean the entire path is secure. First draw the actual link, list the devices, ports, communication directions, and management entrances clearly, and then you will know where protection should be placed.

2. Separate the threats so the measures match
Eavesdropping is when others see data they should not see; unauthorized control is when someone without permission sends commands to a device; resource exhaustion may come from too many connections, abnormal requests, or incorrect retries, making normal collection impossible. There is also an easily overlooked situation: authorized personnel mistakenly changing the baud rate, device address, or network mode can also cause communication interruption. Security must prevent malicious behavior and also constrain operational mistakes.
Therefore, confidentiality, identity verification, operation permissions, and availability cannot replace one another. Encryption can reduce the risk of the link being eavesdropped, but it cannot stop someone who has already been allowed into the system from mistakenly sending commands. Access whitelists limit entrances, but they cannot guarantee that an allowed computer is not infected. Connection count limits can help avoid resources being exhausted, but they cannot replace network segmentation. Every measure has boundaries and needs to be used in combination.
3. First narrow the entrances, then assign least privilege
Do not directly expose the serial server’s business ports and management page to the public network. Field collection devices should be placed in a clearly defined industrial network area, separated from office terminals and guest wireless networks. VLANs can divide logical networks, but cross-area access still needs policies enforced by routing, firewalls, or other access control devices; only dividing VLANs without restricting cross-area traffic does not complete isolation.
Access rules should be written as “the specified collection host accesses the necessary ports of the specified device” rather than allowing the entire network segment to access freely. IP whitelists help, but an IP address is not a person’s identity and cannot replace account authentication. Management entrances should be limited to the operations area, using independent accounts and sufficiently strong passwords; when the device supports role division, separate read-only viewing, configuration modification, and upgrade permissions. Close unused services, keep change records, and revoke permissions promptly after employees leave or outsourcing ends.
4. Encrypted channels must clearly state the scope of protection
TLS is a secure communication protocol, not a single encryption algorithm alongside AES. A correctly implemented TLS combines identity verification, key negotiation, and authenticated encryption to protect the connection. Whether TLS is supported, which versions are supported, and how certificates are verified all need to be checked for the specific model, firmware, and application software. Using HTTPS for web login does not mean another TCP business port automatically uses TLS.
If the serial server itself does not have a confirmed secure business channel, a suitable VPN gateway can be used at the network boundary to protect cross-plant connections. VPN encapsulates the original network data into a protected channel, and the gateways at both ends encrypt and decrypt. It protects the segment covered by the tunnel; the serial wires, the LANs before and after the gateway, and platform accounts still need separate protection. The gateway also cannot therefore open unlimited access to all internal devices.

During deployment, the peer identity must be verified, and certificate verification cannot be skipped for a long time just to eliminate errors. Keys and certificates should have storage, update, and revocation processes, and fixed keys for all devices should not be written into public configuration files. Encryption also adds processing overhead or encapsulation overhead, so collection cycles, timeouts, and reconnection after disconnection need to be verified on site; you cannot only check “connection successful.” Control-type services also need to check state handling after reconnection to avoid repeated execution of incorrect commands.
5. Why CRC is not an anti-tampering tool
CRC is a checksum method used to detect transmission errors, suitable for checking data changes caused by noise or line problems. But if an attacker can change the data, they can usually also recalculate the corresponding CRC. Therefore, a correct CRC does not mean the data comes from a trusted device, and even less does it mean it has not been maliciously modified. Cryptographic message authentication requires a key to participate, making it difficult for someone without the key to forge a valid result; its role is different from ordinary error checking.
Simply XORing the original data with a fixed number should also not be treated as a reliable security solution. Algorithm names, key lengths, or “self-developed encryption” claims cannot replace protocol design and implementation review. Prefer mature secure channels with clear maintenance mechanisms and verifiable implementation methods; do not assemble encryption and checksums yourself to protect important control commands. Beyond encryption, business systems should still check command permissions, ranges, and abnormal values.
6. How Feichang products fit into such a solution
The FCT-081219 lipstick-style industrial rail-mounted serial server on the Feichang official website supports one channel of optional RS232, RS422, or RS485 access to 100 Mbps Ethernet, and provides functions such as WEB configuration, SNMP management, access control, and firmware upgrade. These capabilities respectively help with field access, centralized configuration, and device maintenance; the small size and rail or wall mounting make it convenient to arrange space inside cabinets. They are networking and management capabilities, and cannot directly lead to the conclusion that all cryptographic security functions are present.
The product details currently checked do not explicitly list business TLS, certificate authentication, or VPN termination capabilities, so this article does not write these capabilities as established functions of this model. During selection, confirm with Feichang the ordered model, firmware version, specific granularity of access control, and services that can be disabled, and then decide whether to pair it with an external security gateway. Electrical protection, environmental adaptability, and network security are different issues; lightning protection or wide-temperature specifications cannot replace proof of a secure channel.
7. Start acceptance from a small system
For example, a hypothetical plant wants to send readings from several meters to a remote collection platform. First record the serial parameters, device addresses, and collection cycle, confirm locally that readings are stable, and then restrict access to the business port to only the collection host. The management interface is for the operations area only. The cross-plant part is transmitted through an authenticated secure channel and limited to the targets actually needed; do not disable all firewalls just for troubleshooting, and do not open all ports.
Acceptance should separately test that authorized connections can collect normally, unauthorized connections are rejected, recovery after a normal disconnection is controllable, and management changes leave records. Tests should use maintenance windows and authorized devices; high-intensity scanning or denial-of-service tests must not be run arbitrarily on the production network. Check abnormal connections, login failures, and collection timeouts. When device logs are insufficient, combine gateway, switch, and host computer records, and keep times as unified as possible to make it easier to trace the same event.
Finally, back up the configuration and record the firmware version, upgrade source, and rollback steps. Verify patches in an appropriate environment first, then schedule a window for upgrading. The emergency process should state who has the authority to isolate devices, how to maintain critical business, and when to restore connections; do not treat “unplug everything” as a standard action suitable for all sites. The core of secure serial networking is not adding a lock icon, but implementing identity, links, permissions, and recovery responsibilities on the actual data path.
Translated from the Chinese technical article. Source first published: 2025-02-18. Source last revised: 2026-10-13T19:28:50+08:00. Read the Chinese source

