Permanent roaming rules for IoT in 2026

Which markets restrict permanent roaming for IoT, why devices get disconnected, and how multi-IMSI, eUICC, and local profiles keep deployments compliant.

The devices worked for nine months. Then a regional carrier ran its housekeeping, and 400 units in one market stopped attaching on the same afternoon. Nothing changed in your firmware. Nothing changed in your platform. A roaming agreement reached its limit.

Permanent roaming is the constraint that catches teams after deployment rather than during procurement. It is a regulatory and commercial question that lands as a hardware problem, which is why it is worth designing around before the first unit ships.

 

 

What is permanent roaming?

Roaming exists so a subscriber from one country gets service while visiting another. It assumes the visitor goes home. An IoT device does not. A sensor installed in Spain on a SIM from another country roams there for its entire operating life, which is 5, 10, or 15 years.

 

Permanent roaming is that state: a device attached indefinitely to a visited network it never leaves. Regulators and carriers restrict it for three reasons.

 

  • Lawful intercept and data sovereignty. A device generating traffic inside a jurisdiction while subscribed to a foreign network sits outside that regulator's reach.
  •  
  • Numbering and licensing rules. National frameworks assign spectrum and numbering to licensed local operators serving local subscribers.
  •  
  • Commercial balance. A visited network carries capacity and support cost for a device that never becomes its customer.

 

How restrictions actually arrive

The rules reach your fleet through three different mechanisms, and the difference matters when you plan.

 

 

Regulatory prohibition

The national regulator bars foreign SIMs from operating permanently in-country. Compliance is not negotiable through your provider, and the remedy is a local subscription identity. Brazil is the most cited example, where Anatel rules require local connectivity for devices operating on a permanent basis.

 

 

Local presence or licensing requirements

Service is available, but only through a locally licensed operator or a local partnership. India and China both work this way in practice, so multi-country deployments need a local profile or a local partner arrangement rather than an inbound roaming SIM.

 

 

Carrier policy limits

No regulation prohibits the device, but the visited network applies a time window in its roaming agreements. A 90-day window is the common pattern, after which the SIM is barred, throttled, or flagged for review. This is the mechanism behind most sudden mid-life disconnections, because it fires quietly and per-carrier.

 

 

Markets to check before you commit hardware

Restrictions and enforcement change from year to year, and enforcement varies between carriers inside the same market. Treat the list below as a prompt to verify rather than a table to trust.

 

  • Latin America: Brazil is the strictest. Others in the region apply local licensing conditions.
  •  
  • Asia: India, China, Vietnam, Indonesia, Singapore, and Japan all apply local presence requirements or defined roaming windows.
  • Middle East: the UAE, Saudi Arabia, Qatar, Oman, and Kuwait apply local licensing conditions or restrict inbound permanent roaming.
  •  
  • Turkey and Israel: both apply defined limits on foreign SIMs operating in-country.
  •  
  • North America: driven by carrier policy rather than regulation, with time-window enforcement written into roaming agreements.
  • Australia and parts of Africa: carrier policy limits, with enforcement varying by operator.
  •  

Confirm the current position for each market with your connectivity provider before you commit hardware, and get the answer in writing per market rather than as a global assurance.

 

 

How permanent roaming failures show up in your deployment

The failure is rarely announced. Four signatures are worth recognising.

 

  • A cohort of devices deployed in the same window stops attaching together, because they crossed the same threshold on the same day.
  •  
  • Devices reattach after a power cycle, then drop again days later, because the bar is applied per attach rather than permanently.
  • One market degrades while every other market runs normally, which points at a single roaming agreement rather than your platform.
  •  
  • Nothing appears in your application layer at all, because a device that never attaches sends no error.
  •  

The last one is the expensive one. A truck roll to a wind turbine, a substation, or a vessel costs multiples of the connectivity itself.

 

 

The four ways to design around it

1. Multi-IMSI

One SIM holds several operator identities and switches between them. When one network bars the device or an agreement lapses, the SIM attaches through another identity in the same market. This removes single-carrier dependency and adds resilience against outages that have nothing to do with roaming rules.

 

Multi-IMSI works within the agreements available to your provider. It handles carrier policy limits well. It does not create a local subscription where a regulator requires one.

 

 

2. eUICC and remote SIM provisioning

