In industrial IoT projects, cellular routers are often selected simply as an “internet pipe”—Is the signal good? Is the speed high enough? Can the price be pushed down? That logic may work for consumer-grade routers, but in industrial scenarios it misses a critical point: the router is the security egress for the entire site network, not just an entry point to the Internet.
In a Reddit discussion about cellular router security, one idea is worth noting: use an “external” cellular modem, connect through Wi-Fi or a similar method, and do not let it directly access system memory or the core network. The logic behind this suggestion is simple—once the cellular router is compromised, the attacker is standing at the entrance to your OT network.
OTORIO research has already found security vulnerabilities in the cloud management platforms of several mainstream industrial cellular router vendors, potentially affecting a very large number of devices. For a manufacturer, a compromised router on a production line does not mean “the network is a little slow.” It can mean line downtime, uncontrolled equipment, and even safety incidents.
PUSR has pointed out a very common phenomenon in industrial router selection:conversations almost always start with speed and price, and almost never start with security.Hardware specifications are visible and easy to debate. But what determines whether a site can stay online is often the internal security mechanisms.
This article looks at the security features that should be evaluated in an industrial cellular router, from the perspective of a manufacturer selecting one.
Security begins the moment the router powers on.
Secure Boot.The bootloader should verify cryptographic signatures before executing any code. Without secure boot, someone with physical access to the device—or a tampered firmware file—can take control before you even log in. This is especially critical at unattended remote sites, where you cannot send someone to physically inspect the device every time.
Firmware signing and integrity verification.Every firmware image should be signed, and the device should verify the signature and checksum before writing to flash. A very specific question to ask a vendor is: “How do I verify that a firmware file is genuine?” If they cannot answer, that itself is a signal.
Secure firmware updates.Updates should be transmitted over an encrypted channel, flashed atomically, and rolled back cleanly if interrupted. A half-written firmware at a remote site is not a bug report—it is a site visit that must be handled in person.
TPM (Trusted Platform Module).More and more industrial routers now include a TPM chip for secure key storage. A TPM ensures that keys cannot be easily extracted, even if the device is physically disassembled.
No hardcoded credentials.This is one of the most common reasons industrial routers are compromised. Scanners continuously scan cellular IP ranges looking for default login information such as admin/admin. Every device should have unique default credentials at shipment, not one shared password for the entire product line.
Password policy.Enforce strong passwords, disallow shared factory defaults, and lock accounts after repeated failed login attempts. These may sound basic, but not every vendor has implemented them seriously.
Account management.Distinguish between administrator and viewer roles, support per-user accounts, and allow unused accounts to be disabled.
SSH security.Prefer key-based authentication over password authentication, support SSH2 only, and allow the port to be configured.Telnet should be disabled by default—Telnet transmits passwords in plaintext and should not simply be hidden behind a menu; it should not be running at all.
802.1X and AAA.For scenarios requiring centralized authentication, check whether the router supports 802.1X port authentication and whether it supports AAA protocols such as RADIUS and TACACS+. These mechanisms ensure that only authenticated PLCs, sensors, or management terminals can join the network, while also providing audit trails and role-based permissions.
Two-factor authentication (2FA).For remote management interfaces, 2FA can significantly reduce the risk of credential theft. This is especially important in distributed sites and mobile asset scenarios.
Stateful firewall, default deny on the WAN side.An industrial cellular router’s firewall should be stateful, and the default policy on the WAN side should be to deny all inbound traffic, opening only the services actually in use. NAT is not a firewall—NAT is only address translation and does not provide stateful packet inspection.
ACL (Access Control List).The management interface should be restricted to specific source IPs or subnets. On a factory floor, the management UI does not need to be open to the entire network. ACLs should also be able to limit lateral movement inside the network.
VLAN isolation.Separate the OT network from the office network. If PLCs and employee laptops are in the same broadcast domain, one infected laptop can reach the production line. VLAN segmentation plus inter-VLAN access rules is one of the lowest-cost and most direct security measures in industrial networks.
Service disabling.Unused physical ports, Telnet, SNMP, Modbus, and other protocols should be disableable, minimizing the attack surface. This is especially valuable at unattended remote sites.
Disable Ping response.Make it harder for attackers to easily discover hosts by ping, increasing the difficulty of reconnaissance.
VPN is the security core of an industrial cellular router.Cellular networks themselves do not provide an end-to-end encryption guarantee—data traffic running over a SIM card is readable inside the carrier’s network. A VPN tunnel ensures that traffic crossing the SIM card is unreadable to anyone on the carrier network.
Specific items to check:
Supported VPN protocols: At minimum, IPsec, OpenVPN, and L2TP should be covered. Ideally, GRE and WireGuard should also be supported. IPsec with AES-256 encryption remains the industry standard for remote site deployments.
OpenVPN flexibility: Does it support connecting simultaneously as a client to multiple OpenVPN servers while also acting as a server itself? Does it support one-click import of .ovpn and PKCS#12 certificate files? These capabilities directly affect deployment efficiency and also reflect the maturity of the product’s VPN functionality.
Encryption strength: Confirm whether OpenVPN or IPsec uses AES-256 or AES-128. There is a substantial security difference between the two.
Chinese cryptographic algorithms: In domestic industrial and energy scenarios, support for domestic cryptographic algorithms such as SM2/SM4 is sometimes a compliance requirement and should be considered as an option during selection.
Wi-Fi security.If the router includes Wi-Fi, confirm whether it supports WPA2-PSK and WPA3-PSK, as well as TKIP and AES encryption algorithms. WPA2 is the baseline; WPA3 is a plus.
Security is not only about “keeping them out.” It also means “knowing immediately when something goes wrong.”
Offline and traffic alerts.Device offline, traffic exceeding limits, SIM card abnormalities—these events need real-time alerts, pushed through at least two channels, such as email plus SMS. Having only one alert channel means that if that channel fails, you know nothing at all.
Weak signal alerts.Alert thresholds should be configurable and trigger at a realistically usable RSSI level, rather than waiting until the signal disappears completely.
HTTPS management interface.The management interface should support HTTPS, not HTTP. A management interface that does not support HTTPS is vulnerable to man-in-the-middle attacks, where an attacker can intercept credentials during login.
Watchdog.Hardware plus software dual watchdog, with automatic recovery when the device becomes unresponsive. The test method is simple: kill the cellular process or freeze the Web UI, then verify whether the recovery time matches the documented interval.
Logging and audit.Does it support detailed device operation logs? Can it record who changed what configuration and when? For scenarios that need to meet compliance requirements or trace security incidents, logging capability is a requirement.
Condense the points above into an actionable checklist:
| Layer | Check Items |
|---|---|
| Boot trust | Secure boot, firmware signature verification, secure firmware updates, TPM support |
| Identity and access | Unique default credentials, password policy, account role separation, SSH key authentication, Telnet disabled by default, 802.1X/AAA, 2FA |
| Traffic control | Stateful firewall (default deny on WAN), ACL, VLAN isolation, service disabling, Ping disabled |
| Data encryption | IPsec/AES-256, OpenVPN (multi-server client + server mode), GRE, WireGuard, Chinese cryptographic algorithms (optional) |
| Operations and alerts | Offline/traffic/SIM anomaly alerts, multi-channel alert push, HTTPS management, hardware + software watchdog, audit logs |
| Compliance certifications | EN 18031, IEC 62443-4-2, etc. |
During the POC phase, it is recommended to actually test every item in this table. A week of bench testing takes only a few engineer-hours, while the same defect causing one day of production line downtime is a completely different order of magnitude in loss.
Security features in industrial cellular routers are not a “nice to have” add-on. They are infrastructure that determines whether a site can stay online. When manufacturers put security ahead of speed and price during selection, it is not excessive caution—it is taking responsibility for production continuity.
If you are evaluating the security capabilities of industrial cellular routers, you are welcome to discuss your specific selection requirements with PUSR’s technical team.
