Cellular Router Security Hardening

The MikroTik September 2026 wake-up call

On 3 September 2026, MikroTik published a security advisory: it had found a vulnerability in RouterOS and shipped fixes across every release channel, namely 7.25 beta 3, 7.24.2, 7.23.4 and the 6.49.21 long-term build. To give operators time to patch, it deliberately held back the technical detail (MikroTik security advisory, September 2026).

Two details are worth pausing on. First, after you upgrade, RouterOS now checks whether the device has already been compromised and marks it with a Flagged status in the log. When a vendor builds a compromise check into the patch itself, it is telling you plainly that some devices in the field are already owned. Second, MikroTik advises inspecting the configuration for scripts, users or settings you do not recognise, even on a device that is not flagged.

MikroTik is one of the most widely deployed router platforms in the world, with a large LTE and 5G line used in M2M and IoT roles. The lesson is not that MikroTik is unusually weak. It is that one firmware flaw in a mass-deployed platform instantly becomes a global attack surface, and that is true of every vendor on your shortlist.

One flaw, every brand: a field-wide pattern

Look across the last eighteen months and the pattern repeats regardless of logo. The point of the tour below is not to single out any brand, but to show that firmware bugs, exposed interfaces and default credentials are universal.

Teltonika

CVE-2026-8914, a high-severity flaw in RutOS, let a low-privileged authenticated user run commands as root, and was fixed in 2026 firmware (NVD). Teltonika is, by most measures, a security-mature vendor: it holds IEC 62443-4-1 certification, runs third-party penetration testing on RutOS and its Remote Management System, and its RF devices meet the Radio Equipment Directive cyber requirements (Teltonika Security Centre). Maturity lowers the rate of flaws. It does not take it to zero.

The consequences are not theoretical. In August 2026, investigators reported that an attacker reached a Polish power plant by tunnelling SSH through a Teltonika RUTX50 that sat on a private APN, scanning the internal network, and taking over a controller that still ran its default administrator password. A turbine was stopped. Notably, the known router CVEs would not have granted that access on their own: the attacker had working SSH credentials. A private APN did not save the site, because the router was still reachable and the device behind it was left on defaults (The Hacker News, August 2026).

Robustel, Milesight and MikroTik again

Cisco Talos found ten vulnerabilities in the Robustel R1510 industrial router, nine of them command-injection issues rated critical, any of which could run arbitrary code (Cisco Talos). Robustel today publishes CVE-tagged advisories and runs recurring independent penetration testing through its Security Centre, a clear improvement on the original handling.

On Milesight, a directory-listing misconfiguration on several industrial cellular routers exposed log files, and a hardcoded key in the web interface let the stored passwords be decrypted, handing over admin access (CVE-2023-43261). And separate from its September advisory, CISA issued two MikroTik advisories in late July 2026: one for a RouterOS API session flaw that let a low-privilege account read the WireGuard private key in plaintext, which is enough to impersonate the VPN, and one for an API that accepted unlimited login attempts with no lockout (CISA ICSA-26-211-01).

The through-line is simple. Firmware has bugs, management interfaces get exposed, and credentials get left on defaults. Brand loyalty is not a security control.

How a cellular router actually gets exposed

Before hardening anything, it helps to see the ways a device becomes reachable or controllable. They fall into a few categories, and most real incidents combine two or three of them.

A public IP SIM

A SIM that gives the router a public, internet-routable address makes it directly scannable, and internet-scanning engines index those addresses continuously. Sometimes a public IP is the right call, for inbound VPN, firewall whitelisting or source-IP authentication, but it should be a deliberate decision with a firewall in front, not an accident of the tariff. For most fleets a private IP, a private APN, or a VPN over a private IP is safer and often cheaper. We cover the trade-off in full in private vs public IP for cellular IoT.

Exposed management interfaces

Even without a public IP SIM, you expose a device when you forward ports to it, put the web UI, SSH, the API or WinBox on the WAN side, enable dynamic DNS with open ports, or leave UPnP running. The management plane should never face the open internet.

Weak, default or reused credentials

The most common root cause across every brand. Default passwords, one shared password across a whole fleet, and reused SSH keys turn a minor exposure into a full takeover.

Unpatched firmware

A known CVE plus an exposed device is an open door. The gap between disclosure and exploitation is now measured in days, not months.

The devices behind the router

A router is a gateway to a local network of PLCs, meters and cameras. If those run default credentials, a foothold on or through the router reaches them, exactly as happened in the Polish plant. Segmentation limits how far an intruder can travel.

Prevent: a cellular router security baseline

This baseline applies to any make. It is deliberately vendor-neutral, because the controls that matter are the same on a Teltonika RUTX, a Robustel gateway, a MikroTik box, a Milesight UR unit, a Cradlepoint, an InHand or a Ubiquiti device.

