Cross-border cellular IoT deployments face three problems at once. Carrier networks differ by country. National rules govern roaming duration and where data lives. And the devices themselves run no security agent, so they defend nothing on their own.
Securing a global fleet in 2026 rests on four layers: device identity anchored in the SIM, traffic routed through a private APN instead of the public internet, Zero Trust so every session is device-initiated with no exposed ports, and real-time fleet visibility that produces the audit evidence NIS2 asks for. This guide covers each layer, the country-level constraints that apply, and a reference architecture for global deployments.
A device you ship to Poland behaves differently from the identical device in Brazil. Different carrier. Different NAT behaviour. Different DNS resolution. Different national rules on how long a foreign SIM stays attached to the local network.
Your security policy was written once. The network underneath it changes at every border.
That gap is where most global IoT security failures start. Not in the device firmware, and not in the cloud. In the connectivity layer between them, which most teams treat as plumbing instead of as part of the security architecture.
The exposure is well documented. Palo Alto Networks, in its 2025 Device Security Threat Report covering more than 27 million connected devices across 1,803 enterprise networks, found that 98% of IoT traffic travels unencrypted and around 21% of IoT devices carry at least one known vulnerability. The average enterprise in that dataset ran roughly 35,000 devices across 80 device types.
Now spread that estate across fifteen countries and four carriers.
Four failures typically show up after rollout, not before it.
Address assumptions stop holding. Roaming changes how network address translation behaves. The IP ranges you allowlisted in testing are not the ranges your devices present in production. Teams respond by widening the allowlist until it stops meaning anything.
Private APN behaviour diverges by carrier. Features you relied on with one operator work differently with the next. What looked like one policy becomes fifteen exceptions.
VPN backhaul introduces latency and a single point of failure. Routing traffic from Chile to a concentrator in Frankfurt adds hundreds of milliseconds and one more thing to break. Worse, being inside the tunnel becomes a proxy for being trusted.
Audit evidence does not exist. Someone asks for per-region proof of who accessed which device and when. You are stitching together carrier logs, jump host records and firewall exports by hand.
Treat the ICCID and the IMEI as inventory markers, not credentials. Both are visible, both are recorded across multiple carrier systems, and neither proves anything about the device presenting them.
Real device protection starts with a cryptographic identity anchored in hardware the device does not export. A secure element works. The SIM works, and for cellular fleets it has an advantage the secure element does not: it is already the thing the network authenticates.
For cross-border fleets, that identity has to survive a change of carrier. Two technologies do the work.
Multi-IMSI lets a single SIM hold several network identities and select the strongest available local network without physical access to the device. eUICC lets you provision and switch operator profiles over the air, which matters where a country restricts how long a foreign SIM operates on local networks.
The point is not redundancy for its own sake. It is that the device keeps one stable identity while the network underneath it changes. Your policy binds to the identity, not to the carrier.
A device reachable from the public internet is a device being scanned right now. Shodan indexes the ones with open ports. Automated scanners find the rest within hours of first attachment.
A private APN removes the device from that surface entirely. Traffic leaves the radio network and lands inside a private, isolated path that carries it to your data centre or cloud environment without touching public infrastructure. Add static private IPs and the device becomes invisible to anything outside that path.
For cloud-native architectures, direct connections to AWS, Azure, GCP or Alibaba remove the backhaul detour. Traffic lands in the nearest compliant region instead of crossing three continents to reach a central hub.
One caution. Private networking gives you isolation. It does not give you visibility. An isolated APN tells you nothing about what your devices are talking to inside it, which is the specific evidence a NIS2 auditor asks for. Isolation and Zero Trust answer different questions, and a global deployment needs both from the start. Retrofitting the second one after an audit finding is how most teams end up doing it twice.
Standard Zero Trust assumes an endpoint that runs software. A laptop installs a client, the client checks posture, the broker grants access to one application. That model has been settled in IT for years.
IoT breaks it. A sensor with 256KB of RAM runs no agent. A headless controller in a substation runs no agent. An EV charger runs no agent. Which is why most Zero Trust programmes stop at the edge of the OT estate and leave the devices with the weakest defences outside the architecture.
The fix is to move enforcement off the device and into the network the device is already authenticating to.
Zero Trust Connectivity, delivered through the SIM, makes all traffic device-initiated. No ports are exposed. No VPN client sits on the device. Policy sits at the network edge, globally, and travels with the device across borders because it binds to identity and not to location.
Zero Trust Visualisation adds the layer isolation alone lacks. The gateway captures and maps every session passing through it. Normal device communication renders as expected traffic. A device reaching a destination it has never contacted before triggers an alert. From that map you apply policy-based segmentation, so a compromised device reaches nothing beyond what it was authorised to reach.
The two components work together. One removes the attack surface. The other shows you what is happening inside what remains.
Ask a global operations team how a service technician in Spain reaches a controller in Romania. The honest answer is a VPN account, shared credentials, and access to more of the network than the job requires.
Verizon's 2024 Data Breach Investigations Report tracks breaches that originate through a third party. [INSERT SOURCE DATA: exact third-party breach share from the 2024 DBIR. Do not publish this sentence without the figure.] In OT environments the pattern repeats: someone compromises a vendor laptop, the vendor holds broad network access, and the blast radius becomes the whole estate.
Privileged remote access built on Zero Trust removes the account entirely. The technician authenticates through a browser, opens an SSH, VNC or RDP session to one specific device, and works inside a session that is time-limited, recorded, and viewable by an employee in real time. When the window closes, the path closes. Nothing was installed on the device, and nothing was granted beyond the one asset.
That session log is also the supplier access evidence NIS2 asks for. One record, per session, per device, without anyone reconstructing it from a jump host.
Two national constraints govern global fleets, and both are operational, not theoretical.
Permanent roaming limits. Several countries restrict how long a foreign SIM operates on local networks before it has to localise or disconnect. Brazil applies a limit measured in months, Turkey requires device IMEI registration within a set window, and India permits a longer but finite period. When a device is cut off for a roaming violation, the failure looks identical to a hardware fault, which is why it takes weeks to diagnose. eUICC with local profile provisioning resolves it without a truck roll.
Data residency. GDPR governs personal data in the EU. Other jurisdictions set their own rules on where industrial and personal telemetry is processed. The architectural answer is to separate residency from security. Land traffic in the nearest compliant region using direct cloud connections, process it there, and replicate summaries onward. Security stays at the session and identity layer, applied identically everywhere.
NIS2 Article 21 sets out ten minimum risk-management measures, among them risk analysis, incident handling, supply-chain security, access control, encryption and multi-factor authentication. Penalties reach EUR 10 million or 2% of global turnover for essential entities.
Four of those measures land directly on the connectivity layer of a cellular IoT deployment.
Access control and MFA map to Zero Trust device identity and brokered sessions. Supply-chain security maps to how third-party technicians reach your devices. Encryption maps to what happens to traffic between the device and your application. Incident handling maps to whether you detect an anomaly in real time or find it in a log review three weeks later.
A note on honesty here. No connectivity provider certifies your NIS2 compliance. IXT included. The controls support the requirements. The compliance posture stays yours.
Put together, a defensible global cellular IoT deployment looks like this.
The device holds a cryptographic identity anchored in the SIM, with multi-IMSI for network resilience and eUICC for compliant localisation. The device initiates every connection outbound, with no listening ports and no inbound path.
That traffic lands in a private APN instead of the public internet, and routes through a direct cloud connection to the nearest compliant region. Mutual TLS protects the application session on top of that private path, so an intermediary sees nothing readable.
Zero Trust policy sits at the network edge and follows the device across borders. The platform maps every session and flags every anomaly in real time. Third-party access runs through time-limited, recorded, clientless browser sessions to individual assets.
Above all of it, a connectivity management platform gives live status, usage and event data across the whole fleet, with API access so the data feeds your own systems and your SIEM.
Four properties define whether the architecture holds: predictable connectivity, verified identity, one policy applied everywhere, and visibility you did not have to reconstruct.
IXT is a full MVNO with its own IoT core network. Not a reseller layer over someone else's platform. That means routing, policy and troubleshooting sit with IXT and not with a third-party carrier, which matters most at the moment a device in another country stops behaving.
The IXT Global SIM reaches 600+ mobile networks across 190+ countries, with multi-IMSI and SIM, eSIM or iSIM form factors. IXT SecureNet delivers the private APN, static IP and direct cloud connections to AWS, Azure, GCP and Alibaba. IXT Zero Trust is the standard security offering, combining Zscaler ZTNA and Illumio-powered visualisation delivered through the SIM, with no client software on the device. The IXT CMP shows fleet status in real time, where several competing platforms report usage on a 24 to 48 hour delay.
Global IoT security is not a device problem or a cloud problem. It is decided in the connectivity layer between them.
Request a test SIM and see how the architecture behaves on your own devices.
Anchor device identity in the SIM so it survives a change of carrier, route traffic through a private APN instead of the public internet, apply Zero Trust so all sessions are device-initiated with no exposed ports, and monitor the fleet in real time. Multi-IMSI and eUICC keep the device connected and locally compliant as it crosses borders, while policy stays bound to identity and not to location.
Devices exposed to the public internet, followed closely by third-party remote access. Palo Alto Networks reports that 98% of IoT traffic travels unencrypted. A device with an open port is scanned within hours of first attachment, and a vendor VPN account with broad network access turns one compromised laptop into an estate-wide incident.
A VPN encrypts transit, and it leaves the device on public infrastructure with network-level trust attached to the tunnel. Anyone inside reaches everything the tunnel reaches. A private APN removes the public internet from the path, and Zero Trust replaces network-level trust with per-session authorisation to individual assets.
IT Zero Trust depends on agent software installed on the endpoint. Headless IoT and OT devices run no agent and have no capacity to run one. Enforcement has to move into the network the device already authenticates to, which is why delivering ZTNA through the SIM reaches devices that agent-based deployments never will.
Several countries restrict how long a foreign SIM operates on their networks before it must localise. When the limit is reached the device is disconnected, and the symptom looks like hardware failure, not a policy event. eUICC with remote profile provisioning localises the device over the air, keeping it connected and compliant without physical access.
It supports the controls NIS2 Article 21 asks for in access control, supply-chain security, encryption and incident handling, and it produces the audit evidence those measures require. No connectivity provider certifies NIS2 compliance on your behalf. The posture remains the customer's responsibility.