4G SIM NewsThe term IoT eSIM sounds deceptively simple.
We already understand SIM cards. We understand eSIMs in smartphones. So it is tempting to assume that an IoT eSIM is basically the same thing: take the plastic SIM card out of an IoT device, replace it with a soldered chip, and carry on as before.
That is part of the story.
It is also the least interesting part.
The bigger change happening around IoT eSIM is not really about changing the physical format of the SIM. It is about changing where the mobile subscription comes from, how it is delivered to the device, who controls it, and whether it can be changed after the equipment has been deployed.
That turns IoT eSIM from a component into an ecosystem.
A modern IoT eSIM deployment can involve the eUICC itself, one or more mobile network profiles, bootstrap connectivity, remote SIM provisioning infrastructure, an IoT Profile Assistant, an eSIM IoT Manager, connectivity management platforms, APIs, mobile operators, MVNOs and the modem or device containing the eSIM.
Understanding those pieces is important because simply buying something described as an “IoT eSIM” does not necessarily give you all the capabilities associated with modern eSIM technology.
So let’s start with the SIM itself.
What Is an IoT SIM?
A traditional IoT SIM performs fundamentally the same job as the SIM in a mobile phone.
It provides the identity and credentials that allow a device to authenticate with a mobile network.
Depending on the service, an IoT SIM might additionally provide features such as:
- access to multiple roaming networks;
- private APNs;
- fixed or private IP addressing;
- VPN connectivity;
- pooled data allowances;
- centralised SIM management;
- usage alerts;
- API access;
- network steering;
- multi-IMSI capabilities.
Those are connectivity service features rather than properties of the physical SIM card itself.
This distinction becomes particularly important when discussing eSIM.
The SIM is one component.
The connectivity service surrounding it is another.
And remote SIM provisioning adds another layer again.
What Does “eSIM” Actually Mean?
Unfortunately, eSIM has become one of those technology terms that can mean slightly different things depending on who is using it.
People sometimes use eSIM to mean a soldered SIM.
Others use it to describe an eUICC.
Others mean a downloadable mobile subscription.
And connectivity providers may use “eSIM” to describe an entire managed connectivity proposition.
These are related concepts, but they are not identical.
An embedded SIM can describe a SIM supplied in a soldered form factor such as MFF2 rather than the familiar removable 2FF, 3FF or 4FF card.
An eUICC, however, is the important part when discussing remote provisioning.
The eUICC provides the secure environment capable of storing and managing different operator profiles.
That profile is effectively what turns the eUICC into a subscriber of a particular connectivity service.
This distinction gives us a useful rule:
The eUICC is not the mobile network subscription.
It is the secure platform on which mobile network subscription profiles can reside.
That is why eSIM potentially changes the connectivity model so dramatically.
The Old Model: SIM and Subscription Arrive Together
Consider a conventional IoT deployment.
A company builds 5,000 smart vending machines.
Before the machines leave the factory, somebody installs 5,000 SIM cards supplied by Connectivity Provider A.
Those SIMs are configured with Provider A’s service.
The machines are deployed throughout the UK.
Five years later, the company wants to move its connectivity to Provider B.
Technically, that might be perfectly possible.
Operationally, it can be painful.
Somebody may need to visit thousands of machines, open them, remove the existing SIM and install another one.
For a vending machine sitting in the manufacturer’s warehouse, changing a SIM takes seconds.
For a machine installed hundreds of miles away, the SIM card might cost pennies while changing it costs £100 or more once engineers, travel, access arrangements and downtime are considered.
IoT eSIM attacks that particular problem.
Instead of changing the physical SIM, change the profile stored on the eUICC.
But making that happen requires considerably more than the eUICC itself.
The eSIM Is the Tip of the Iceberg
This is perhaps the easiest way to understand modern IoT eSIM.
Imagine the eSIM as the visible tip of an iceberg.
Inside the device you may have:
eUICC → profile → IPA → modem/device software
Outside the device you may have:
eIM → provisioning infrastructure → connectivity provider → mobile network
Above that might sit:
connectivity platform → API → enterprise application
The physical SIM is therefore only one element in a much larger chain.
And every link matters.
A device containing an eUICC does not automatically mean that an enterprise can log into a portal tomorrow and move the device from one connectivity provider to another.
The surrounding architecture has to support it.
Why IoT Needed Its Own eSIM Architecture
Consumers already use eSIM extensively.
Buy a new smartphone and you may be able to scan a QR code from your operator and download a mobile subscription.
That works because a smartphone has several things that many IoT devices do not.
It has a screen.
It has a user.
It has a sophisticated operating system.
It generally has plenty of processing power.
It can connect to Wi-Fi.
And there is normally somebody standing next to it who can approve what is happening.
Now compare that with a water meter.
The meter might be installed underground.
It might have no screen and three buttons — or no buttons at all.
It may communicate infrequently to conserve battery power.
Nobody is standing next to it scanning QR codes.
It could remain in service for ten or twenty years.
That requires a different approach.
The GSMA therefore developed an architecture specifically suited to IoT devices, including devices that are constrained by power, communications capability or user interface.
The current generation of this architecture is generally associated with SGP.31 and SGP.32.
And this is where IoT eSIM becomes much more interesting than simply replacing a piece of plastic.
Meet SGP.32
SGP.32 is the GSMA technical specification for eSIM remote provisioning in IoT.
The architecture builds upon concepts developed for consumer eSIM while adapting them for remotely managed IoT equipment.
Instead of expecting a human user to control the process from the device, SGP.32 introduces components designed for remote fleet management.
Two particularly important terms are:
IPA — IoT Profile Assistant
and
eIM — eSIM IoT Manager
If you are evaluating IoT eSIM services over the next few years, expect to encounter these abbreviations increasingly frequently.
Understanding them makes much of the surrounding eSIM terminology considerably easier.
What Is the IPA?
The IoT Profile Assistant, or IPA, provides device-side functionality required for the IoT eSIM architecture.
It acts as part of the communication path between the eUICC and the external provisioning and management infrastructure.
There are two broad implementation approaches.
The IPA can exist within the device — often described as IPAd.
Alternatively, functionality can be implemented within the eUICC itself — IPAe.
That distinction matters to equipment manufacturers because it can affect the modem, firmware, device integration and certification requirements associated with implementing SGP.32.
This is a good example of why asking:
“Does this router have an eSIM?”
is no longer necessarily a sufficiently detailed question.
A better set of questions might include:
Does it contain an eUICC?
Which remote provisioning architecture does it support?
Where is the IPA implemented?
Does the modem firmware support the required functionality?
Which eIMs has it been tested with?
Which profile providers have been validated?
Suddenly our apparently simple SIM card has become a systems integration question.
What Is the eIM?
The eSIM IoT Manager, or eIM, is one of the most important parts of the SGP.32 architecture.
It provides the remote management function required to control profile operations across IoT devices.
Rather than somebody interacting directly with each device, the eIM can remotely initiate operations associated with profiles.
That can include activities such as downloading profiles and enabling, disabling or deleting them.
Think of it as moving the “user intent” away from the individual device and into remotely controlled infrastructure.
For IoT, that makes sense.
Nobody wants an engineer visiting 20,000 smart meters and clicking an imaginary “install new mobile plan” button.
The fleet needs to be managed centrally.
Then There Is the SM-DP+
Another part of the ecosystem is the Subscription Manager Data Preparation Plus, normally abbreviated to SM-DP+.
This infrastructure securely prepares and delivers operator profiles.
The distinction between the eIM and SM-DP+ is worth understanding.
Broadly speaking:
The eIM helps orchestrate what should happen.
The SM-DP+ provides the profile that needs to be installed.
The IPA and eUICC then participate in making that happen securely on the device.
There are different possible communication paths, including direct and indirect profile download mechanisms, depending upon the device and architecture.
This flexibility is important because IoT ranges from powerful industrial Linux gateways to tiny battery-powered sensors.
One architecture needs to accommodate both.
What Is a Profile?
The profile is the bit that actually gives the eSIM its mobile subscription.
It contains the operator-specific information and credentials necessary for the device to use that service.
An eUICC can potentially store multiple profiles.
For example:
Profile A — UK connectivity provider
Profile B — German operator
Profile C — US connectivity provider
The appropriate profile can then be enabled according to the deployment requirements and commercial arrangements.
That is fundamentally different from the traditional model where the subscription identity was effectively tied to the SIM that had physically been inserted into the equipment.
The hardware and connectivity subscription become more separable.
That is the real revolution.
What Is a Bootstrap Profile?
Of course, we immediately encounter a chicken-and-egg problem.
If a device needs connectivity to download its permanent connectivity profile, how does it get online in the first place?
One answer is a bootstrap profile.
A bootstrap profile can provide initial connectivity allowing the device to communicate with the infrastructure required to provision its operational profile.
Imagine a manufacturer producing industrial gateways for worldwide distribution.
Rather than manufacturing:
UK gateway with UK SIM,
German gateway with German SIM,
US gateway with US SIM,
French gateway with French SIM,
the manufacturer could potentially build a common hardware product containing an eUICC and suitable bootstrap capability.
When the device reaches its destination, the appropriate operational connectivity can be provisioned.
That can simplify manufacturing, stock management and international logistics enormously.
One Hardware SKU Becomes Possible
This is one of the less glamorous but potentially enormous benefits of IoT eSIM.
Manufacturers hate unnecessary product variants.
Every variation introduces:
- different stock;
- different forecasting;
- different procurement;
- different manufacturing processes;
- different documentation;
- different distribution arrangements;
- different support requirements.
Connectivity has historically contributed to that complexity.
If eSIM allows a manufacturer to produce one connectivity-ready product and determine the final mobile subscription later, the benefits extend far beyond the cost of the SIM.
IoT eSIM therefore becomes a supply-chain technology, not merely a telecoms technology.
Does IoT eSIM Automatically Mean Multi-Network?
No.
This is one of the most important misconceptions.
An eSIM does not magically make a device connect to every mobile network.
A particular profile might already provide roaming access to numerous networks. That is common with IoT SIM services today.
Alternatively, several different profiles could exist on the eUICC.
Those are different concepts.
A multi-network roaming SIM can already allow a device to select between several visited networks without changing its underlying subscription profile.
eSIM remote provisioning goes a level higher.
It potentially allows the subscription itself to be changed.
You could therefore have a multi-network Profile A and a completely different multi-network Profile B.
That distinction becomes important when designing resilience.
Does eSIM Mean You Can Change Provider Whenever You Want?
Technically, eSIM makes changing profiles possible.
Commercially, things can be considerably more complicated.
This is where buyers need to read past the marketing.
The fact that an eUICC is technically capable of receiving another profile does not necessarily mean the customer has unrestricted control over doing so.
Questions worth asking include:
- Who owns or controls the eIM relationship?
- Who controls profile provisioning?
- Can third-party profiles be installed?
- Which SM-DP+ platforms are supported?
- Can profiles from another connectivity provider be loaded?
- What happens when the existing commercial contract ends?
- Can management be transferred elsewhere?
- Who owns the device configuration and associated credentials?
- Is there an API?
- Is the API genuinely multi-provider?
- What export or migration process exists?
These may ultimately prove more important than the price per megabyte.
eSIM Enables Choice. It Does Not Guarantee Freedom.
That distinction deserves repeating.
eSIM enables choice. It does not guarantee freedom.
It is entirely possible to build a technically advanced eSIM service that still creates substantial commercial dependency on one provider.
There is nothing inherently wrong with that.
A managed service provider might be doing considerable work behind the scenes and providing genuine value.
But customers should understand what they are buying.
If your objective is simply to avoid physical SIM replacements, a fully managed provider-controlled ecosystem might be perfect.
If your objective is long-term independence from individual connectivity suppliers, you need to investigate the architecture and commercial arrangements much more carefully.
What Does the Complete IoT eSIM Ecosystem Look Like?
A simplified SGP.32 deployment might look something like this:
IoT application / enterprise systems
↓
Connectivity management platform / API
↓
eIM
↓
IPA
↓
eUICC
↓
Operator profile
↓
Mobile network
Meanwhile, the SM-DP+ participates in securely delivering the required operator profile.
Real deployments can be more complicated, but this simple model demonstrates the key point.
When somebody sells you an “IoT eSIM”, they could actually be selling several different things bundled together:
the physical eUICC;
the initial profile;
bootstrap connectivity;
remote provisioning;
profile lifecycle management;
an eIM service;
connectivity management;
mobile data;
roaming agreements;
API access;
monitoring;
billing;
security services;
support.
That is an ecosystem.
The Router or Modem Matters Too
Another misconception is that any cellular router containing an eSIM-compatible slot or embedded eUICC automatically supports every modern IoT eSIM capability.
Not necessarily.
The cellular module, modem firmware, router operating system and device management software can all matter.
SGP.32 requires functionality beyond simply recognising a SIM.
Manufacturers therefore need to think about eSIM support during hardware and software design.
For equipment buyers, this introduces a new procurement question.
Historically you might have asked:
Which LTE and 5G bands does the router support?
Increasingly you may also need to ask:
Which eSIM architecture does the device support?
That could become particularly important for equipment expected to remain deployed for ten or fifteen years.
eSIM Does Not Replace Good Radio Engineering
There is also a danger that eSIM becomes another magical telecoms acronym supposedly capable of solving every connectivity problem.
It isn’t.
Changing profiles cannot fix a poor antenna.
It cannot create coverage where no suitable network exists.
It cannot compensate for incorrect antenna placement.
It cannot make an LTE-only modem support 5G.
It cannot overcome missing frequency bands.
And it cannot guarantee that two networks actually provide independent infrastructure at the location concerned.
eSIM provides another tool for managing connectivity.
The fundamentals of RF engineering still apply.
A well-installed external antenna connected to the appropriate modem on a suitable frequency band remains rather important.
Physics has stubbornly refused to read the eSIM marketing brochures.
Where IoT eSIM Becomes Particularly Valuable
The strongest use cases tend to be deployments where changing physical SIM cards would be expensive, difficult or impossible.
Smart metering is an obvious example.
So are:
- EV charging points;
- vending machines;
- digital signage;
- environmental sensors;
- industrial monitoring equipment;
- agricultural telemetry;
- security systems;
- traffic infrastructure;
- remote energy assets;
- logistics devices;
- healthcare equipment;
- connected machinery.
The longer the expected equipment life, the more interesting remote profile management becomes.
If a device is expected to operate for fifteen years, predicting which connectivity provider will offer the best commercial and technical proposition throughout that entire period is impossible.
Being able to change the connectivity profile without replacing the equipment therefore has genuine strategic value.
Resilience Is Possible — But It Must Be Designed
Another potential advantage is connectivity resilience.
Suppose a critical remote device contains multiple available profiles.
If the primary connectivity arrangement fails or becomes unsuitable, another profile could potentially be activated.
That sounds wonderful.
But once again, the capability is not automatic.
Somebody has to define:
what constitutes failure;
how failure is detected;
who authorises the switch;
whether the device still has enough connectivity to receive instructions;
whether fallback behaviour exists;
which alternative profile should be used;
and how the device returns to normal afterwards.
The eSIM provides the capability.
The system architecture provides the resilience.
That distinction applies repeatedly throughout IoT.
The API May Become as Important as the SIM
As eSIM estates become larger, humans clicking buttons in portals becomes increasingly inefficient.
APIs allow profile and connectivity management to become part of a company’s wider operational systems.
A manufacturer might provision connectivity automatically when equipment is commissioned.
A logistics platform might choose connectivity according to destination.
An enterprise could integrate profile status into its own monitoring platform.
A connectivity provider could expose multiple underlying operators through one customer-facing service.
This is where IoT eSIM starts becoming software-defined connectivity.
The physical SIM gradually disappears into the infrastructure.
What matters is the orchestration layer above it.
The Big Change: Connectivity After Manufacturing
Traditional SIM deployment encourages connectivity decisions early.
You choose a provider.
You buy the SIMs.
You install them.
You manufacture the product.
You ship it.
SGP.32 potentially changes that sequence.
Manufacture the product.
Install the eUICC.
Ship the product.
Deploy it.
Then determine or change the operational connectivity profile.
That separation between hardware manufacture and connectivity selection could prove one of the most important consequences of IoT eSIM.
It gives manufacturers considerably more flexibility over where and how products are sold.
What Should an IoT eSIM Buyer Actually Ask?
The first question probably should not be:
“How much is the SIM?”
Instead, start with the deployment.
How long will the equipment remain in service?
Will it be expensive to visit?
Will it operate in one country or many?
Do you need several networks?
Do you need several connectivity providers?
Do you need remote profile switching?
Who needs to control those profiles?
Will you need APIs?
Could you change connectivity provider in five years?
What happens to the eSIM estate if you do?
Which hardware supports the proposed architecture?
Who operates the eIM?
Which profiles can be loaded?
What happens if the bootstrap connectivity disappears?
Those questions reveal far more about an IoT eSIM proposition than whether the physical component costs £2 or £5.
So, Is IoT eSIM Just a SIM?
At its simplest, yes.
There is still a secure SIM component somewhere inside the device performing the familiar job of authenticating cellular connectivity.
But treating modern IoT eSIM as merely a smaller SIM card misses almost everything interesting about it.
The real proposition is an ecosystem connecting:
hardware, eUICC, profiles, IPA, eIM, provisioning infrastructure, connectivity providers, mobile networks, management platforms and enterprise software.
SGP.32 brings those pieces together in an architecture designed specifically for remotely managed IoT equipment.
That changes the question from:
“Which SIM should I put in this device?”
to something much more useful:
“How should this device obtain and manage cellular connectivity throughout its operational life?”
For a router installed temporarily on a construction site, that distinction might not matter enormously.
For 100,000 meters expected to remain installed until 2040, it matters a great deal.
And that is probably the best way to understand the transition taking place.
The SIM card is not disappearing.
It is becoming infrastructure.
The interesting part is increasingly everything around it.
Sources
GSMA — eSIM Consumer and IoT Specifications
GSMA — SGP.32 eSIM IoT Technical Specification
GSMA — SGP.31 eSIM IoT Architecture and Requirements
GSMA — eSIM for IoT overview
Kigen — SGP.32 Reality Check
Kigen — eSIM IoT Manager
Kigen — New eSIM for IoT Specification: SGP.32 Explained