You spent £1,000 on a phone full of eSIM technology and never once had to understand SGP.22. So why does the IoT industry sell connectivity the other way round, starting with the plumbing instead of the outcome?
Do not start by asking whether you need SGP.32. Start by specifying the outcome: how long the device stays in the field, which networks it can use, how it recovers from failure, and whether you can manage it without a site visit. Choose hardware and a managed service against that specification. SGP.32 is one useful mechanism inside a good connectivity lifecycle, not the thing you are buying.
The eSIM phone you already own
You walk into a phone shop and spend £1,000 on an iPhone. What did you actually buy? Email, messaging, banking, maps, music, your photographs, boarding passes, payment cards. A very good camera, a screen, an operating system, an enormous ecosystem of apps. Some status, probably. A brand, whether you admit it or not.
What you almost certainly did not buy was SGP.22. There is a reasonable chance you have spent four figures on a phone containing eSIM technology without ever hearing the name. And why should you have? You understand eSIM at roughly the level you need to: you can activate a service without pushing a piece of plastic into a tray, you can probably add a second line, and you understand roaming because your email still arrives when you land abroad. Apple does not sell you SGP.22. Your operator does not expect you to understand remote SIM provisioning architecture. They sell you the ability to do things.
Here is the other point. You could do most of that with a perfectly good £500 phone. You might still choose the £1,000 one for the camera, the ecosystem, the support, or simply because you like owning it. Those are all forms of value. You choose the combination of hardware, software, service, experience and brand that works for you. Somewhere underneath is a complicated stack of mobile standards making the connectivity work, but those standards are not what you thought you were buying. So why do we buy IoT connectivity completely differently?
Why IoT turns into alphabet soup
Imagine you are responsible for connecting 500 EV chargers. You approach the IoT connectivity industry and suddenly you are hearing about eSIM, eUICC, multi-network, steered and unsteered roaming, dual-IMSI, multi-IMSI, remote SIM provisioning, bootstrap profiles, SGP.32, SM-DP+, IPA, eIM and possibly iSIM as well. You did not ask for any of that. You wanted the charger to stay connected.
The driver wants to arrive, plug in, authenticate, charge, pay and drive away. Operations wants to know whether the charger is working. Support wants to diagnose problems remotely. The software team wants updates to reach the device. Finance wants sensible, predictable costs. And if, in five years, the connectivity arrangement is no longer right, nobody wants to send engineers round the country with a bag of replacement SIMs. Those are the things you are actually buying. Everything underneath exists to deliver them. That does not make the technology unimportant, quite the opposite, understanding enough of it prevents some very expensive mistakes. But we are starting at the wrong end.
What you are actually buying
An "IoT SIM" sounds like a product. In reality it is often one small component in a much larger service. You might be buying network access, or access to several networks. You are buying a subscriber identity so your equipment can authenticate. You are buying data, and probably a management platform, and perhaps APIs. You might need private networking, a VPN, a fixed IP or a private APN. You might be buying alerts and usage controls, and support. Increasingly you are buying the ability to change the connectivity profile inside deployed equipment without visiting it. Above all, you are buying the expectation that your connected application keeps working.
For an EV charger, connectivity is not the product. Nor for a vending machine, an alarm, a CCTV camera, an agricultural controller or an industrial PLC. It enables the product. That distinction is the whole argument of this guide.
Start with the job
Forget SGP.32 for a moment and specify connectivity for that EV charger. The requirements might be: stay connected wherever reasonably possible; recover automatically from common network failures; tell us when something has gone wrong; let us diagnose remotely; give us enough network choice for good coverage; avoid unnecessary engineer visits; do not force a site visit simply because the connectivity supplier changes; and remain economically supportable for the expected life of the charger.
That is already a good connectivity specification. Notice what it does not say. It does not say "must use SGP.32." We have specified what we want. Now we can decide which technologies help us achieve it.
There is a slight problem with this article. We have started explaining IoT connectivity to somebody who just wanted their equipment to work, which is exactly what we accused the industry of doing. So let us stop and answer the simpler question first: what would we actually deploy?
What we would actually deploy in 2026
There is no single answer for every application. A £70 telemetry gateway sending a few megabytes a month does not need the architecture of a commercially important EV charger. A remote agricultural sensor is not a payment system. A CCTV feed consuming tens of gigabytes is different again. But for a reasonably important remote installation, where a connectivity failure has a real commercial consequence, we would start by designing for failure rather than pretending failure will not happen.
Because there is no such thing as guaranteed always-on cellular. Networks fail. Routers fail. SIM services fail. Antennas get damaged. DNS fails. Software crashes. Power supplies fail. Cloud platforms have outages. And sooner or later somebody puts a JCB through something important. The realistic objective is always-on by design, never guaranteed, and that changes the architecture.
Two independent cellular paths
For a commercially important installation in 2026 we would seriously consider a dual-modem industrial router. Not merely dual-SIM. Dual modem. There is a difference. A dual-SIM router with a single modem can hold two SIM services for useful resilience, but there is still only one modem. A dual-modem router gives two independent cellular interfaces: one can fail while the other keeps working. We cover that distinction in full in our guide to dual-IMSI versus dual-modem routers.
A useful current example is the Teltonika RUTC42, which uses two independent LTE Cat 4 modems and supports cellular failover and load balancing, with RMS for remote management. Why Cat 4? Because an EV charger does not need gigabit 5G to exchange routine operational data. 4G is mature, widely available, well understood by engineers, and the antenna ecosystem is established. For many applications being deployed in 2026, conventional LTE remains a rational choice.
We are not saying everybody should buy a RUTC42. It demonstrates the architecture. Another Teltonika model might suit another job; a Robustel, Digi, Milesight, InHand or Peplink may be a better fit elsewhere. Remember the smartphone: if a £500 phone delivers everything you value, do not buy the £1,000 one because somebody says it must be better. Industrial hardware is no different. Buy the outcome, not the badge.
Two connections, not just two SIM cards
Now give those two modems connectivity. As a worked example rather than a tariff recommendation, the primary modem might carry multi-network IoT connectivity with 1 GB a month and the secondary another multi-network connection with perhaps 500 MB. But the important step is to check whether those services genuinely provide different failure domains. Two SIMs from the same platform in two modems gives radio resilience, yet both might still depend on the same APN, the same core, the same roaming platform, or ultimately the same supplier.
For a genuinely important application, diversity has to mean more than two SIMs. The useful question is: what could take both connections down at the same time? That is a far more valuable resilience question than counting SIM slots.
Cheap data has quietly changed the maths
Why pay for a second connection that mostly sits idle? Because low-volume IoT data has become inexpensive relative to downtime, and the way it is sold has shifted. The market has moved away from rigid monthly bundles towards transparent, pay-as-you-use pricing: billing per megabyte for what is actually consumed, no minimum order quantities, and in some cases charging only for the SIMs that are actively transmitting in a given period. Fleets increasingly pool data so that quiet devices offset busy ones, and platforms surface usage so waste can be designed out rather than discovered on an invoice.
The point is not that one provider charges a particular rate. Rates vary by provider, volume, networks and service level, and models range from pure per-megabyte to flat per-device pricing built around a device's known behaviour. The point is that intelligent, usage-based pricing has made deliberate redundancy affordable for applications where it matters. If a backup connection spends most of its life carrying very little traffic, what are you really paying for? Time.
Connectivity is increasingly sold as a managed service with smarter, more transparent data pricing underneath it, not as a bag of megabytes on a fixed bundle. That makes the service wrapper, how it fails over, how you diagnose it, what happens when you leave, at least as important as the raw price per gigabyte.
Resilience buys you time
Imagine the primary connection fails at 02:17 on a Tuesday. The router detects it and moves traffic to the second modem. The charger keeps communicating. At the same time the remote-management system raises an alert. The support team arrives that morning and sees a fault, primary cellular WAN unavailable, but not an outage. They can investigate the primary path remotely while the application keeps running on the second modem. Perhaps the network had an outage, perhaps the SIM is not registering, perhaps the modem needs restarting, perhaps a firmware issue has appeared, perhaps the original provider has a wider problem. The engineer investigates, and the customer can still charge their car. That is what resilience should do: turn emergencies into support tickets.
This is why we would provision remote management from day one. With the Teltonika example that means RMS. If an asset will stay installed for years, it can make sense to buy long-duration management entitlement as part of the initial installation cost rather than treating it as an optional extra somebody might remember to renew. Router, antenna, connectivity, remote management, installation and commissioning are one system. The exact platform depends on the hardware you choose; the questions are the same. When the primary connection misbehaves, can your engineer securely reach the equipment, inspect it, retrieve diagnostics, change configuration, restart services and update firmware?
But what about SGP.32?
Nothing described so far necessarily requires SGP.32, and that matters. Our customer wanted resilient connectivity and fewer site visits. Existing technologies already deliver much of that. If the chosen router and provider let us remotely manage eSIM profiles today, we may already be able to change the underlying service without physically replacing a SIM. That is not the same as saying the implementation is SGP.32, it is not, but from the customer's point of view we have already achieved one of the outcomes that makes SGP.32 interesting: changing connectivity without sending somebody to site.
That proves the argument rather than undermining it. Do not delay a sound 2026 deployment while you wait for every component in the industry to support tomorrow's preferred standard. Buy the outcome you need today, understand where the standards are heading, and let the architecture underneath your service evolve.
The GSMA published SGP.32 v1.3 on 28 May 2026, but v1.2 remains the version that eUICCs, eIM platforms and SM-DP+ servers are formally certified against, and most vendor documentation still references v1.2. Chasing "v1.3 support" on a spec sheet is exactly the back-to-front buying this guide warns against. Ask a supplier which version they hold certification against and when they expect to certify against v1.3.
A ten-year fleet is not one ten-year-old product
Suppose the charger manufacturer deploys from 2026 to 2036. It would be absurd to assume every unit built across that decade must contain identical communications hardware. A plausible lifecycle looks more like this, and the objective throughout is never to keep the technology identical, only to keep the service working.
Future-proofing does not mean predicting the future
Nothing is future-proof. Every modem eventually becomes old, every cellular generation eventually disappears, standards evolve, companies are acquired, networks merge, prices change, products reach end of life. So future-proofing should not mean buying something in 2026 that will never become obsolete. It should mean designing the system so that obsolescence can be managed: replaceable communications hardware, sensible multi-network connectivity, two cellular paths where justified, remote management, eUICC and eSIM, SGP.32 as it becomes available, iSIM in later generations, documented installations, good antennas, APIs, a modular application architecture, and connectivity contracts that do not create unnecessary lock-in. The architecture survives the change.
Installation is part of connectivity
One part of IoT connectivity gets nowhere near enough attention: the installation. You can spend hundreds of pounds on a professional router, pay for managed connectivity and remote management, then connect the whole thing through the cheapest antenna you could find. That is false economy. A £300 router cannot repeal physics. The antenna is part of the communications system, and it should be chosen for the frequencies in use, the mounting environment, MIMO requirements, cable length, connector type, enclosure and position. Sometimes an inexpensive antenna is fine; sometimes it is not. Buy the right value, not automatically the highest or lowest price.
Record the radio environment before the installer leaves
When a permanent cellular installation is commissioned, create a record of the radio environment while it is known to be working. Do not just glance at the signal bars and drive away. Where the hardware allows, run a network and cellular scan and record what you can: available operators and cells, radio technology, frequency bands, serving cell and Cell ID, RSRP, RSRQ, SINR, RSSI, the selected network and the antenna configuration. Not every modem exposes every measurement, and that is not the point. The point is a baseline.
Imagine somebody calls support four years later to say the charger keeps dropping offline. Support can see the radio environment today, but without a commissioning record nobody knows what good looked like in 2026. With one, they can compare: perhaps the serving network changed, perhaps signal quality deteriorated, perhaps another network is now clearly better, perhaps the antenna failed, perhaps someone built something next to the site. Now remote support has evidence rather than guesswork. For an important asset we would record more than the scan: the router make, model, serial and firmware; SIM and eSIM identifiers, provider, primary and backup services; the radio measurements; the antenna make, model, position, cable and photographs; the remote-management registration and alert configuration; and the expected traffic and key application endpoints. The person supporting the device in 2032 should not be reconstructing what someone installed six years earlier.
The wrong kind of value, and why boring is good
Problems usually start when one part of the system is optimised because it is easy to put in a spreadsheet. Router A costs £150, Router B costs £210, so Router A "saves" £60. Perhaps. But what if Router B gives you better remote management, or the second modem the application genuinely needs, or better long-term support, or an ecosystem your engineers already understand? The same happens with antennas and SIMs. Provider A is £1 a month cheaper, but which networks can it use, how does failover work, how fast can you diagnose a fault, can you change connectivity remotely, and what does it cost you to leave? Weigh the £1 against the cost of an engineer visit or an hour of downtime and it stops looking clever.
The best measure of a successful industrial installation is that nothing happens. Nobody drives to site, swaps the SIM, resets the router or climbs onto a roof. Nobody discovers that the only person who knew the password left three years ago. The application simply keeps doing its job, month after month, and nobody thinks about it. That boring reliability has value, and it usually comes from spending money in the right places at the start. Not necessarily more, just correctly.
The technical guide: what the terms actually mean
If all you wanted was help buying connectivity, you could stop above. But if you specify hardware, negotiate with providers, or have just been offered an "unsteered multi-network multi-IMSI SGP.32-ready IoT eSIM" and would like to know whether that sentence means anything, here is the plumbing.
SIM, IMSI and multi-IMSI
A SIM holds the credentials that let a device identify and authenticate itself to a network; the plastic card is just the familiar form factor, and IoT SIMs also come soldered. The important distinction is between the physical component and what can be provisioned onto it. The IMSI, the International Mobile Subscriber Identity, is one of the identities a network uses to recognise the subscription. A multi-IMSI service can hold more than one identity, because different identities can carry different network relationships, and the platform can change which one the SIM uses. That is another mechanism for maintaining connectivity, but it is not the same as remotely replacing the whole operator profile, and it does not automatically make you independent of the company providing it. Dual-IMSI is simply the two-identity version of the same idea. Do not weight the acronym; ask what the second identity actually gives you.
Multi-network, steered and unsteered roaming
A multi-network SIM can register with more than one network; in the UK a roaming proposition may reach several of the national networks rather than tying you to one. Useful, but the label does not tell you which networks, in which countries, on which radio technologies, whether LTE-M or NB-IoT are available, whether all networks are on equal terms, how the device selects between them, and how long recovery takes. A list of operator logos is not a resilience architecture. Roaming can also be steered, where the provider prefers particular partners, or unsteered, implying more freedom to select. Again the label is not enough. The practical question is: if the device is clinging to a poor network while a better permitted one is available, what actually happens?
Dual SIM is not dual modem
Worth repeating. A dual-SIM router may hold one modem and two SIM interfaces and switch between subscriptions. A dual-modem router has two cellular modems and two paths that exist independently. For uptime, the second is a stronger form of resilience. Neither is automatically better; it depends on the application.
eSIM, eUICC and iSIM
Consumer usage has muddled this. People say "eSIM" to mean there is no removable card, which is understandable but incomplete. The important component is the eUICC, the secure element that can store and manage operator profiles under a remote-provisioning architecture. The real value is not losing the SIM tray; it is changing the connectivity profile without changing the physical component, which matters a great deal for a device that is hard to reach. iSIM takes integration further, placing secure SIM functionality inside the cellular chipset or module, which can mean fewer components and less board space. But physical integration is not the same as the provisioning standard: where the secure element lives and how profiles are remotely managed are related but separate questions.
SGP.22 versus SGP.31 and SGP.32
SGP.22 is the technical architecture behind consumer eSIM, the one in your phone. Your phone has advantages an IoT device may lack: a screen, a user, an operating system, a powerful processor, decent internet, and somebody physically holding it during activation. An environmental sensor bolted to infrastructure, a tracker moving across Europe, a meter in a locked cabinet or a charger on a driveway may have no screen, no user, limited power and bandwidth, intermittent connectivity, and thousands of identical siblings. That is why the GSMA built the IoT remote-provisioning architecture around SGP.31 and SGP.32. SGP.32 is designed for remote provisioning and management of IoT devices, including those constrained by their network or their user interface. As of 2026 the current version is v1.3.
What SGP.32 actually does, IPA and eIM
Strip away the terminology and the capability is simple: a standardised architecture through which operator profiles on IoT eUICCs can be remotely provisioned and managed. Deploy 10,000 devices, and five years later the arrangement needs to change because pricing, coverage, roaming or regulation shifted, or you entered another country, or a better service appeared. With a fixed SIM that could mean physically changing 10,000 cards. The cards are cheap; visiting 10,000 sites is not. Remote provisioning changes the economics. Two acronyms recur: the IPA, the IoT Profile Assistant, which helps the device interact with the provisioning process and can live in different places in the architecture; and the eIM, the eSIM IoT Manager, involved in remotely managing provisioning across the fleet. From the buyer's side the useful question stays the same: who manages this for me, and what can I do with it?
"Our solution supports SGP.32" does not automatically mean "you can move your entire estate to any provider whenever you want." Ask who controls the eIM, who controls the eUICC relationship, which profiles can be downloaded, whether another provider's profile can genuinely be introduced and who authorises it, what happens when the contract ends, what happens to profiles already installed, and what happens to offline devices during a migration. And the simplest question of all: what happens if I leave you? That single question can tell you more than half an hour of SGP.32 slides.
Roaming, multi-IMSI and SGP.32 solve different problems
A roaming SIM already reaches several networks, so if the current one disappears the device can register with another permitted network. That solves a network-access problem. SGP.32 potentially lets you change the operator profile itself, which solves a connectivity-lifecycle problem. Changing which visited network you use is not the same as changing the underlying profile through which those relationships are obtained. Both can be useful, and they can work together. The same goes for multi-IMSI: a sophisticated multi-IMSI profile can give excellent international reach and resilience, and could itself sit inside a broader remote-provisioning architecture. You do not have to pick an ideological side. Ask what problem you are solving.
SGP.32 cannot upgrade your modem
Obvious, but it matters for lifecycle planning. Changing a profile does not change the radio. If your modem does not support a band, no SIM change adds it. If your hardware is not 5G, no eSIM profile creates a 5G modem, and the same applies to LTE-M, NB-IoT, RedCap, eRedCap and NTN. The complete system remains modem, firmware, antenna, SIM or eUICC or iSIM, profile, network, provider and management platform. SGP.32 is an important part of that architecture. It is not the whole of it.
Quick reference: what each term gives you
| Term | What it can give the buyer | What it does not automatically give you |
|---|---|---|
| Roaming SIM | Access to partner networks | Access to every network |
| Multi-network SIM | Greater network choice | SGP.32 or supplier independence |
| Unsteered roaming | More freedom in network selection | Instant or perfect failover |
| Dual-IMSI | Two subscriber identities | Two independent providers |
| Multi-IMSI | Multiple identities and network relationships | Replaceable operator profiles |
| Dual SIM | Two subscriptions available to a device | Two independent modems |
| Dual modem | Two cellular radio paths | Independence if everything upstream is shared |
| eUICC / eSIM | Remotely manageable profiles when the service supports it | Automatic freedom to use any provider |
| iSIM | SIM and eUICC integrated into the chipset or module | A particular provisioning standard by itself |
| SGP.22 | Consumer eSIM provisioning architecture | Fleet provisioning for constrained IoT devices |
| SGP.32 | Standardised IoT remote profile provisioning and management | Better coverage or guaranteed commercial independence |
| Remote management | Remote visibility, diagnostics and configuration | A replacement for resilient connectivity |
| Good antenna install | A better chance of a stable radio link | Protection from every network outage |
A buyer's checklist
- What does the application actually need: how much data, how important is uptime, how hard is physical access, how long will it be deployed?
- Which actual networks can it use, in the countries that matter, not just "multi-network"?
- How does it recover from failure: another network, another SIM, another modem, another profile?
- Can you manage it remotely, and can you still manage it when the primary connection has failed?
- What antenna does the installation need: mounting position, cable losses, MIMO configuration?
- What happens if the connectivity provider changes: can it be changed remotely, or does someone visit the device?
- What happens as the fleet evolves: must every device be identical, or can the technology evolve under a consistent service?
- What is the real cost: hardware, connectivity, management, installation, support, engineer visits and downtime, not just the SIM tariff?
Do not buy SGP.32. Buy a connectivity lifecycle.
That is the conclusion. Do not start with "do I need SGP.32?" Start with "what could happen to this device during its operational life?" Networks, coverage, prices, suppliers and regulations can all change; the device might move country; your company or your provider might be acquired; new radio technologies will appear and old ones will disappear. Then ask how many of those changes you can manage without visiting the device. Now SGP.32 makes sense, not as something to worship, but as one more mechanism for a better connectivity lifecycle.
Perhaps its ultimate success will be when most IoT buyers stop talking about it, the way you never celebrate SGP.22 when you activate an eSIM on your phone. The charger manufacturer should be able to say: I need these devices connected for ten years, in these countries, using roughly this much data, and I do not want to visit them just to change provider. The connectivity industry should work out the plumbing, sell the service, support it and improve it. The customer buys the outcome. Be aware enough of the plumbing to recognise unnecessary lock-in and ask the hard questions, but no more than that. After everything in this guide, your EV charger still does not know what SGP.32 is. It wants an IP connection. The driver wants to plug in, pay and drive away. Everyone else in the chain is being paid to make that happen.
Frequently asked questions
Do I need SGP.32 to deploy IoT connectivity in 2026?
Not necessarily. Most of what buyers want, resilient connectivity, remote diagnostics and fewer site visits, can be delivered today with mature hardware, multi-network connectivity and remote management. SGP.32 is a useful mechanism for changing operator profiles remotely over a long asset life, but it is one part of a good connectivity lifecycle rather than a prerequisite for deploying now.
What is the difference between an IoT SIM and an IoT connectivity service?
An IoT SIM is one component. A connectivity service can include network access, a subscriber identity, data, a management platform, APIs, private networking, alerts, support and the ability to change the connectivity profile remotely. For most deployments the outcome you are buying is the service, the expectation that the device stays connected, not the SIM itself.
Is a dual-SIM router the same as a dual-modem router?
No. A dual-SIM router usually has one modem and two SIM interfaces and switches between subscriptions. A dual-modem router has two independent cellular modems and two paths that can operate independently, so one can fail while the other keeps working. For uptime-critical applications the dual-modem design is the stronger form of resilience.
Does SGP.32 mean I can move my devices to any provider?
Not automatically. Support for SGP.32 does not by itself guarantee you can move an estate to any provider on demand. It depends on who controls the eIM and the eUICC relationship, which profiles can be downloaded and who authorises them. Ask a supplier directly what happens if you leave, and what happens to already-installed profiles and offline devices during a migration.
What is the difference between SGP.22 and SGP.32?
SGP.22 is the GSMA architecture for consumer eSIM, used in phones and other devices that have a screen and a user. SGP.32 is the IoT remote SIM provisioning architecture, designed for devices that may have no user interface and constrained connectivity, and it supports remote provisioning and management at fleet scale. The GSMA published SGP.32 v1.3 on 28 May 2026, though v1.2 remains the certification baseline.
What should I ask a connectivity provider before buying?
Ask which actual networks the SIM can use in the countries that matter, how the device recovers from failure, whether you can manage and diagnose it remotely when the primary connection is down, how connectivity can be changed without a site visit, what the real total cost is including support and downtime, and what happens if you leave. The answers reveal far more than a spec-sheet list of supported acronyms.
Ask IoTPortal
Not sure what you need? Tell us what you are trying to connect, deploy, understand or fix. Some of our most useful articles start with a real question from somebody solving a real IoT problem. We will give you our view based on our experience of the market and point you towards the hardware, connectivity and technologies worth considering. If it is a question others are likely to be asking, we may research it and turn the answer into an article.
