IoT roaming regulations are the local rules that decide whether a roaming device can legally operate in a market — and for how long. Some countries prohibit permanent roaming outright; others enforce time limits after which a device must switch to a local profile; others still require billing transparency or in-country operator agreements. Discovered late, any one of them can halt a launch.
And late is exactly when they tend to be discovered. This is one of the nine reasons IoT fleets switch connectivity providers — not because the regulations are unbeatable, but because most fleets meet them for the first time with devices already in the field. Here’s how the blockers show up, why they’re so hard to comply with mid-rollout, and how SGP.32 changes the equation.
How do regulatory blockers show up in a launch?
Fleet managers describe new-market launches coming to a halt the moment local regulation enters the picture. The biggest issue, they point out, is that managers find out about local blockers once a rollout is already underway.
The blockers themselves vary by market. Some countries prohibit permanent roaming outright. Others enforce time limits after which a device must switch to a local profile. Others still require billing transparency or in-country operator agreements that are difficult or impossible to meet. For anyone selling into government or utilities, the bar is even higher: without formal regulatory clearance, deals simply don’t close.
When scoping solutions, managers report that local operators won’t cooperate on migrations. As a result, clean OTA transitions are impossible and costly physical SIM swaps are the only alternatives. Import rules around SIMs and eSIMs add another layer of uncertainty for hardware that has to cross borders before it can be deployed.
“Devices in-country were put on a forbidden list by networks and didn’t recover until we cleared the priority network list; without local agreements this kind of thing blocks multi-operator failover.”
The cumulative effect is that a prospect can’t confidently promise a customer in a new market that the product will work — not because the technology fails, but because the regulatory and commercial landscape is too fragmented to navigate reliably.
Why is compliance so hard mid-rollout?
Regulation is a constant in every market, and an unpredictable one. Rules around permanent roaming, local operator requirements, and SIM import restrictions vary widely by country and change without much warning. The real problem isn’t regulations per se — it’s that discovering them tends to happen late, when a rollout is already planned or a tender is already won. The markets with roaming restrictions are generally known; what’s unknown is what it takes, step by step, to overcome the blocker.
Compliance is usually a simple commercial and legal decision: identify the requirement, meet it. With cellular connectivity, the “meet it” part is theoretically solved by remote SIM provisioning — swapping profiles over the air on a deployed device. However, until SGP.32, there was no practical standard for remotely switching operator profiles on deployed devices, which meant SIMs were effectively locked to whatever operator they shipped with.
So what would elsewhere be a straightforward compliance step — swap to a local profile, meet the local requirement — becomes a hardware or logistics problem instead.
What SGP.32 changes (and what it doesn’t yet)
SGP.32, the GSMA’s eSIM IoT standard for remote SIM provisioning, changes the underlying capability: switching a deployed device to a local profile becomes an over-the-air update rather than a truck roll. That’s the difference between a compliance requirement being a line item and being a blocker.
But the ecosystem around it is still maturing. Until remote profile management is widely accessible and affordable, compliance in new markets will keep depending on getting the SIM choice right before deployment.
That’s why many fleet managers are willing to navigate the developing SGP.32 market and pay the early-adopter premium to turn compliance into a simple OTA update — and for some, it’s a must. For the fuller background on why permanent roaming causes so much trouble in the first place, see our guide to IoT’s struggle with permanent roaming.
How Onomondo handles new-market compliance
Onomondo is SGP.32-ready and owns its own global core network, which means a device that needs a local profile can get one over the air — compliance becomes an OTA update, not a hardware swap or a field visit.
The pattern across every lesson in this series holds here too: the fix is being decided before the rollout, not during it. Adopt SGP.32 early, know the requirements in the markets you’re entering, and the regulatory landscape becomes something you navigate rather than something you hit.
Frequently Asked Questions
What are permanent roaming restrictions?
Rules in some markets that limit how long a roaming device can stay connected. Some countries prohibit permanent roaming outright; others enforce time limits after which a device must switch to a local profile.
What is a local profile in IoT?
An operator profile from an in-country network, used in place of a roaming connection. In markets that restrict permanent roaming or require in-country agreements, switching a device to a local profile is how it stays compliant.
How does SGP.32 help with in-country compliance?
SGP.32 is the GSMA’s eSIM IoT standard for remote SIM provisioning. It makes it practical to switch a deployed device’s operator profile over the air — so meeting a local-profile requirement becomes an OTA update instead of a physical SIM swap.
When should you check roaming regulations for a new market?
Before the rollout is planned and before a tender is won — not after. The markets with roaming restrictions are generally known; the step-by-step path to overcoming each blocker is what takes time to establish, and discovering it late is what halts launches.
