Zero Trust IoT Security for Utilities: Why VPNs Are No Longer Enough
Lorem ipsum dolor sit amet, consectetur adipiscing elit.
From AMI 2.0 rollouts and substation automation to distributed energy resources at the grid edge, IoT is reshaping how utilities operate. Thousands of connected devices now sit across remote substations, pump stations, and metering infrastructure, transmitting sensitive operational data over cellular networks.
The problem is that most of this connectivity was never designed with security in mind.
One in three data breaches now involves an IoT device, according to Verizon. More than half of all IoT devices have vulnerabilities that attackers are actively exploiting (IBM). For utilities running critical infrastructure, these are not abstract statistics. They represent real exposure across systems that millions of people depend on every day.
The traditional response has been VPNs and private APNs. For years, these tools worked well enough. But as device fleets grow and threat levels rise, the security model built around perimeter trust is starting to break.
Zero Trust offers a different approach. One that treats every device and every connection as something that needs to be verified, not assumed safe.
This guide explains what that looks like in practice for utilities, where the biggest risks are, and how to start closing the gaps.
The security model utilities inherited
Most utility IoT deployments still rely on architectures designed in a different era. Site-to-site VPNs connect remote locations to central systems. Private APNs isolate traffic from the public internet. These approaches helped when the device count was manageable and the threat landscape was simpler.
The issue today is scale and exposure.
Smart grids, AMI 2.0, substation automation, and distributed energy are pushing millions of devices to the grid edge. Legacy APNs and flat site-to-site VPNs widen the blast radius when something goes wrong. They slow field work and make audits painful. Roaming gaps and SIM swaps add truck rolls and downtime.
As Marius Holmsen, security expert at Shift Security, put it in a recent conversation:
"We need to stop assuming anything is secure -- whether it's inside or outside. Every device, every connection must be validated."
The legacy model assumes that what is inside the network is safe. That assumption does not hold when devices sit in publicly accessible locations, when contractors need remote access, and when a single compromised endpoint opens a path to the rest of your OT environment.
Why Zero Trust is different
Zero Trust does not change the radio bearers or the core platforms you already run. What changes is how identity, policy, and access are enforced per device and per task, so the network stops being flat by default.
Instead of funnelling devices into one broad VPN tunnel, Zero Trust takes each connection and applies strict control. Every device is identified and validated. Every request is checked against policy covering time, location, application, and patch status. Access is granted only to the specific resource needed. Nothing more.
"Zero trust means we don't actually trust anyone -- not by default. We verify everything, every time." -- Marius Holmsen, Shift Security
This removes the traditional attack surface. There are no exposed endpoints and no open doors. Communication is initiated from inside-out, making it invisible to outside attackers.
Two pressures are making this shift urgent for utilities right now.
First, rising threat levels. Critical infrastructure including waste management, water, and energy is increasingly targeted by sophisticated actors. Many of these systems were deployed years ago without security as a design priority. They remain vulnerable today.
Second, regulation. The EU's NIS2 directive is now live, requiring operators of essential services in energy, transport, health, and digital infrastructure to meet stricter cybersecurity standards. This includes technical and organisational security measures, breach notification within 24 hours, and personal accountability for board members and senior management. (Read more: NIS2 and IoT Connectivity)
The five biggest risks in utility IoT deployments
Understanding where your current setup is exposed helps clarify where Zero Trust adds the most value. These are the risks that come up most often in conversations with utility operators.
1. Lateral movement through flat VPNs
With flat site-to-site VPNs, once someone is on the network, they often see far more than they should. RTUs, meters, gateways, and everything connected through that tunnel. A single compromised endpoint becomes a path into your entire OT environment.
The Target breach in the US is a well-known example. Attackers first gained access through an HVAC system vendor, then moved laterally through the company's IT systems. That story is over a decade old, but the pattern is still common in IoT setups today.
"That story is over 10 years old, but it's just as relevant today. Many IoT setups still expose themselves in exactly the same way." -- Marius Holmsen, Shift Security
The fix: Grant per-session, per-application access to a single device and close it automatically when the job is done.
2. Shared VPN credentials that never expire
Jump hosts and shared logins help in a pinch. Then they linger for months. Nobody is sure who touched what, and there is no audit trail that regulators or incident responders would find useful.
The fix: Named identities with multi-factor authentication for every engineer and contractor, plus time-boxed access windows. No shared credentials.
3. Operational traffic mixing with admin protocols
Operational protocols like IEC-104, DNP3, DLMS/COSEM, and MQTT end up riding next to open admin ports (web, SSH, SNMP) across a flat tunnel. This is unintentional exposure that creates opportunity for attackers.
The fix: Enforce device-level allow-lists. Only the protocols and FQDNs each device type needs. Default-deny everything else.
4. Coverage drops from single-profile roaming
Single-IMSI roaming locks devices to one network profile. When that network weakens, telemetry flaps and field teams get dispatched to fix connectivity problems that should never have occurred.
The fix: Use eUICC and multi-IMSI with policy-based steering and remote profile swaps so sites stay online across borders without truck rolls.
5. Logs that do not answer the hard questions
"VPN connected for 42 minutes" is not enough for NIS2 compliance or an incident review. Regulators and security teams need to know who accessed which device, with what protocol, for how long, and under which policy.
The fix: Capture session-level logs covering identity, device, time, and policy. Stream them to your SIEM for fast incident investigations.
What good looks like for utilities
When Zero Trust is implemented well, day-to-day operations should feel simpler, not more complex. Here is what that looks like in practice.
Identity comes first. Every device carries its own identity bound to the SIM or eUICC. Every user is named with multi-factor authentication. No identity, no entry.
Devices only communicate using the protocols they need, to the exact destinations you approve. IEC-104, DNP3, DLMS/COSEM, MQTT. Nothing extra gets through.
Maintenance access works per session. An engineer gets a single-use key for one device and one task. It expires automatically when the work is done. No standing access lingers in the background.
There are no flat tunnels joining entire networks together. Instead, thin, policy-controlled lanes open for the job at hand and close when it is complete.
And every session leaves a clear audit trail. Who did what, when, and under which policy. This is the kind of evidence that satisfies both internal security reviews and regulatory obligations.
Zero Trust in action: utility use cases
Advanced metering (AMI 2.0)
The risk: With flat VPNs, a simple meter room quietly exposes web and SSH on hubs. Brittle IP allow-lists block perfectly valid reads while leaving unnecessary ports open.
A better approach: Give each device a SIM/eUICC-bound identity and only allow DLMS/COSEM traffic to the MDM. When maintenance is needed, open a short, single-device session and close it automatically.
Substation maintenance
The risk: Shared jump hosts and broad tunnels mean one login gives access to the whole subnet.
A better approach: Approve a named engineer with MFA for one device, one protocol (IEC-104 or DNP3), and one time window. The session expires on its own and leaves a clean audit trail.
DER onboarding (solar and battery)
The risk: During commissioning, wildcard endpoints and "temporary" rules tend to stick around long after the work is finished.
A better approach: Bind identity at scan, then allow MQTT only to the named broker. The commissioning path closes on sign-off. Nothing stays open by accident.
Temporary works and outages
The risk: Teams grant blanket VPN access to move fast during outages, then lose track of who did what.
A better approach: Use a predefined "temporary works" policy with single-device, time-boxed access and enhanced logging. Revoke it the moment the job is done.
The regulatory pressure is here
The regulatory environment for IoT is no longer abstract or advisory. NIS2 is now in effect across EU member states, and it applies directly to the way utilities secure their connected infrastructure.
Under NIS2, operators of essential services must prevent, detect, and limit the impact of security incidents. They must enforce access control and reduce implicit trust. They must manage supply chain and third-party access risk. And they must demonstrate effective security measures and governance to regulators.
For utilities relying on VPNs and basic APNs for their IoT connectivity, meeting these requirements is difficult without changing the underlying security model.
Beyond NIS2, GDPR continues to require encryption and jurisdictional control over personal and usage data collected by IoT systems. Permanent roaming laws in countries like Brazil, Turkey, India, and China are enforcing strict limits on roaming SIMs, creating disconnection risks for deployments without local profiles. And the upcoming EU Cyber Resilience Act will require IoT products to meet security-by-design standards.
Board members and senior management now carry personal accountability for compliance. This is not a technical concern you delegate to the network team. It is a governance issue.
How to start thinking about the shift
Zero Trust is not a product you install on a Tuesday morning. It is a shift in how identity, policy, and access are enforced across your connected infrastructure.
The good news is that it does not require ripping out everything already in place. As Marius Holmsen put it:
"You don't have to replace all your equipment. What's important is securing each device and its connection. That's where zero trust changes the game."
The shift starts with understanding where your current setup leaves gaps and where a per-device, per-session approach removes the most risk.
For utilities, the practical starting points are clear. Get third-party access under control. Move from shared VPN credentials to named, time-limited sessions. Enforce protocol-level policies on device communications. And build the audit trail that NIS2 and your own incident teams will need.
Connectivity is the layer that ties all of this together. If your SIM-based connectivity provides reachability without security, visibility, or segmentation, it becomes part of the attack surface rather than part of the defence.
Watch the webinar: Zero Trust security in IoT
Want to go deeper? Watch our on-demand webinar where Henning Solberg, Founder and CTO of IXT, and Stefan Drees walk through how Zero Trust applies to real-world IoT deployments, including the technical architecture and practical implementation steps.
Frequently asked questions
Does Zero Trust replace our existing VPN or APN setup?
It does not require you to rip out your current infrastructure overnight. Zero Trust shifts the model from broad network tunnels to per-session, application-specific access. This removes exposed endpoints and reduces lateral movement. Many organisations adopt it alongside existing connectivity and migrate gradually.
How do contractors and third-party vendors get access without a shared VPN?
Each contractor receives a named identity with multi-factor authentication. Access is approved for a specific device, a specific protocol, and a defined time window. The session runs through a browser, so there is no VPN client to distribute. It expires automatically and leaves a full audit trail in your SIEM.
What protocols and destinations can we control?
You define policies per device type. For example, meters communicate using DLMS/COSEM to a named MDM endpoint. RTUs use IEC-104 or DNP3 to specific masters. Gateways use MQTT to a named broker. Everything else is denied by default.
Does this work for devices that cannot run security software?
Yes. Zero Trust enforcement happens at the network and SIM level, not on the device itself. This makes it suitable for headless IoT devices, legacy equipment, and constrained hardware that cannot support VPN clients or security agents.
How does this relate to NIS2 compliance?
NIS2 requires operators of essential services to enforce access control, reduce implicit trust, manage third-party risk, and demonstrate security governance. Zero Trust SIM connectivity directly supports these requirements through network segmentation, identity-based access, session logging, and policy enforcement at the edge.
About IXT
IXT is a full MVNO built for IoT, operating its own core network across 600+ mobile networks in 190+ countries. The company delivers secure, scalable connectivity for enterprises deploying connected devices in regulated and security-sensitive industries. Learn more at ixt.io.