Private Cellular Networks for Utilities: Building Secure, Future-Ready Connectivity

The utility network of 2026 looks nothing like the one most operators built their connectivity strategy around. Distributed energy resources, EV charging, battery storage, substation automation and near-real-time metering have turned a handful of monitored sites into tens of thousands of intelligent endpoints spread across the service area. At the same time, the line between corporate IT and operational technology (OT) is dissolving, and every newly connected asset widens the attack surface.

Leaning on public cellular alone starts to creak under that load. Shared networks contend for capacity during exactly the storm or outage events when utility traffic matters most, they offer little visibility into how data is routed, and they hand control of a mission-critical dependency to a third party. That is why private cellular, private LTE and private 5G, has moved from a niche experiment to a serious part of the critical-infrastructure toolkit.

What “private” actually buys you

A private cellular network uses the same 3GPP technology as the public carriers, but the operator, or a managed provider on their behalf, controls the core, the policies and often the spectrum. In practical terms that means:

• Access control on your terms. You decide which devices attach, how traffic is prioritised and where it is allowed to go.
• Isolation from public congestion and threats. Mission-critical traffic is not competing with the public internet for airtime, and it is not exposed to it by default.
• Deterministic performance. Dedicated capacity delivers the predictable latency and reliability that SCADA, protection and control cannot do without.
• Coverage where carriers will not build. Substations, reservoirs and rural distribution assets can be covered on the operator’s own terms rather than waiting for commercial rollout.

The UK spectrum picture

Much of the private-cellular conversation is written from a US perspective, where utilities have built private LTE on the 900 MHz band anchored by Anterix. The UK route is different and, for most enterprises, more accessible. Ofcom’s Shared Access Licence (SAL) framework lets organisations apply for localised spectrum directly from the regulator rather than negotiating with a mobile operator.

The framework covers several bands, including 1800 MHz, 2300 MHz, the sizeable 3.8 to 4.2 GHz mid-band allocation and 26 GHz for indoor use, and it has proved genuinely popular: more than 1,600 Shared Access licences had been issued since the framework opened in 2019, with numbers still climbing as Ofcom works to automate and speed up the application process. For a utility, that means a private network is a licensing exercise and a design exercise, not a decade-long spectrum campaign.

Security is layered, not a property of the spectrum

It is tempting to treat “private” as a synonym for “secure”. It is not. A private network removes a large class of exposure, but a poorly managed fleet on private spectrum is still a poorly managed fleet. Real resilience comes from three layers working together: the network, the device and the management plane.

1. Network control and isolation

Running your own network, or a slice of one, lets you segment traffic, enforce per-device policy and keep OT protocols off any path that touches the public internet. This is the layer private cellular delivers most directly.

2. Device-level security in the field

The endpoint is almost always the weakest link. A cellular router sitting in an unmanned cabinet needs to prove it is running trusted firmware, protect data at rest and in transit, and refuse unauthorised access even when someone has physical hands on it.

3. Secure remote management

With thousands of endpoints you cannot send an engineer to each one. A management platform that can push configuration, roll out firmware and enforce a consistent security posture over the air is what turns a pile of routers into a governable estate.

The router is the security boundary

Whatever the core looks like, the field router is where policy meets the physical asset. This is where hardware choice earns its keep, and two vendors in particular come up repeatedly for UK utility and industrial work.

Teltonika

Teltonika’s RutOS platform underpins the RUT and RUTX families and bundles a deep security toolset as standard: a broad VPN suite spanning IPsec (IKEv1/IKEv2), OpenVPN, WireGuard and more, a configurable firewall, multi-level user authorisation and hardened remote-access options. Selected models are available with a secure boot variant that cryptographically verifies each stage of the boot process, so only firmware signed by Teltonika will run, which shuts the door on tampered images in the field.

For utility work the dual-SIM models matter: the RUT956, for example, is widely used for remote metering, pulling data from energy meters over RS232/RS485 and failing over automatically between SIMs on weak signal, data limits or a dropped connection. The heavier RUTX and RUTM ranges (including 5G on the RUTM50) add throughput and multi-WAN backup for busier sites.

Milesight

