Cellular routers and gateways connect pumping stations, substations, kiosks, ATMs, digital signs and remote cabinets straight to a mobile network, and many of them sit with a public IP address, a web console and a default password where nobody looks at them for years. They are edge devices in every sense: internet reachable, rarely patched, poorly logged and often trusted by the OT or branch network behind them. This guide covers the hardening that is specific to 4G LTE and 5G devices: SIM and APN design, management exposure, cloud management portals, SMS control, firmware, VPN and logging. It is written for OT engineers, network engineers and security teams responsible for remote sites. The workflow for granting people remote access through these devices is covered in the OT Remote Access Guide, and general small router hardening in the SOHO and SMB Router Hardening Guide; this page stays on the cellular device itself.
Key takeaways
- The SIM decides your exposure. A SIM with a public IP address puts the router's services on the internet; a private APN with a private address keeps them inside the carrier's network and your VPN.
- Management interfaces never face the internet. The 2025 joint edge device guidance led by Canada's Cyber Centre states management interfaces should not be directly exposed to the internet. Use the private APN, a VPN or the vendor's cloud portal instead.
- The cloud portal is a privileged identity system. Whoever holds a cloud management account can push configuration and firmware to every router in the fleet, so it needs phishing-resistant MFA, roles and audit logging.
- SMS is a management channel. SMS commands that reboot, reconfigure or open remote access must be disabled or restricted to allow-listed numbers with a password.
- Logs must leave the device. Forward syslog to a central collector, because local logs on a compromised or rebooted router are lost or untrustworthy.
Why cellular gateways are a distinct risk
A cellular gateway combines a router, a firewall, a modem and often a serial or Modbus gateway in one box, deployed where there is no wired connection and no on-site IT. Several properties make it harder to secure than a branch router:
- Carrier addressing: the IP address and inbound reachability are set by the SIM and APN, not by your firewall team. A public IP SIM can make the device reachable from anywhere.
- Out of band channels: SMS and cloud management give paths into the device that bypass the LAN and the VPN.
- Long life and physical exposure: devices sit in roadside cabinets and kiosks for a decade, where the SIM can be removed and used elsewhere.
- Trusted position: the OT network behind the router often has no other control, so compromise of the router is compromise of the site.
Industrial cellular routers appear regularly in CISA ICS advisories, and CISA added a 2018 file upload flaw in one widely used cellular router operating system (CVE-2018-4063) to its Known Exploited Vulnerabilities catalogue on 12 December 2025, years after disclosure. Old firmware on forgotten devices is the pattern to plan for. The relevant ATT&CK for ICS techniques are T0883 Internet Accessible Device, T0822 External Remote Services and T0866 Exploitation of Remote Services; in enterprise terms, T1190 Exploit Public-Facing Application and T1078 Valid Accounts.
SIM, APN and carrier configuration
Most of the attack surface reduction available for a cellular device is decided when the SIM is ordered. Treat the carrier contract as a security control.
| Option | What it means | Security effect | When to use |
|---|---|---|---|
| Public APN, public IP SIM | Device gets an internet routable address | Every listening service, and any port forward to the LAN, is reachable from the internet | Avoid; only with inbound blocked at the carrier and device and a documented exception |
| Public APN, private IP (carrier NAT) | Device shares carrier NAT, outbound only | No unsolicited inbound, but the device can reach the whole internet | Small deployments using an outbound VPN or cloud portal for management |
| Private APN | Dedicated APN that routes only to your network, usually through an IPsec or dedicated link from the carrier | Device is not internet reachable; traffic lands in your data centre or cloud where you can filter and log it | OT, utilities, payment and any fleet over a few dozen sites |
| Private APN plus device VPN | Private APN and an encrypted tunnel from the device to your head end | Protects against carrier side exposure and gives you end to end authentication | Critical infrastructure and regulated data |
- Ask the carrier the right questions: whether the APN blocks inbound traffic and which ports or protocols it filters, whether the SIM can be locked to the intended hardware (for example by device TAC or IMEI), and how the APN connects to your network.
- Lock SIMs to devices: use carrier side IMEI or TAC locking and set a SIM PIN on the router where supported, so a SIM pulled from a cabinet cannot be used in a laptop to join your private APN.
- Restrict SIM services: disable voice and premium SMS where not needed and set data caps and usage alerts. Unusual data use on a SIM is often the first sign of misuse.
- Know your cellular threat model: the radio link has its own risks, such as fake base stations and downgrade to older generations. See the Cellular Baseband and IMSI Catcher Guide and the 5G Security Guide.
Management exposure and authentication
The joint 2025 edge device publications from the Australian, Canadian, UK and US agencies agree on the core rules: keep management interfaces off the internet, use phishing-resistant MFA for all administrative access, change default credentials before deployment and disable unused services.
| Interface | Hardening setting | Notes |
|---|---|---|
| Web UI | HTTPS only; HTTP disabled; WAN and mobile side access off | Some platforms ship remote web, SSH and CLI access off by default with local LAN access on; confirm on every model |
| SSH and CLI | Key based where supported; Telnet disabled; WAN access off | Allow-list management source addresses on the LAN or VPN side |
| SNMP | SNMPv3 with authentication and privacy; v1 and v2c disabled | Restrict to the monitoring server address |
| Login protection | Lockout or blocking after failed logins | Some platforms block a source IP after 10 failed SSH or web logins by default |
| Local accounts | Unique admin password per device from a vault; read-only roles for monitoring | Many devices ship with a per-device default printed on the label; it is still a default and must be changed |
| Physical ports | Unused Ethernet ports disabled; LAN DHCP off where devices are static; USB limited to signed configuration | Cabinets are physically accessible |
| Wi-Fi | Disabled unless required; WPA2 or WPA3 Enterprise if used | A Wi-Fi radio in a roadside cabinet is an extra entry point |
Device local accounts are machine credentials in practice: shared by field engineers, rarely rotated and stored in spreadsheets. Generate a unique password per device, keep it in a privileged access or secrets vault, and rotate it when an engineer leaves. Where the device supports RADIUS or TACACS+ for admin login, use it so access follows your identity provider. See the Device and IoT Identity Guide.
Cloud management portals and SMS control
Most industrial cellular router vendors offer a cloud portal for fleet configuration, firmware updates and remote access. It removes the need for public IPs, which is good, and concentrates control of the whole fleet in one web account, which is a risk to manage.
- Accounts: named accounts only, no shared fleet login; phishing-resistant MFA or SSO through your identity provider where offered; least privilege roles that separate viewing, configuration and firmware deployment.
- Remote access features: portal based tunnels or remote web sessions to devices behind the router are external remote services. Enable them per device and per session, with time limits and approval, not permanently.
- API keys: portal API tokens used by monitoring or provisioning scripts are non-human identities with fleet wide power. Scope, store and rotate them like any other privileged secret.
- Audit: export portal audit logs to your SIEM: logins, role changes, configuration pushes, firmware deployments and remote sessions.
- Device enrolment: confirm how devices are claimed into a tenant (serial number, claim code) and remove devices from the portal when they are decommissioned or resold.
SMS control: many routers accept SMS commands to reboot, change APN settings, switch on remote access or return status. Disable SMS management unless there is an operational need. Where it is needed, require the admin password in the command, allow-list sender numbers, and log every command. Remember that caller ID can be spoofed, so number allow-listing alone is not authentication.
Firmware and lifecycle
- Inventory: record model, serial, IMEI, ICCID, firmware version, site and owner for every device. Without the IMEI and ICCID you cannot tie carrier data to a device.
- Subscribe to advisories: follow each vendor's security notifications and CISA ICS advisories, and track the vendor's software support policy and end of life dates. See the ICS Advisory Triage and OT Vulnerability Management Guide.
- Test before rollout: the joint guidance advises installing security patches as quickly as possible after testing on a standby or test device. Keep one of each model in a lab.
- Roll out in rings: lab, a few low impact sites, then the fleet. A failed firmware update at a remote site means a truck roll, so stage carefully and confirm the device can fall back to its previous image.
- Verify integrity: install only signed firmware from the vendor's official channel, and check the running version after update.
- Replace end of life devices: devices that no longer receive firmware updates should be replaced or isolated behind compensating controls. See the Firmware and Boot Security Guide.
VPN and network segmentation
- Tunnel design: choose between device to head end VPN (IPsec IKEv2, OpenVPN or WireGuard, depending on what the platform supports), carrier provided IPsec from the private APN, or end to end encryption from the field device to the application. Router to cloud tunnels leave traffic between the field device and the router unencrypted, so sensitive protocols may still need application layer protection.
- Authentication: certificate based tunnel authentication with per device certificates in preference to a shared pre-shared key used across the fleet. See the IoT and Device Certificate Provisioning (EST, SCEP) Guide.
- Default deny at the head end: each site's tunnel should reach only the SCADA, historian or payment hosts it needs, not the whole corporate network.
- Local firewall: block inbound on the mobile interface, remove unused port forwards and DMZ settings, and segment the LAN so a compromised field device cannot reach the router's management plane.
- Failover paths: where a router fails over between wired and cellular WANs, make sure the same rules and VPN apply on both paths.
Logging, detection and measurement
The joint guidance calls for centralised, off-device logging with log levels as detailed as possible, and redundancy for event logs. For cellular gateways, collect from three places: the device, the cloud portal and the carrier.
| Source | Events to collect | What to alert on |
|---|---|---|
| Device syslog | Admin logins and failures, configuration changes, reboots, firmware changes, VPN up and down, SMS commands received | Logins from unexpected sources, config change outside a change window, SMS command from unknown numbers |
| Cloud portal audit log | Portal logins, role changes, bulk configuration pushes, firmware deployments, remote sessions | New admin, MFA disabled, mass push, remote session without a ticket |
| Carrier portal and APN records | Data volume per SIM, IMEI to ICCID pairing, session locations | SIM seen in a different IMEI, data spike, sessions from an unexpected cell area |
| Head end and firewall | Tunnel establishment, traffic from each site | Site talking to hosts outside its allow-list, tunnel from an unknown certificate |
- Exposure: number of devices with a public IP or an internet reachable management service, from external attack surface scans. Target zero.
- Firmware currency: percentage of the fleet on a supported, current firmware within your patch target.
- Default credential rate: devices still using the factory or label password, from configuration audits.
- Logging coverage: percentage of devices whose syslog reached the collector in the last 24 hours.
- Portal hygiene: portal accounts without MFA and accounts unused for 90 days.
Rolling out the baseline
- Discover: pull SIM lists from every carrier account and match them to device inventory; scan your public ranges and carrier assigned addresses for exposed management services.
- Close exposure first: disable WAN side management and port forwards on internet reachable devices, and request private IP or private APN SIMs.
- Build a golden configuration: one baseline per model covering the tables above, tested in the lab, held in version control and pushed through the cloud portal or configuration management.
- Pilot: apply to a handful of sites, confirm operations and remote support still work, and keep the previous configuration file for rollback.
- Fleet rollout and audit: roll out in waves, then compare running configurations against the golden configuration monthly and investigate drift.
Small versus large estates: a business with ten kiosks can use private IP SIMs, the vendor cloud portal with MFA and syslog to a managed collector. A utility with thousands of sites should run a private APN into its own head end, per device certificates, centralised configuration management and carrier data feeds into the SOC.
Framework mapping
| Control area | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|---|---|
| Device and SIM inventory | CM-8 System Component Inventory | ID.AM-01 |
| Golden configuration, unused services off | CM-6 Configuration Settings, CM-7 Least Functionality | PR.PS-01 |
| Management access and MFA | AC-17 Remote Access, IA-2 Identification and Authentication | PR.AA-05 |
| Private APN, VPN and segmentation | SC-7 Boundary Protection | PR.PS-01 |
| Firmware patching | SI-2 Flaw Remediation | PR.PS-01 |
| Centralised logging and review | AU-6 Audit Record Review, Analysis, and Reporting | DE.CM-01 |
For OT environments, NIST SP 800-82 Rev. 3 gives the wider architecture and ISA/IEC 62443 the zone and conduit model into which the cellular gateway fits as a conduit.
Common failure patterns
- Public IP SIMs by default: the carrier issued what was cheapest, and the router's web console has been on the internet since installation.
- Port forwards left from commissioning: an integrator opened a port to a PLC or HMI to test remotely and never closed it.
- Shared cloud portal login: one fleet account used by the vendor, integrator and in-house team, without MFA, and nobody can say who pushed a change.
- SMS commands enabled with no password: anyone who knows the SIM's number can reboot the device or change its settings.
- Firmware frozen at installation: no inventory of versions, no lab device, and fear of truck rolls means updates are never applied.
- Local logs only: the device keeps a small rolling log that is overwritten or wiped on reboot, so an investigation has nothing to work with.
Practitioner checklist
- Inventory every cellular device with model, serial, IMEI, ICCID, firmware, site and owner, and reconcile it with carrier SIM lists.
- Replace public IP SIMs with private IP or private APN SIMs, and lock SIMs to their devices.
- Disable web, SSH and CLI management on WAN and mobile interfaces; allow-list management sources on the LAN or VPN side.
- Set a unique, vaulted admin password per device and disable Telnet, HTTP and SNMPv1 and v2c.
- Protect the cloud management portal with named accounts, phishing-resistant MFA or SSO, roles and SIEM forwarded audit logs.
- Disable SMS management or require a password and allow-listed numbers, and log every command.
- Use certificate based VPNs to a default deny head end, and remove unused port forwards and DMZ settings.
- Patch firmware through a lab and ring rollout, and replace devices past end of support.
- Forward device syslog off the box and alert on configuration changes, failed logins and SIM to IMEI mismatches.
Standards and references
- ASD's ACSC and partners: Mitigation Strategies for Edge Devices, Executive Guidance
- Canadian Centre for Cyber Security and partners: Security Considerations for Edge Devices (ITSM.80.101)
- CISA: Known Exploited Vulnerabilities Catalog
- NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
- NIST: SP 800-53 Rev. 5
- Robustel: A Practical Guide to 3G/4G Router Security
- Teltonika Networks: RUTC42 Device security
Related NHI Mgmt Group resources: OT Remote Access Guide · SOHO and SMB Router Hardening Guide · Industrial IoT (IIoT) Security Guide · ICS Advisory Triage and OT Vulnerability Management Guide · Device and IoT Identity Guide