Industrial Switch and Serial Gateway Hardening Guide: Access, Protocols and Patching

Industrial Ethernet switches and serial-to-Ethernet device servers sit between control equipment and every network above it, yet they are often installed with factory credentials, every management service enabled and no logging at all. A serial device server (for example a Moxa NPort, a Lantronix EDS or a Digi unit) turns RS-232/422/485 devices into network endpoints, and an industrial switch (for example Moxa EDS, Hirschmann HiOS-based or Cisco IE models) carries the control traffic. Compromise either and an attacker can read, inject or block process data. This guide sets out a vendor-neutral hardening baseline, covering management access, accounts, integrations, logging and physical interfaces, using the vendors' own advisories and hardening material as anchors. It is written for OT network engineers, control system integrators and security teams responsible for plant networks.

Key takeaways

• These devices are exposed edge, even inside the plant. CISA, FBI, EPA and DOE list removing OT connections from the public internet and changing default passwords as the first two primary mitigations for OT, and both apply directly to switches and serial servers.
• Management is the attack surface. Web consoles, Telnet, SNMP, vendor discovery utilities and serial console ports are how these devices are taken over; disable what you do not use and restrict the rest to a management network.
• Some vulnerabilities have no patch. Moxa's advisory MPSA-257331 (CVE-2025-15017) covers active debug code on the UART interface of NPort 5000, 6000 and S9000 series with mitigation only, so physical access control is a real security control.
• Serial servers are now in the KEV catalogue. CISA added CVE-2025-67038, an OS command injection in Lantronix EDS5000 executing as root, on 23 June 2026: treat device-server firmware like any other internet-edge firmware.
• Accounts and keys on network devices are machine identities. Shared admin logins, SNMP community strings and integration credentials need owners, rotation and central authentication where the device supports it.

How identity and access work on industrial networking devices

Most industrial switches and serial servers have a small local account database, often with a fixed administrator account and one or two lower roles, plus several management channels that each authenticate differently. Mid-range and enterprise-class industrial switches add RADIUS or TACACS+ for administrator login and 802.1X for port access; many serial servers do not.

The serial data channel deserves special attention. Industrial protocols carried over it (Modbus RTU, DNP3 serial, vendor protocols) usually have no authentication of their own, so whoever can open the TCP socket on the device server can usually command the field device. See the Industrial Protocol Security Guide.

Admin roles and privileged access

• Change every default credential at installation: including the console, web, SNMP and any service or support account. The CISA, FBI, EPA and DOE primary mitigations note that targeted OT systems used default or easily guessed passwords.
• Use named accounts where the device allows it: on switches with AAA, authenticate administrators through RADIUS or TACACS+ and keep one local break-glass account sealed in a vault. On IOS-based industrial switches the Cisco hardening guide shows the pattern: aaa new-model, aaa authentication login default group tacacs+ enable, command authorisation and accounting at privilege 15.
• Store secrets with strong hashing: on IOS, Cisco recommends enable secret and username ... algorithm-type scrypt secret, eliminating enable password and Type 7, and warns that service password-encryption is weak obfuscation.
• Separate read-only and admin roles: operators and monitoring tools need read access; only network engineers need configuration rights.
• Control remote administration: integrators and vendors should reach management interfaces only through the plant's brokered remote access, with phishing-resistant MFA as the CISA primary mitigations recommend. See the OT Remote Access Guide.
• Set session limits: idle timeouts on console and remote sessions (IOS exec-timeout; default ten minutes per Cisco) and lockout after failed attempts (aaa local authentication attempts max-fail).

Integrations, API tokens and service accounts

Industrial networking devices integrate with more systems than their size suggests, and each integration carries a credential.

These credentials are classic non-human identities: long-lived, shared between tools, and rarely rotated because nobody wants to touch a running plant. Record each one with an owner and rotation trigger. See the Service Account Security Guide and the Secrets Management Guide.

Logging and detection

• Send logs off the device: syslog to a collector in the OT DMZ or site security zone, with timestamps. On IOS, Cisco's guidance uses logging host, logging buffered, logging source-interface and service timestamps log datetime msec show-timezone.
• Synchronise time: authenticated NTP so events can be correlated with HMI and controller logs.
• Alert on high-value events: administrator login success and failure, configuration change and save, firmware upload, account changes, port link up and down on critical ports, spanning tree topology changes, and reboots.
• Watch the network, not just the device: many serial servers log little. Passive OT monitoring can see new connections to serial TCP ports, management traffic from unexpected hosts and firmware transfers. See the OT Network Security Monitoring Guide.
• Track advisories: subscribe to vendor PSIRT feeds (Moxa, Belden for Hirschmann, Cisco, Lantronix) and CISA ICS advisories, and check the KEV catalogue. Moxa advisories include defence-in-depth mitigations such as restricting network access with firewalls or ACLs, VLAN segregation, disabling unused services and ports, and enabling event logging.

Relevant ATT&CK for ICS techniques to map detections to include T0883 Internet Accessible Device, T0822 External Remote Services, T0886 Remote Services, T0859 Valid Accounts, T0830 Adversary-in-the-Middle and T0814 Denial of Service.

Hardening baseline

Apply the baseline in phases, because a misstep on a switch can stop a production line.

