Blog

How to build IoT connectivity without permanent roaming

Written by IXT | 19. aug. 2026, 11:50:52

You shipped 8,000 devices into a market on a roaming SIM. They worked for 11 months. Then a regulator sent your carrier's local partner a notice, the partner cut the roaming agreement, and your fleet went dark in a country where you have customers under contract.

 

Nobody made a mistake in that story. The devices were provisioned correctly, the SIMs were the ones the supplier recommended, and the coverage map said the country was covered. Roaming was designed for a phone crossing a border for 2 weeks. A device that never comes home is a different thing, and a growing number of regulators treat it that way.

 

This guide covers where permanent roaming creates exposure, and how to design connectivity that does not depend on it.

 

 

What permanent roaming means, and why regulators care

Roaming lets a subscriber from one network use another operator's network abroad. The commercial and regulatory framework behind it assumes the visit ends. Permanent roaming is what happens when it never does: a device provisioned on a home network in one country, installed in a second country, and left there for its entire 8 or 10 year service life.

 

Three reasons regulators push back on this.

 

Lawful intercept and data jurisdiction. A permanently roaming device routes signalling and often user traffic through a foreign core network. National authorities lose the visibility their legislation assumes they have over communications inside their borders.

 

Numbering and licensing. A device living permanently in a country consumes local network resources without a local subscription, local numbering, or a licensed local operator taking responsibility for it.

 

Emergency services and quality obligations. Local operators carry obligations tied to subscribers. A foreign IMSI sitting on their network indefinitely falls outside that accounting.

 

None of this arrives as a single global rule. It arrives as national telecoms law, enforced unevenly, and revised without much notice.

 

 

How the restriction reaches you in practice

The enforcement is rarely a letter to you. It reaches your fleet through your provider's roaming agreements, which is why teams get surprised.

 

Some markets set a hard time limit, and devices get deregistered after a fixed number of days on the network. Some require a local operator relationship for any device in permanent service, which means your provider needs a local agreement or your devices need a local identity. Some markets enforce nothing on paper and enforce plenty in practice, where the local operator throttles or drops foreign IMSIs that never leave. And some restrict specific technologies rather than roaming outright, with NB-IoT and LTE-M roaming unavailable in markets where 4G roaming works fine.

 

Markets commonly cited in permanent roaming discussions include Brazil, Turkey, India, China, Canada, Saudi Arabia, the United Arab Emirates, and Vietnam. The rules move, the interpretations differ by operator, and the only reliable answer is a current one from a provider who holds the agreements in that market.

 

 

Designing connectivity that does not depend on permanent roaming

Five design decisions carry most of the weight. Take them in this order.

 

1. Map your deployment countries against your device lifecycle before you choose a SIM

List every market you sell into now, and every market on the 24-month roadmap. Against each one, record the expected device dwell time, the radio technology the hardware supports, and whether the device is reachable for a site visit after installation.

That last column is the one teams skip, and it decides everything downstream. A device on a wall 40 metres up a wind turbine, or sealed inside a charger enclosure, is a device whose connectivity has to be changed remotely or not at all.

 

 

2. Choose a SIM that holds more than one network identity

A single-IMSI SIM has one home network and one set of roaming agreements. When that agreement changes in a market, you have no second path.

 

Multi-IMSI SIMs hold several operator identities on one physical SIM and switch between them. If one identity loses access in a market, the device falls back to another. For markets where a local identity is available, a multi-IMSI SIM presents a local IMSI rather than a foreign one, so the device is not roaming at all. IXT supports local IMSI options in key markets to reduce permanent roaming risk.

 

The trade-off worth knowing: switching identities takes time, and a device deep in a sleep cycle recovers more slowly than a mains-powered one. Design your reporting intervals with a failover window in mind.

 

 

3. Use eUICC so profiles change without a site visit

eUICC is the standard that makes a SIM's operator profile remotely rewritable. It is what turns a connectivity change from a truck roll into an over-the-air operation.

 

For IoT specifically, GSMA SGP.32 is the specification that matters. Earlier remote provisioning standards were built around either consumer devices with a user interface or machine-to-machine models that assumed a heavyweight platform relationship. SGP.32 was written for constrained devices with no screen and no user, and it lets the device owner rather than the operator drive profile changes.

 