An eUICC accepts new operator profiles over the air after the device is in the field. Where a market later demands a local identity, you download a local profile rather than sending a technician. GSMA SGP.32 defines the IoT variant of this and removes the assumption that a person is present to accept the change, which the earlier consumer specification carried.

 

Design consideration: the device must reach the provisioning service to receive a profile. A device already barred from attaching cannot download the profile that would fix it, so provisioning has to be planned before the block, not after.

 

 

3. Local profiles and localisation

For markets with genuine regulatory prohibition, a local subscription is the answer. That means an in-country IMSI so the device is a local subscriber rather than a permanent visitor. IXT supports local IMSI options in key markets to reduce permanent roaming risk.

 

 

4. Design the hardware for the option you have not needed yet

The decisions that trap teams are made at hardware selection. Specify an eUICC-capable form factor, whether SIM, eSIM, or iSIM, even if you launch on a single roaming profile. Confirm the radio bands and technologies in every target market, since LTE-M and NB-IoT availability varies. Retrofitting a SIM form factor across a deployed fleet is the most expensive fix on this page.

 

 

Comparing the approaches

 

Approach Solves Does not solve
Single roaming profile Fast launch, one commercial relationship Carrier windows, regulatory prohibition, carrier outages
Multi-IMSI Carrier policy limits, single-carrier outages, coverage gaps Markets requiring a local subscriber identity
eUICC with remote provisioning Changing rules after deployment, operator switching Devices already barred before a profile is delivered
Local profile in-market Regulatory prohibition, data residency expectations Operational simplicity, since more relationships are in play

 

 

 

A practical sequence for a multi-country rollout

  1. List every market for the full device lifetime, including the ones on the three-year roadmap.
  2.  
  3. Classify each one: regulatory prohibition, local presence requirement, or carrier policy limit.
  4.  
  5. Ask your provider, per market, which identity the device will use and how long it holds.
  6.  
  7. Choose an eUICC-capable form factor before hardware sign-off.
  8.  
  9. Set fleet alerting on attach failures by market and by cohort, not on data usage alone.
  10.  
  11. Review the market classifications annually, because rules and enforcement move.

 

 

Where visibility earns its place

Every mitigation above depends on knowing what happened, and when. Many connectivity platforms report on a 24 to 48 hour delay, which turns a roaming bar into a mystery that plays out over a week. IXT's CMP shows every SIM in real time: status, usage, location, and session logs, with alerting per group. When a cohort in one market stops attaching, that pattern is visible the same hour rather than at month end.

 

IXT runs a dedicated mobile core built for IoT from the ground up rather than a virtualised platform on shared infrastructure, with coverage across 600+ mobile networks in 190+ countries. That gives direct control over routing and policy, and it is why the roaming question is answered per market rather than as a single global claim.

 

 

Frequently asked questions

Which countries restrict permanent roaming for IoT?

Brazil, India, China, Turkey, and several Gulf markets are the most frequently flagged, alongside carrier-enforced windows in North America, Japan, Singapore, Vietnam, and parts of Africa and Oceania. Rules and enforcement change, so verify each target market at design time rather than working from a published list.

 

 

How long before a device is treated as permanently roaming?

A 90-day window written into the roaming agreement is the common pattern, though some carriers apply longer or shorter thresholds and some markets prohibit foreign SIMs outright. The threshold sits with the visited network, not with your device.

 

 

Does an eSIM solve permanent roaming?

An eSIM makes the fix deliverable without a site visit, which is not the same as removing the restriction. The eUICC lets you install a compliant local profile remotely. You still need a provider with that profile available in the market.

 

 

Is multi-IMSI enough on its own?

For carrier policy limits and outage resilience, multi-IMSI does most of the work. Where a regulator requires a local subscriber identity, a local profile is the answer.

 

 

What happens to a device that gets barred?

It stops attaching to that network. Depending on the deployment, the device retries and drains battery, buffers data until storage fills, or goes silent with no alert reaching your platform. This is why attach-failure alerting matters more than usage alerting.

 

 

Does permanent roaming affect data residency and NIS2?

They are separate questions that arrive together. Roaming determines which network carries the traffic. Data residency and NIS2 Article 21(2) technical controls concern where traffic goes and who reaches it. Private routing and per-session access control address the second question regardless of which identity the device attaches with.

 

 

Can I fix this after deployment?

With an eUICC-capable device and a provider that holds local profiles, yes, remotely. With a soldered single-profile SIM in a sealed enclosure, the fix is a technician and a ladder.

 

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