Below is a practical look at why VPNs fail at grid-edge scale, what a Zero Trust pattern looks like for OT, and how IXT SecureNet implements it without ripping out what you already have.
The problem: flat tunnels in a world of spiky, remote work
VPNs were designed to connect trusted networks. Utilities don’t have “one trusted network” any more; they have thousands of small, intermittently connected sites, many run by contractors, all changing over time. A site-to-site VPN drops every device on one side into the same flat address space as the other. That makes day-to-day ops easy—until an account is phished, a laptop is lost, or a misconfigured rule exposes half your estate.
Meanwhile, field teams need surgical access to one device for one task. VPNs give them a fire hose.
Risk scenarios you’ll recognise
1) Lateral movement from a single compromised credential
Shared VPN accounts or jump hosts are convenient. They also mean a single phished password can see more than it should. Once inside a flat subnet, an attacker can scan, pivot and tamper.
2) Shadow rules and “temporary” exceptions that never die
An urgent fault, a quick firmware push, a contractor who needs access “just for today”. Exceptions pile up, and nobody is fully sure what’s open where.
3) IP allow-lists that don’t match the real world
Dynamic addresses, roaming SIMs and multi-tenant platforms make static IP allow-lists brittle. You either over-permit or lock people out.
4) Over-exposed protocols at the grid edge
RTUs, IED gateways, meters and field controllers speak MQTT, IEC-104, DNP3 and DLMS/COSEM. A flat tunnel can expose management interfaces you never meant to publish.
5) Audit you can’t actually use
VPNs tell you a user connected to a network. They rarely tell you which device they touched, which flows were approved, or when a session truly ended.
The Zero Trust pattern for OT (in plain language)
Identity first, for people and things
Every device has a strong identity (SIM/eUICC + device posture). Every user does too (MFA/identity provider). No identity, no access.
Approve only the flows a task needs
Define protocols and FQDNs per device type. Allow MQTT to a defined broker, IEC-104/DNP3 to named SCADA headends, DLMS/COSEM to metering systems—and block everything else by default.
Per-session, per-app access
When someone needs to work on a site, grant time-bound access to a single device for a specific protocol. When the job is done, the session auto-expires and the door closes.
Segmentation without flat networks
No site-to-site tunnels that merge subnets. Build thin, temporary paths for specific tasks.
Audit that’s actually useful
Record who accessed which device, for how long, with which protocol, and what policy allowed it. Make it easy to review and revoke.
How IXT SecureNet implements this
One SIM, global by default
Our secure IoT SIM gives resilient coverage across borders with multi-IMSI and eUICC profile management. Steer by policy, not luck, and swap profiles over the air to avoid site visits.
Device identity tied to the SIM
Each device gets a cryptographic identity anchored to its SIM/eUICC. Policies follow that identity, so you can enforce controls per device and per fleet, not per subnet.
Protocol allow-lists at device level
Approve only the flows your assets need—MQTT, IEC-104/DNP3, DLMS/COSEM or standard IP to defined FQDNs. Everything else is denied by default.
Just-in-time privileged access
Grant an engineer time-boxed access to a single device/session for maintenance. No broad VPN, no shared jump host. Sessions close automatically.
End-to-end audit
Every session is logged with identity, device, policy and duration. You get an audit trail you can actually use in incident reviews and compliance checks.
Keep what works, remove what doesn’t
SecureNet layers on top of your existing platforms and APNs where needed. You can phase out flat tunnels at your pace while gaining control and visibility from day one.
Bottom line
VPNs join networks. Utilities need to join people and devices to tasks—briefly, narrowly and with proof. If you’re scaling AMI, substation automation or distributed energy, moving from flat tunnels to per-session, per-app access is the difference between “mostly fine” and “operationally safe”.
Next steps
-
Download the utilities edition of our guide to see the pattern, checklists and reference architecture.
-
Want to prove it? Request a test SIM and we’ll help you pilot just-in-time access on 10–20 sites.