• Kill default credentials. Set a unique, strong password on every device. Where supported, use keys rather than passwords for SSH, and put multi-factor authentication on cloud and fleet-management accounts.
• Keep firmware current. Track each device model and its firmware version, and patch promptly when an advisory lands. Slow patching is where breaches live.
• Keep the management plane off the internet. Bind the web UI, SSH and the API to the LAN or a management VPN, and disable WAN-side access to admin services.
• Prefer private addressing. Use a private IP or private APN, or a VPN, rather than a public IP SIM, unless you have a specific reason and a firewall. WireGuard is light and copes well with changing cellular IPs. See using a VPS for IoT and M2M for a simple pattern.
• Firewall to least privilege. Permit only the destinations the device genuinely needs, inbound and outbound, and drop the rest.
• Disable unused services. Turn off UPnP, unused protocols and anything you are not actively using. Every running service is attack surface.
• Segment the local network. Keep field controllers on their own segment so a router foothold is not the same as full operational-technology access, and change the default credentials on those devices too.
• Least privilege on accounts. Give operator accounts only the rights they need, and remove old accounts and keys when people or contractors move on.

Prevent, operationally: stay ahead of the advisories

Hardening a device once is not enough. New flaws land constantly, so the operational half of prevention is making sure you hear about them and can act at fleet scale.

• Know your fleet. Keep an inventory of make, model and firmware version. You cannot act on an advisory if you do not know what you run.
• Watch the manufacturer security pages. Every major vendor publishes advisories: the MikroTik Security page, the Teltonika Security Centre, the Robustel Security Centre, and the equivalents for Milesight, Cradlepoint, InHand and Ubiquiti. Bookmark the ones you use and check on a schedule.
• Get on the security mailing lists. Subscribe to each vendor security or firmware notification list so fixes reach you by email rather than by breach.
• Patch at scale with a fleet platform. Updating device by device does not scale. Teltonika RMS, Robustel RCMS, Cradlepoint NetCloud and InHand cloud management let you see firmware status across the estate and roll updates out centrally. Treat the platform itself as sensitive: multi-factor authentication, restricted logins, and its own patching.
• Know where to get support. Keep the vendor support channel and your distributor or integrator contact to hand before you need them. The fixed firmware version and upgrade path usually come from the vendor security page or the support portal.

Monitor: know when something is wrong

Prevention reduces the odds. Monitoring is how you catch the case that gets through.

• Track the CVE feeds. The NIST NVD, OpenCVE and the CISA Known Exploited Vulnerabilities catalogue let you watch for new issues affecting your specific brands and models.
• Watch the device. Review logs, watch for a Flagged status on MikroTik, and look for unknown users, SSH keys, scheduled tasks or scripts, and unexpected outbound connections. These are the fingerprints of a foothold.
• Centralise the logs. Forward syslog and authentication logs from routers to a central store or SIEM so you can correlate and retain them, and alert on the creation of any new local account or SSH key.
• Watch for configuration drift. A config entry you did not make is a warning worth investigating.

Government guidance points the same way. CISA and the NSA published router hygiene advice in 2026 covering exactly this ground: current firmware, no unnecessary internet-facing services, and monitoring for tampering (CISA AA26-194a).

Using AI to watch CVEs for the brands you run

The manual version of CVE monitoring is tedious, which is why it quietly lapses. An AI assistant is well suited to the tedious part. Give it your exact makes, models and firmware versions, and ask it to check the public sources for anything new since your last review, then summarise what applies to you and how urgent it is.

A workable monthly prompt looks like this:

One caveat matters more than any other: verify before you act. Language models can invent a plausible CVE number or misstate a version range. Treat the AI output as a fast first pass, then confirm every item that matters against the primary source, the NVD entry or the vendor advisory, before you schedule a patch or raise an alarm. It is the same discipline you would apply to any second-hand security claim.

Automate the plumbing underneath it as well. The NVD offers data feeds, OpenCVE lets you subscribe per vendor, and CISA will email you new advisories. The AI is the triage layer on top of those feeds, not a replacement for them.

Fix: if you suspect a device is compromised

If a device is flagged, exposed, or simply behaving oddly, work through this in order rather than reaching straight for a factory reset.

• Isolate, but preserve. Take the device off the network, but do not wipe it first if you can capture evidence.
• Capture logs and config. Export the logs and the current configuration for review before you change anything.
• Patch. Move to the fixed firmware from the vendor.
• Rotate everything. Change all device passwords, SSH keys, VPN keys and any credentials that touched the device or its management platform. Assume anything on the box is known to the attacker. A leaked WireGuard key must be regenerated, not merely re-passworded.
• Hunt for persistence. Remove unknown users, scripts, scheduled tasks and SSH keys. A Flagged status or an unexplained config entry means you should assume compromise.
• Rebuild from known-good. If in doubt, factory reset and restore from a trusted configuration backup rather than the on-device state. This is where a maintained backup process earns its keep, see OT backup and recovery.
• Check downstream. Give the devices behind the router the same treatment, starting with default credentials.
• Follow the vendor guidance. MikroTik, for example, documents the recovery steps for a Flagged device on its advisory.

Make it a routine

Security on a router fleet is not a one-off project, it is a cadence. Prevent, monitor and fix map cleanly onto a schedule.

Frequently asked questions