A meter ships to Poland. It attaches to one network and works for 8 months. Then that network moves traffic to a new packet gateway, the device stops registering, and nobody notices until a usage report shows zero consumption for a fortnight. The device did not fail. Its single route onto the network did.
That is the design problem multi-IMSI solves. Not coverage on a map, but what happens on the day the one network you attached to stops working the way it did at commissioning.
What multi-IMSI is, and what eUICC adds on top
An IMSI is the subscriber identity a device presents when it asks a mobile network for service. A single-IMSI SIM presents one identity, tied to one home operator, and reaches every other country through that operator's roaming agreements. One identity, one set of commercial relationships, one dependency.
A multi-IMSI SIM holds several subscriber identities in the SIM profile. The device selects between them at attach time or on failure. If one identity is refused service, rejected by the visited network, or landed on a degraded path, the SIM presents another.
eUICC works at a different level. It rewrites the whole operator profile over the air using the GSMA remote SIM provisioning standards, SGP.32 for IoT. Multi-IMSI switches identity within a profile in seconds. eUICC replaces the profile itself, which takes longer and involves an orchestration step, and it changes the commercial relationship underneath the device.
The two are complementary. Multi-IMSI handles daily resilience. eUICC handles the structural change: a country where the original operator has no viable path, a regulator that requires a local subscription, a carrier contract you want to exit without touching hardware.
Where single-network designs break
Four failure modes account for most of what goes wrong on cross-border fleets.
- Attach refusal in a specific country. The roaming agreement covers the country on paper. The visited network refuses the IMSI range in practice, or admits it only to a 2G fallback that the device does not support.
- Silent degradation. The device stays attached but sits on a congested or badly routed path. Sessions drop, retries multiply, and battery-powered devices burn through their power budget on failed transmissions.
- Permanent roaming enforcement. A device sits on a foreign network for 90 days or more and gets deregistered. Brazil, Turkey, India, China, Canada, and others enforce this to differing degrees. The fleet goes dark by country, not by device.
- Operator change on the home side. Your provider renegotiates or loses an agreement. A country that worked at design time stops working, and with a single IMSI there is nothing in the SIM to fall back to.
None of these are device faults. All of them look like device faults to a field team.
Design criteria for a multi-IMSI deployment
1. Decide what triggers a switch
The weakest multi-IMSI designs switch only on outright attach failure. That misses silent degradation entirely. Define the trigger set before you deploy: attach reject codes, consecutive session failures, time without a successful data transfer, signal quality thresholds. A device that has not delivered a payload in 6 hours has a problem worth switching for, even though it reports as attached.
2. Order the IMSIs deliberately per region
The list order sets which network the device tries first. A device destined for the Nordics has a different sensible order to one destined for southern Europe. If your provider ships one profile order for every device in the fleet, half your devices start on the wrong network and switch on first power-up, which costs you a switching cycle you did not need.
3. Bound the switching behaviour
Unbounded retry logic is its own outage. A device that cycles through 4 identities every 90 seconds looks like a fault to the visited network and gets barred. Set a back-off. Set a maximum switch count per period. Set a resting state so a device that has exhausted its options waits rather than hammering.
4. Match the switching model to the power budget
Each attach attempt costs energy. On a mains-powered charger this is irrelevant. On an NB-IoT sensor with a 10-year battery, aggressive switching logic is a design decision you make once and live with for the life of the device. Model the worst case: how many switches per day before the battery projection breaks.
5. Instrument the switching, not only the connection
A fleet where 12% of devices switch identity daily is telling you something specific about one region or one hardware batch. If your platform reports connection status only, that signal is invisible. You want per-device switch history, the network each device is currently on, and session logs, in something closer to live than a daily export.
6. Plan the eUICC path before you need it
Multi-IMSI runs out of options when no identity in the profile has a viable path in a country. Decide now which markets get a local profile, what the trigger for a profile swap is, and who authorises it. Retrofitting a remote provisioning path onto a deployed fleet is harder than designing it in.
The tradeoffs nobody puts in the datasheet
Multi-IMSI adds moving parts. Two identities means two sets of routing, two sets of billing records, and two places a misconfiguration hides. Diagnosing a device that switched networks mid-session is harder than diagnosing one that has a single path.
Switching also takes time. A switch is a detach, a scan, and a fresh attach. Real-world figures land between 30 seconds and a few minutes depending on the radio environment. For a telemetry device reporting every 15 minutes that is invisible. For a payment terminal mid-transaction it is a failed transaction. Applications that hold long-lived sessions need reconnection logic that assumes the underlying network changes underneath them.
And multi-IMSI is not a compliance answer on its own. Presenting a second foreign identity in a country that restricts permanent roaming buys you a second clock, not an exemption. Local IMSI or a local profile is what addresses that.
How IXT approaches this
IXT runs a dedicated mobile core built for IoT from the ground up, not virtualised on shared infrastructure. That gives IXT direct control over routing, steering policy, and the identity a device presents, rather than inheriting whatever a partner platform allows.
The practical result for a fleet designer: 600+ mobile networks across 190+ countries reachable from one SIM, in physical SIM, eSIM, or iSIM form. IXT supports local IMSI options in key markets to reduce permanent roaming risk. Steering policy is set per deployment rather than one global default. And 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 a region starts switching identity more than it used to, you see it in the same week rather than the next quarter.
Redundancy is a property of the design, not of the SIM. The SIM gives the device somewhere else to go. The switching policy, the profile order, the instrumentation, and the eUICC plan decide whether it gets there.
FAQ
Is multi-IMSI the same as multi-network roaming?
No. Single-IMSI roaming reaches other networks through one home operator's agreements. Multi-IMSI holds several subscriber identities in the SIM, so the device presents a different identity and a different set of agreements when the first one fails.
Do I need eUICC if I already have multi-IMSI?
For most cross-border fleets, yes, as a planned escalation path. Multi-IMSI covers daily resilience within the profile it ships with. eUICC covers the cases that profile does not: a market requiring a local subscription, a country where no shipped identity has a path, or a provider change without a site visit.
How long does an IMSI switch take?
Between roughly 30 seconds and a few minutes, driven by the detach and reattach cycle and the radio environment. Design your application to tolerate a gap of minutes, not milliseconds.
Does multi-IMSI solve permanent roaming restrictions?
Not by itself. Switching to another foreign identity restarts the clock on a restriction rather than removing it. Local IMSI options or a locally provisioned profile address the underlying requirement.
Does adding IMSIs improve coverage?
It improves the odds of attaching where coverage exists. It adds nothing where there is no cellular service at all. Coverage is a radio question. Multi-IMSI is an admission and routing question.
What does this cost in device complexity?
Nothing on the device if the switching logic sits in the SIM applet and the network. It does put a requirement on your application: reconnection logic that assumes the network underneath a session changes without warning.
Next step
If you are designing a fleet that crosses borders, the switching policy matters more than the coverage map. Ask us how it works for your deployment, or book a demo at ixt.io.
