What is permanent roaming in IoT?
Permanent roaming in IoT is the long-term use of a cellular subscription outside its home country or home network territory. Whether it is permitted depends on local law, regulation, operator policy and roaming agreements; a SIM that attaches during a test is not proof that years of service are allowed.
Definition
Permanent roaming is sustained use of a mobile subscription on a visited network rather than the subscription's home network, often by an IoT device installed abroad.
Key Takeaways
- Temporary roaming access does not establish permission for permanent use.
- Regulators, visited operators and home providers can impose different restrictions.
- Brazil, Turkey and India are commonly cited as restrictive markets, but current rules must be verified.
- Local profiles, eUICC and multi-IMSI can mitigate—not automatically eliminate—risk.
- Keep country and operator evidence current throughout the device lifecycle.
Why is permanent roaming restricted?
Governments and operators may seek local accountability, lawful-intercept support, emergency-service compliance, tax treatment, numbering control, data handling or fair wholesale use. The mechanism varies: regulation may limit foreign credentials; an operator may prohibit sustained use in its wholesale agreement; or a provider may apply a time or usage policy.
These layers must be checked separately. A regulator may allow a model that one visited operator declines, while a roaming contract can change even when law does not. Device certification, import and sector rules are separate again. Obtain written advice for the actual product, not a generic country color on a coverage map.
Which countries require special attention?
Brazil, Turkey and India are commonly cited in industry discussions as markets with restrictive permanent-roaming or localization conditions. That statement is a screening flag, not legal advice and not a claim that every IoT deployment is prohibited. Definitions, exemptions, licensing models and operator implementation can change.
Verify current primary material from the relevant regulator—Brazil's Anatel, Turkey's Information and Communication Technologies Authority (BTK), and India's Department of Telecommunications (DoT)—plus the selected operators and connectivity provider. Record the date, source, device type, intended duration, profile origin and conclusion. Revalidate before shipment and periodically afterward.
What operational problems can occur?
A visited network may reject registration, limit a radio technology or stop access after a policy change. The home provider may suspend a SIM under fair-use or contract terms. Routing back to a distant home core can also affect latency and data path, although this is an architecture issue rather than a permanent-roaming rule.
Failures may appear after installation rather than during acceptance testing. Devices can remain offline if firmware repeatedly retries a forbidden network or cannot select another identity. Support teams need registration reject causes, current IMSI, visited network and last successful session to distinguish coverage from policy.
How do local profiles, eSIM and multi-IMSI help?
A local operator profile can turn the device into a domestic subscription, subject to local requirements. An embedded Universal Integrated Circuit Card (eUICC) under an appropriate remote SIM provisioning architecture can download and enable such a profile after manufacture. GSMA SGP.32 is designed for IoT profile management.
A multi-IMSI SIM can present another home identity with different roaming or local arrangements. However, an additional foreign IMSI is not automatically local and may face the same restriction. Ask whose network identifier and core are used, whether the arrangement is recognized locally, and who holds required registrations. Read SGP.32 and multi-network IoT SIM.
How should a global deployment manage compliance?
Create a country matrix with regulator status, operator policy, allowed duration, profile type, radio technology, data-routing constraints, evidence owner and next review date. Separate confirmed facts, provider representations and unresolved questions. Require change notification contractually where possible, while maintaining independent review.
Pilot with the production profile and device, but treat successful attachment only as a technical observation. Preserve a bootstrap or alternative path for profile changes and define what happens to installed devices if access ends. In high-risk countries, obtain qualified local legal and regulatory advice. This article is educational and not legal advice.
What questions should providers answer?
Ask whether service is roaming or local in each country, which legal entity supplies it, which IMSI and core network are used, and whether any duration or usage threshold applies. Request the primary rule or named operator basis for the answer and the date it was checked.
Confirm remedies: profile change, alternative IMSI, local stock, notification period and support process. Determine who bears device-access cost if a policy changes. Avoid absolute assurances such as “permanent roaming is allowed everywhere”; country-specific, dated evidence is more credible.
How should teams validate the decision before deployment?
Treat published specifications and supplier documentation as a starting point, not proof that a design will work in every target location. Build a representative test set covering the countries, operators, radio conditions, device firmware, antennas, power sources and backend routes that production devices will encounter.
Start with a written traffic and operating profile. Record payload sizes, message frequency, acceptable latency, mobility, expected device life, firmware-update size and behavior after an outage. Test normal operation as well as weak signal, loss of service, exhausted data allowance, expired credentials, a network change and a backend that is temporarily unavailable. Long retry loops can consume more energy and data than the normal application.
Use a pilot large enough to reveal variation between buildings, regions and networks. Capture attach success, time to first data, session failures, round-trip latency, retransmissions, radio measurements, energy use and data counted by both device and provider. The recommendation is to define acceptance thresholds before the pilot, then retain the evidence used to approve the production design.
Commercial and technical validation should happen together. Confirm which networks, countries, features and support functions are included in writing. Check how subscriptions are activated, suspended, exported and terminated; how alerts work; what happens at contractual limits; and whether the device can be moved to another provider if circumstances change. A low headline rate does not compensate for an unsuitable radio, inaccessible diagnostics or a design that requires field replacement.
What should an operational plan include?
Connectivity is a lifecycle responsibility rather than a one-time component purchase. Assign owners for provisioning, inventory, usage monitoring, incident response, security updates and retirement. Keep the device identifier, subscription identifier, hardware revision, firmware version, deployment location and responsible customer or business unit linked in an inventory system.
Set alerts for unexpected activation, prolonged silence, unusual usage and repeated network sessions. The right threshold depends on the application: silence from a monthly meter is different from silence from a safety alarm. Document who investigates each alert and which evidence is available from the device, connectivity platform and application.
Plan controlled firmware updates, including staged rollout, rollback and recovery from interrupted downloads. Budget for protocol overhead and retries rather than payload bytes alone. Review operator technology roadmaps and regulatory requirements during the service life, especially for products sold into multiple countries. For a structured launch review, use the IoT deployment checklist.
Finally, design an exit path. Record whether hardware supports another profile, SIM or radio technology; how data and identifiers can be exported; and how credentials are revoked at end of life. This is a recommendation for resilience, not a claim that every deployment needs multiple providers.