Permanent roaming looks like it works. That is the problem with it.
You ship a device to another country, it attaches to a foreign network through your provider's roaming agreement, and it reports data on schedule. Nothing in the commissioning process tells you the arrangement has an expiry date. Then a regulator tightens enforcement, or an operator runs its deregistration job, and a group of devices in one country goes dark on the same day. The devices are fine. The regulatory basis for how they were connected is not.
Roaming was designed for people who travel. A handset visits a foreign network for a fortnight and goes home. Charging, taxation, lawful intercept, and emergency service obligations all assume that pattern.
An IoT device does not go home. A charge point installed in Warsaw stays in Warsaw for a decade, permanently attached to a Polish network on a foreign subscription. Regulators read that as an operator serving the local market without a local licence, local tax presence, or local lawful intercept obligations. Several enforce against it.
Enforcement takes 3 forms in practice. A regulator sets a hard limit, commonly 90 days of continuous presence. An operator applies its own deregistration policy regardless of what the regulator requires. Or the roaming agreement itself gets renegotiated and an IMSI range that worked last year stops being admitted.
Brazil, Turkey, India, China, Canada, and Saudi Arabia are among the markets that come up most often, and the picture shifts. Treating the list as fixed is the mistake. The design question is not which countries restrict permanent roaming today, but whether your fleet survives the next country that starts.
Permanent roaming failures share a shape that makes them expensive.
The SIM holds several subscriber identities and presents a different one when the first is refused. On a permanent roaming restriction, switching to a second foreign identity restarts the clock rather than removing the restriction, so treat multi-IMSI as resilience rather than a compliance answer. It is the right tool for attach refusals, degraded paths, and operator-side policy changes, and it works in seconds without touching the device.
A local subscriber identity means the device presents as a domestic subscriber rather than a visitor. The permanent roaming question stops applying, because the device is not roaming. This is the direct answer where a market enforces hard limits, and it is why the market coverage of local IMSI options matters more than a headline country count when you are choosing a provider.
eUICC rewrites the operator profile over the air, under GSMA SGP.32 for IoT. Where multi-IMSI switches identity inside a profile, eUICC replaces the profile and the commercial relationship underneath it. That is what turns a regulatory change from a truck roll into an orchestration task. It needs planning before deployment: which markets get a local profile, what triggers a swap, and who authorises it. Retrofitting a provisioning path onto devices already in the field is the hard version of this work.
Where traffic breaks out matters as much as which identity the device presents. Local breakout keeps data in-region, which shortens the path, reduces latency, and answers data residency questions that arrive alongside the roaming ones. A provider with direct control of its own core sets this per deployment. A provider running virtualised on someone else's platform inherits whatever that platform allows.
Work through 4 questions per market, not per device.
For most cross-border fleets the answer is layered rather than singular: multi-IMSI for daily resilience, local IMSI in the markets that enforce, and an eUICC path held in reserve for the market that changes its rules after you shipped.
IXT runs a dedicated mobile core built for IoT from the ground up, not virtualised on shared infrastructure. That gives direct control over routing, steering policy, and the identity a device presents, rather than depending on a partner platform's defaults.
One SIM reaches 600+ mobile networks across 190+ countries, in physical SIM, eSIM, or iSIM form. IXT supports local IMSI options in key markets to reduce permanent roaming risk, and steering policy is set per deployment rather than as one global default. The IXT CMP shows every SIM in real time, including status, usage, location, and session logs, where many platforms carry a 24 to 48 hour data delay. When devices in one country start failing to attach, that difference decides whether you find out this week or next quarter.
Coverage is not guaranteed on every network in every country. It depends on the roaming and local agreements in place at the time of deployment, which is exactly why the alternative paths belong in the design rather than in the incident response plan.
Where a limit is set, 90 days of continuous presence is the most common threshold, and some operators apply shorter policies of their own. Treat any single figure as a starting point and confirm per market at design time.
Brazil, Turkey, India, China, Canada, and Saudi Arabia are the ones raised most frequently, with enforcement varying between them. The list changes, so build a fleet that survives an addition to it rather than one tuned to today's version.
No. Presenting a second foreign identity restarts the clock on a restriction. Local IMSI or a locally provisioned profile addresses the underlying requirement.
Not quite. eSIM describes the soldered MFF2 form factor. eUICC describes the ability to change operator profiles remotely. A device benefits from either independently, and the pairing of the two is what most IoT deployments are reaching for.
In a restricted market, recovery needs physical access to swap the SIM. That is the cost worth quantifying before the next hardware revision, because specifying eSIM or iSIM with eUICC support at design time removes it entirely.
Identity switching and profile swaps sit in the SIM and the network. What firmware needs is reconnection logic that tolerates the network underneath a session changing without warning, and a retry pattern that backs off rather than hammering a network that has refused it.
If your fleet crosses borders and stays put once it lands, the roaming basis under it is worth checking before a regulator checks it for you. Ask us how it works for your deployment, or book a demo at ixt.io.
Related articles
Third-party vendor access is one of the most common entry points for cyberattacks on industrial and IoT environments. Here is what the risk actually looks like, why traditional access methods make it worse, and what a more secure approach requires.
Which markets restrict permanent roaming for IoT, why devices get disconnected, and how multi-IMSI, eUICC, and local profiles keep deployments compliant.
Enterprise IoT SIM pricing looks clean until the invoice lands. Where the hidden fees come from, and what predictable per device pricing actually requires.