Milesight’s UR series takes a similar layered approach with a slightly different emphasis. The UR32, UR35 and 5G UR75 combine dual-SIM cellular with automated failover, a full VPN protocol set (IPsec, OpenVPN, WireGuard, GRE, L2TP, DMVPN and more) and network-hardening controls such as ACLs, DMZ, SYN-flood protection and traffic filtering. Access control is unusually thorough for the price point, with centralised AAA support (RADIUS, TACACS+, LDAP, 802.1x and local authentication) and multiple user-privilege levels.

Two Milesight touches are handy for grid work specifically: native DLMS support (the global smart-meter protocol) for clean integration with metering and substation systems, and an embedded Python SDK for running light custom logic at the edge. Fleets are managed centrally through the Milesight Development Platform for over-the-air configuration and firmware.

Both are strong choices; the split tends to come down to existing tooling, metering protocol needs and whether a project standardises on RutOS or the Milesight stack. Feature sets vary by model and firmware, so confirm the specifics on the exact SKU before you commit a rollout to them.

eSIM and the SIM layer: where flexibility becomes security

In a large field deployment, the humble SIM card is a surprisingly big source of risk and delay. Physically provisioning, swapping and tracking thousands of SIMs is slow, error-prone and, every time a cabinet is opened, a small security event in its own right. eSIM removes most of that.

The standard that finally makes eSIM fit for utility-scale IoT is GSMA SGP.32. Unlike the consumer eSIM standard (SGP.22), which assumed a person with a screen to scan a QR code, SGP.32 is built for headless, deployed devices. It introduces an eSIM IoT Manager (eIM) and an IoT Profile Assistant (IPA) so profiles can be downloaded, enabled, disabled and switched entirely over the air, with lightweight transports suited to constrained NB-IoT and LTE-M endpoints. The specification has matured through 2024 to 2026, certified modules are now shipping, and commercial deployment is expected to scale through late 2026 and 2027.

For utilities, the security and continuity benefits are concrete:

• No physical handling. Provision and re-provision remotely, so a profile change is never a site visit or an opened enclosure.
• Operator flexibility and sunset protection. As 2G and 3G are retired and coverage shifts, devices can move to a new profile without touching hardware. In the UK’s multi-operator market that is a genuine hedge against a decade-long deployment outliving its original network.
• Private-to-public failover. A single eUICC can hold both a private-network profile and a public fallback, switching automatically to keep an asset online.

Automation and resilience close the loop

Security and operational efficiency pull in the same direction here: every manual step you remove is one fewer chance for human error and one fewer truck roll. Zero-touch provisioning lets a device attach on a bootstrap profile, pull its intended configuration and connectivity remotely, and settle into the right network with no engineer on site. Combine that with automated SIM and WAN failover, and the fleet stays connected and consistent without constant intervention, which is exactly the posture a distributed grid needs.

What to specify: a practical checklist

A strategic advantage, not a checkbox

For utilities and critical-infrastructure operators, secure connectivity has stopped being a background utility of its own and become foundational to how the grid runs. Put the pieces together, private or shared spectrum for control, hardened routers as the security boundary, eSIM for flexibility and continuity, and centralised management to hold it all to a consistent standard, and you get a network that is more resilient, easier to govern and better placed to absorb whatever the next decade of grid modernisation asks of it.

Frequently asked questions

Is a private cellular network the same as a secure one?

No. Private spectrum removes a large class of exposure, but security still depends on hardened devices, encrypted transport, access control and disciplined remote management. Treat “private” as one layer, not the whole strategy.

Do I need my own spectrum in the UK?

Not necessarily. You can apply for localised spectrum through Ofcom’s Shared Access Licence framework, or work with a managed private-network provider who holds the licence and delivers the core as a service. Many deployments also combine a private core with public fallback.

Should I wait for SGP.32 before deploying?

Generally no. Deploy on the connectivity you can get today, but specify eSIM-capable (eUICC) hardware so you can adopt SGP.32 profile management as the ecosystem matures, rather than being locked to one operator for a ten-year asset life.

Which router should a utility choose?

Both Teltonika and Milesight cover the core security and failover requirements well. The decision usually turns on metering protocol needs (DLMS vs Modbus), edge-logic requirements, and which management platform your team wants to standardise on. Validate the exact feature set on the specific model before rollout.