A quiet shift has happened in industrial networking. The latest generation of industrial gateways comes with SIM slots and pairs with outdoor 5G modems as standard — connectivity that used to require a fixed line is now built into the box. And nobody in the industry is surprised. Cellular connectivity at remote sites has simply become the default.

That's good news and bad news. Good, because a pumping station, a solar farm, or a production cell no longer needs a fixed broadband line to be reachable. Bad, because every site you connect over 4G/5G is now a door into your OT network — and most of those doors were installed by whoever rushed the deployment, not by whoever thinks about security.

Let's talk about what actually works. Not theory — the things you can configure on a real industrial 4G router this week.

First, know where the risk is — and how to avoid it

Here's the uncomfortable part: the cellular link itself is rarely the problem. The carrier network is fairly opaque from the outside — a device on 4G isn't trivially scannable the way a server with a public IP is.

What gets remote OT networks compromised is almost always the stuff around the link:

• Port forwarding straight to a PLC or HMI.Someone needs remote access, so they forward TCP 502 or the SCADA web port to the internet. That Modbus TCP server was never designed to face the public internet.

• Flat networks.The cellular router bridges everything — PLCs, IP cameras, the contractor's laptop on guest Wi-Fi — into one subnet. One infected camera, and your controller is a hop away.

• Default credentials and forgotten web consoles.A router installed three years ago, still on its default password, with remote management enabled "for convenience."

• No visibility.Nobody notices unusual traffic, because nobody is watching traffic at all.

The fix isn't exotic. It's a handful of practices, applied consistently, on hardware that supports them.

Lock the tunnel, close the ports

The single most effective change: stop using port forwarding and put everything inside a VPN tunnel.

An industrial 4g router or 5g industrial router worth installing should terminate VPN sessions itself. On PUSR routers like theUSR-G806wor the 5GUSR-G816, OpenVPN, IPsec, L2TP, PPTP, and GRE are all built in — no extra box at the edge. The G806w even supports one-click import of .ovpn config files, so you're not hand-typing certificates at a cabinet in a substation at 6 a.m.

Two deployment patterns work well:

① Router as VPN client.Each remote site's router dials into your OpenVPN server at the control center. From the outside, nothing is exposed — no open ports on the cellular side at all. Your SCADA server reaches the PLC through the tunnel.
② Router as VPN server.The G816 and G806w can also act as OpenVPN servers, so your engineers connect into the router directly when they need to. Access is still authenticated, encrypted, and logged — just by the router instead of by a forwarded port.

Either way, the rule of thumb is simple: if a device behind the router is reachable without a tunnel, you've configured something wrong.

Segment like the PLC's life depends on it

Because it might. The cellular router is your natural firewall boundary — use it.

• Put the PLCs and controllers on their own subnet behind the router's LAN.

• Keep IP cameras, contractor Wi-Fi, and anything else on separate VLANs or at minimum separate subnets with inter-routing disabled.

• On the router, only allow the specific traffic that needs to flow: the SCADA poll to the PLC, the historian's upload, nothing else.

A concrete example from the field: PUSR's own application notes for these routers cover shared self-service kiosks, freight and bus fleets, and intelligent robots. What do these have in common? Every one of them carries a payment terminal, a GPS module, or a camerain addition tothe thing you actually manage. Without segmentation, a compromised payment terminal and your control traffic share the same pipe. With it, they don't.

Watch the network, not just the devices

You can't visit 200 remote sites. So the router has to tell you when something is off.

PUSR's remote management platform does exactly this, and it's worth setting up on day one rather than "later":

• Device offline and weak signal alarms— usually operational issues, but a site that keeps dropping offline is also worth a security look.

• Traffic overrun alarms, pushed via email or SMS— this one is quietly powerful. Your site pulls 200 MB a month normally. Suddenly it's pushing gigabytes upstream at 3 a.m. That's the signature of either a misconfiguration or something on the LAN making calls it shouldn't be. Either way, you want to know.

• Remote firmware upgrades— because the router you can patch remotely gets patched; the one you have to drive to doesn't. The platform handles parameter changes, reboots, and firmware from one console, which matters when your sites are spread across a region.

And speaking of firmware: choose hardware that's actively maintained. PUSR's devices now meet the EU's EN 18031 (RED) cybersecurity standard — a useful shorthand when you're comparing vendors, because it means the product was assessed against actual security requirements, not just RF ones.

Don't forget the physical layer of the security stack

Security discussions always go to software, but remote OT sites fail physically more often than they get hacked. The router that dies at -30°C takes your visibility with it.

Look for the industrial fundamentals on the datasheet:

• Wide temperature operation.The G816 runs -35°C to 75°C; the G806w handles -20°C to 70°C — both inside an unheated enclosure.

• Dual hardware/software watchdog.A hung router at an unmanned site auto-recovers instead of waiting for a truck roll.

• Surge, EFT, and ESD protection.Remote sites are where lightning and messy grounding live.

• WAN failover.The G816 and G806w both switch between cellular and wired automatically, so a cut fiber doesn't become an "urgent security incident" when someone reverts to an insecure workaround to get connected again.

That last point is more important than it sounds. Availability and security fail together: when the legitimate link goes down, someonewillimprovise. Failover is a security control.

A checklist you can actually use

If you're deploying cellular routers at remote OT sites, here's the short version:

• VPN tunnel (OpenVPN or IPsec) from every site router — zero inbound port forwarding, ever.
• Change every default password before the device leaves your bench.
• Disable remote web management from the WAN side; manage through the tunnel or the management platform.
• Segment: PLCs on their own subnet, cameras and Wi-Fi elsewhere, inter-routing off.
• Enable offline, weak-signal, and traffic alarms — and route them somewhere a human reads.
• Register the devices for remote firmware updates, and actually apply them.
• Verify the hardware is rated for the site's temperature and power conditions before, not after, the first winter.

None of this is complicated. It's just that cellular deployments often happen site-by-site, in a hurry, by whoever is closest — and the defaults are almost never secure.

The industry has decided that 4G/5G is how remote sites get connected — even the enterprise Wi-Fi vendors are building SIM slots into industrial gateways now. The manufacturers who come out ahead aren't the ones who avoid cellular; they're the ones who treat that cellular router as a security device from the first configuration, not as a modem.

Pick a router that gives you the tools — VPN termination, segmentation, alarm-based monitoring, remote firmware, industrial-grade reliability — and spend an afternoon on the setup.