How multi-IMSI and eUICC support IoT compliance

Multi-IMSI and eUICC reduce permanent roaming risk in different ways. How each supports IoT compliance, where each stops, and what to check first.

Your devices passed certification, shipped on time, and connected on day one. Eighteen months later, a group of them in one country stops attaching. Nothing changed in the hardware. The host operator changed its roaming policy, or a regulator started enforcing a rule that was on the books all along.

 

That is the permanent roaming problem. A device that lives on a foreign SIM in one country indefinitely is roaming permanently, and a growing number of regulators and operators treat that as something to limit or stop. Multi-IMSI and eUICC are the two SIM-level tools most teams reach for. They solve different parts of the problem, and neither one is a compliance guarantee by itself.

 

 

Why permanent roaming is a compliance question

Roaming was designed for travellers. A phone visits a network for days or weeks and leaves. An IoT device installed in a smart meter, a charger, or a vending machine visits and never leaves. From the host network's point of view, that device uses local spectrum and infrastructure under a wholesale agreement that was never priced or regulated for permanent residence.

 

Three kinds of rule create the risk:

 

  • national regulation that restricts or bans permanent roaming, or requires a locally issued number after a set period
  • operator contracts that allow roaming but cap its duration, or reserve the right to disconnect permanent roamers
  • sector and data rules that expect subscriber records or certain traffic to sit with a local, licensed provider

 

Brazil and Turkey are among the markets most frequently cited for restrictions. The rules change and enforcement varies, so check the current position for every country in your rollout plan instead of relying on a list. The underlying point holds everywhere. If your connectivity model depends on a foreign identity staying on a local network forever, you carry a risk you do not control.

 

 

How multi-IMSI addresses it

An IMSI (International Mobile Subscriber Identity) is the subscriber identity stored on the SIM. It tells a network which operator the SIM belongs to. A multi-IMSI SIM holds several of these identities from different operators. An applet on the SIM, or a rule set managed by the provider, decides which one to use.

 

For compliance, the logic is direct. When a device operates in a market where a local or regionally accepted identity exists, the SIM switches to that IMSI. The device then attaches as a local or preferred subscriber instead of a permanent roamer. When it moves, or when that identity loses coverage, the SIM switches again.

 

Multi-IMSI fits well when:

  • your provider already holds identities in your target markets
  • devices move between countries, as in logistics, fleet, and maritime deployments
  • you want the switch to happen over the air, without touching the device

Its limit is the identity set itself. A multi-IMSI SIM carries only the identities its provider has agreements for. If a new market requires a local identity the provider does not hold, the SIM has nothing to switch to.

 

 

How eUICC addresses it

eUICC (embedded Universal Integrated Circuit Card) is the remote provisioning standard defined by the GSMA. Instead of fixed identities, an eUICC stores full operator profiles and accepts new ones remotely. You download a local operator's profile to a device in the field and activate it. No site visit. No card swap.

 

For compliance, eUICC answers the question multi-IMSI leaves open. When a regulator requires a locally issued subscription, you provision one. When an operator contract ends, you move the fleet to a different profile. The GSMA's SGP.32 specification, written for IoT devices with no screen and no user, makes that remote provisioning workable for headless devices across a whole fleet.

 

eUICC has its own constraints:

  • each local profile needs a commercial agreement with that operator, and someone has to manage those agreements
  • a profile change is a planned operation, not an automatic failover
  • older modules and SIMs do not support SGP.32, so hardware you choose today decides what you are able to do later

 

 

Multi-IMSI and eUICC side by side

How the change happens

Multi-IMSI switches identity automatically, based on rules. eUICC changes profile as a deliberate action that you or your provider trigger.

 

 

Who holds the operator relationships

With multi-IMSI, your provider holds the agreements behind each identity. With eUICC, you or your provider sign a local agreement for each profile you download.

 

 

Where each fits

Multi-IMSI suits devices that move, and fleets spread thinly across many countries. eUICC suits large stationary deployments in a restrictive market, where a local subscription is the only compliant route.

 

 

Where they combine

The two are not exclusive. A multi-IMSI applet runs inside an eUICC, so a device uses rule-based switching day to day and receives a new local profile when a market demands one.

 

 

What the SIM does not solve

Staying on the right network identity is one part of compliance. It says nothing about where your traffic goes, who reaches the device, or what records you keep. A device on a compliant local profile still sends data across the public internet unless the routing behind it is private. It still accepts connections from anyone who finds an open port unless access is controlled in the network.

Keep those layers separate when you plan. The SIM identifies the device and decides which network it joins. Private networking keeps traffic off the public internet. A Zero Trust layer in the network and cloud checks every session. Monitoring shows, per SIM, which identity is active and where. Regulators and auditors ask about all four.

 

 

Questions to ask before you commit

  • Which markets in your rollout plan restrict permanent roaming today, and who tracks changes?
  • Which local or regional IMSIs does your provider hold in those markets?
  • Do your modules and SIMs support SGP.32 remote provisioning?
  • Who signs and manages local operator agreements if you need eUICC profiles?
  • How will you see, per SIM, which identity or profile is in use?

 

 

How IXT approaches it

IXT runs its own mobile core built for IoT, with access to 600+ mobile networks across 190+ countries. IXT supports local IMSI options in key markets to reduce permanent roaming risk. The IXT Global SIM comes as SIM, eSIM, or iSIM, so the form factor matches your hardware.

 

The IXT CMP shows every SIM in real time, including status, usage, and location. Many platforms work with a 24-48 hour data delay. SecureNet and IXT Zero Trust sit on top for the routing and access questions the SIM does not answer.

 

Roaming rules differ by country and change with little warning. Plan for that from the first device, not the first disconnection. Ask us how it works for your deployment.

 

 

Why trust this guide

This guidance is based on real IoT and OT deployments in regulated industries including energy, utilities, and industrial environments.

 

IXT designs and operates secure connectivity architectures where:

  • devices are deployed across multiple countries and networks
  • SIM-level identity is enforced at the network edge
  • third-party access is controlled without VPNs
  • audit trails are required for regulatory compliance (including NIS2)

The patterns described here reflect how these environments are secured in practice, not theoretical models.

 

 

About the author

This article was written by the IXT Connectivity and Security team.

 

IXT operates a full MVNO core network and delivers secure IoT connectivity across 190+ countries and 600+ mobile networks. The team works directly with industrial, utilities, and infrastructure operators to design and secure large-scale IoT and OT deployments.

 

Their focus is on network-level Zero Trust architecture, SIM-based identity, and secure device communication without relying on VPNs or endpoint agents.