Specify eUICC hardware at design time even if you launch on a single profile. Retrofitting it means touching every device in the field, and that cost lands years after the decision that caused it.

 

 

4. Keep traffic off the public internet and out of the wrong jurisdiction

Regulatory exposure on permanent roaming is partly about where traffic goes, not only about which IMSI is attached. A device in Germany whose data transits a core network in a third country creates a question your compliance team will eventually have to answer.

 

Private networking answers it directly. IXT SecureNet routes device traffic privately to your data centre or into AWS, Azure, GCP, or Alibaba, without crossing the public internet. Combined with local IMSI options, the traffic path becomes something you describe accurately in an audit rather than something you infer from a coverage map.

 

 

5. Instrument the fleet so you see a market degrade before your customers do

Permanent roaming problems announce themselves as a slow rise in attach failures in one country, weeks before the outage. That signal is visible in session data and invisible in a monthly usage report.

 

The IXT CMP shows every SIM in real time: status, usage, location, and session logs, with threshold alerts per group. Many provider portals report on a 24 to 48 hour delay. When a market starts failing, 48 hours is the difference between a controlled profile switch and an incident review.

 

 

What this looks like across 3 industries

Electric vehicle charging. Chargers ship from one factory into 15 markets and stay installed for a decade. Permanent roaming risk is concentrated because the hardware is identical everywhere and the installed base is immovable. eUICC plus local IMSI options where they exist is the practical route.

 

Utilities and smart metering. Meters have 15-year service lives, sit in basements, and belong to a regulated operator with reporting obligations. Local connectivity is close to mandatory in several markets, and NB-IoT roaming availability has to be checked market by market rather than assumed.

 

Industrial equipment and machinery. Machines are sold, not deployed, so the manufacturer rarely knows the destination country at the point of manufacture. This is the strongest case for eUICC: ship one hardware configuration worldwide and set the profile once the machine reports its location.

 

 

Frequently asked questions

Which countries restrict permanent roaming for IoT?

There is no single authoritative list, because each restriction sits in national telecoms law and gets enforced through operator agreements. Brazil, Turkey, India, China, Canada, Saudi Arabia, the United Arab Emirates, and Vietnam come up most in these conversations. Verify your specific markets with a provider who holds current agreements there, and re-check before each market launch.

 

 

How long is a device allowed to roam before it counts as permanent?

The thresholds vary, from around 90 days in some markets to a commercial judgement made by the visited operator in others. Rather than designing to a threshold, design so that no market depends on roaming for the full device lifetime.

 

 

Does multi-IMSI remove permanent roaming risk on its own?

It reduces it. Multi-IMSI gives you an alternative path when one operator relationship changes, and a local identity where one is available. In markets where no local identity exists, the device is still roaming, and the mitigation is a fallback rather than a fix.

 

 

What is the difference between multi-IMSI and eSIM here?

Multi-IMSI holds several identities and switches between them at the network level. eSIM with eUICC rewrites the operator profile itself, remotely. They solve adjacent problems and work well together: multi-IMSI handles day-to-day resilience, eUICC handles a market-level change of provider without a site visit.

 

 

Can we keep using roaming SIMs where nothing has gone wrong yet?

Plenty of fleets do. The exposure is that the decision sits with a foreign operator's commercial team rather than with you, and the notice period is short. For markets carrying contractual uptime commitments, that is a thin position to hold.

 

 

Does any of this make us NIS2-compliant?

No. Local connectivity and private routing address technical controls, and IXT Zero Trust addresses NIS2 Article 21(2) controls including access control, segmentation, incident detection, and audit trail. Risk documentation, incident response, staff training, and supplier governance stay with you.

 

 

Where to start

Take your 3 largest markets by installed base. For each one, establish whether your devices are on a local or a foreign IMSI today, whether the hardware supports eUICC, and how long a profile change would take if the roaming agreement ended next quarter. If any of those 3 answers is unknown, that is the work.

 

Ask us how it works for your deployment. Book a demo at ixt.io