1. Inventory and back up. Record model, firmware, serial and IP for every switch and device server, and take an offline configuration backup before any change. See the OT Asset Visibility Guide.
2. Check exposure first. Confirm no management interface or serial TCP port is reachable from the internet or the corporate network. This is the highest-value change and usually happens at the firewall, not on the device.
3. Credentials. Replace defaults, create named or role accounts, set console passwords, and move SNMP to v3.
4. Services. Disable HTTP, Telnet, SNMP v1/v2c, unused discovery protocols, vendor configuration utilities after commissioning, and unused serial and Ethernet ports. On IOS-based switches Cisco lists no ip http server, no cdp run or per-interface no cdp enable on untrusted segments, and transport input ssh on VTY lines.
5. Restrict management. Bind management to a dedicated VLAN or interface and apply ACLs to the management plane (IOS Management Plane Protection: control-plane host then management-interface ... allow ssh https; Cisco notes it does not filter IPv6).
6. Switching protections. Where supported and tested: port security or 802.1X on access ports, DHCP snooping, broadcast storm control, and loop protection, so that a rogue laptop or failed device cannot disrupt the ring.
7. Firmware. Upgrade to a supported release that fixes known advisories, after testing on a spare unit or in a lab; verify the image source and hash.
8. Physical. Lock cabinets, seal unused ports, and control access to console and debug interfaces, which for MPSA-257331 is the vendor's primary mitigation.
9. Test and roll back. Pilot on one cell during a maintenance window with operations present; keep the backup and a console cable ready to restore the previous configuration within the window.

When an advisory lands: device-server and switch advisories fall into three groups, and each needs a different response. Remotely exploitable flaws with a fixed firmware release (the Lantronix EDS5000 command injection in the KEV catalogue is an example, with CISA's required action pointing to vendor mitigations and its BOD 26-04 prioritisation guidance) go to the top of the OT patch queue, with the conduit firewall tightened until the upgrade window. Flaws with mitigation only, such as MPSA-257331, become permanent compensating controls recorded against the asset: physical access, network restriction and monitoring. Protocol or cryptographic "security enhancement" notices, such as weak SSH algorithms or TLS renegotiation, are configuration changes to fold into the next baseline revision. Recording which group each advisory falls into, and why, is what lets an auditor or a new engineer understand a device's risk years later. See the ICS Advisory Triage and OT Vulnerability Management Guide.

Decision guidance: small sites with a handful of unmanaged or lightly managed devices should focus on exposure, default credentials and physical security, then replace unmanaged switches in critical zones with managed ones. Large estates should standardise on a golden configuration per model, push it through a management system with change control, and use central AAA. Where a device cannot meet the baseline (no SSH, no SNMPv3, no logging), compensate at the conduit firewall and plan replacement. See the Edge Device End of Life Replacement Playbook.

Framework mapping

In IEC 62443 terms, these devices sit inside zones and on conduits, and their hardening is part of meeting the target security level for the zone. See the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide and the IEC 62443 Guide.

Measuring progress

• Exposure: number of switch or device server management interfaces reachable from outside the OT management zone; target zero.
• Default credential rate: percentage of devices verified as having no default or shared vendor password; target 100 percent changed.
• Insecure protocol count: devices with Telnet, HTTP or SNMP v1/v2c enabled.
• Firmware currency: percentage of devices on a release with no open vendor advisory rated High or Critical, and time from advisory to remediation or documented mitigation.
• Log coverage: percentage of managed devices sending syslog to the collector.

Common misconfigurations

• Serial server TCP ports open to the whole plant network: any workstation can issue commands to a field device because the device server has no IP allowlist.
• SNMP read-write with default communities: lets anyone on the network change configuration or reboot the device.
• Vendor discovery utility left enabled: broadcast configuration tools that were needed once at commissioning stay on for years.
• Management on the production VLAN: no separation between control traffic and administration, so every compromised HMI can reach every switch.
• Unencrypted configuration backups on a shared drive: exposing credentials, SNMP secrets and keys for every device.
• "Air-gapped" devices with a cellular modem: a remote access path added by an integrator that bypasses all segmentation. See the Edge Device Security Guide.

Practitioner checklist

• Confirm no industrial switch or serial server management or serial TCP port is internet-facing or reachable from the corporate network.
• Change all default credentials, including console, SNMP and support accounts, and record owners.
• Disable Telnet, HTTP, SNMP v1/v2c, unused discovery protocols, vendor configuration utilities and unused ports.
• Restrict serial data channels with IP allowlists to named SCADA or historian hosts.
• Move management to a dedicated VLAN with ACLs, and use central AAA where supported.
• Send syslog with authenticated NTP time to a collector and alert on admin logins, configuration and firmware changes.
• Subscribe to vendor PSIRT feeds and CISA ICS advisories; check KEV for your models.
• Secure cabinets and console or debug interfaces, especially for models with mitigation-only advisories.
• Keep encrypted, offline configuration backups and a tested rollback per device.

Standards and references

• CISA, FBI, EPA and DOE: Primary Mitigations to Reduce Cyber Threats to Operational Technology
• Moxa: MPSA-257331 Active Debug Code Vulnerability in Serial Device Servers
• Moxa: Security Advisories
• Belden: Security Assurance and Hirschmann Security Bulletins
• Cisco: Cisco Guide to Harden Cisco IOS Devices
• CISA: Known Exploited Vulnerabilities Catalog
• MITRE ATT&CK: ICS Matrix
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: ICS Advisory Triage and OT Vulnerability Management Guide · Industrial IoT (IIoT) Security Guide · HMI and SCADA Server Hardening Guide · Edge Device Security Guide