Your IoT devices are not laptops. VPNs were not built for them.
The VPN model assumes an endpoint that runs client software, holds a credential, and belongs to a person. A camera on a substation wall has none of those things. Neither does a smart meter, a charge point controller, or a fall-detection sensor in a care home. So the VPN gets pushed to the gateway or the site router, and the whole site ends up on one flat tunnel with broad network access. One compromised vendor laptop, and the tunnel is an open road.
This is the pattern most teams recognise by the time they have a few hundred devices in the field: the VPN did not fail on security review, it failed on arithmetic. Tunnels per site, IP ranges that collide between customers, and a support queue full of vendors who cannot reach the device they were sent to fix.
Four break points, in the order teams usually hit them.
There is also the compliance dimension. NIS2 Article 21(2) sets technical controls around access control, network segmentation, incident detection, supply chain access, and audit trail. A flat tunnel with shared credentials makes those controls hard to demonstrate, and NIS2 places accountability at board and C-suite level.
Zero Trust for IoT moves enforcement off the device and into the network and cloud. In IXT's model that means three separate things working together, and it is worth keeping them separate rather than blending them into a single claim.
The SIM identifies the device. SecureNet keeps traffic off the public internet using a private APN or DNN, private addressing, and direct connections into AWS, Azure, GCP, or Alibaba. The Zero Trust layer checks every session, using Zscaler ZTNA for connectivity and Illumio for traffic visibility and policy-based segmentation.
Practically: no exposed ports, device-initiated traffic only, no client installed on the device, and least privileged access so each device reaches the one application it needs.
Most teams have a diagram of intended traffic and no record of real traffic. Before you write a single policy, get a traffic map: every device, every destination, every protocol, every port. This is where Zero Trust Visualisation earns its place, and it is also where the surprises live. Firmware update servers nobody documented. A test MQTT broker still receiving production telemetry. Devices talking to each other for no designed reason.
Write the policy from observed traffic. Policy written from a diagram breaks on day one.
Zero Trust sits on top of private networking, not beside it. SecureNet takes the device off the public internet, so the traffic path is private before you start enforcing per-session policy on it. For a fleet on IXT SIMs this is a subscription change rather than a hardware visit. For a fleet on another provider, it is a SIM swap, which is the one step in this list that touches devices, and the reason eSIM or iSIM form factors are worth specifying on the next hardware revision.
Pick one site or one device class. Bring it up on the Zero Trust path with the VPN still in place. Compare the traffic map against the policy you wrote in step 1 and fix the gaps while there is a fallback. Teams that cut over a whole estate in one weekend spend the following month discovering undocumented traffic the hard way.
The instinct is to group devices by site, because that is how the VPN was organised. Group by what a compromise would reach instead. Charge points that touch the payment path belong in a different policy group to the ones that only report status. Micro-segmentation contains a breach to a single device and prevents lateral movement across the fleet, and that only holds if the groups reflect risk rather than geography.
This is usually the step that pays for the project. Privileged Remote Access replaces VPN-based vendor access with browser-based sessions: no client install on the vendor's machine, time-limited to a maintenance window, session-recorded, and scoped to the specific devices that vendor owns. A European EV charging operator with 8 hardware vendors gave each vendor access to their own chargers with no IP conflicts and no network access beyond the device in question.
You get a full audit trail of every device, every user, and every third-party contractor that accessed that device, including what actions they took.
Retire tunnels one device class at a time and keep the traffic map running afterwards. New firmware introduces new destinations. A device that starts reaching something outside its policy is either a legitimate change nobody told you about or the first sign of a problem. Anomaly detection on the traffic map is what turns that into an alert rather than a post-incident finding.
Being explicit here is more useful than over-claiming. Zero Trust does not replace a SIEM, a SOC, or an incident response function. It does not patch firmware or act as an MDM. Illumio-based visualisation maps IXT-connected devices, so non-IXT traffic stays outside the picture. Not every device type or protocol is supported without a technical assessment first.
And IXT Zero Trust does not make you NIS2-compliant on its own. It addresses the Article 21(2) technical controls. Risk documentation, incident response plans, staff training, and supplier governance remain yours.
No. Enforcement sits in the network and cloud rather than on the device. That is the point of delivering ZTNA through the SIM: headless devices that cannot run an agent get the same treatment as devices that can.
Standard Zscaler deployments reach endpoints that run an agent. IXT extends that same ZTNA to IoT and OT devices over cellular, which is the part existing deployments cannot reach.
It depends on how much of the traffic map is already known and whether devices need a SIM change. The traffic mapping and policy work is the long pole, not the cutover. Run it per device class rather than as one event.
A private APN hides traffic but does not defend it. It is still a flat network. Isolation without per-session policy and traffic visibility leaves both the lateral movement problem and the audit trail problem unsolved.
Most stop insisting once they see a browser session that needs no client install on their side. Where a vendor tooling dependency is real, scope a narrow path for that vendor and record the exception rather than reopening the tunnel for everyone.
IXT SIMs support NB-IoT and LTE-M, with regional availability confirmed per deployment. Low-power devices need particular attention to session behaviour and reconnection logic, so raise the power budget early in scoping.
Start with the traffic map. You cannot write policy for traffic you have not seen, and most teams find the first surprise within a day. Ask us how it works for your deployment, or book a demo at ixt.io.