You’ve designed a great IoT device, manufactured thousands of them, and shipped them across the globe. Then your primary network operator raises prices. Or a better-coverage alternative opens up. Or maybe a new AI workflow with a CMP fixes a challenge you’ve been having. Or, six months in, you simply realize that your current operator disrupts your data flow.
If your fleet has single-operator SIMs, here are your options: send a technician to swap the card on every device, or continue with disruptive connectivity. You can distribute the rock and the hard place between your options freely.
Remote SIM provisioning (RSP) exists to solve exactly this. It gives users the ability to update, switch, or replace the connectivity profile on a SIM, without physically interacting with the device. For IoT deployments that live in thousands across the globe for years and years, Remote SIM Provisioning massively simplifies operational overhead.
What you’ll learn in this article:
Table of Contents
What is Remote SIM Provisioning?
Remote SIM provisioning is the ability to download, update, or switch a SIM’s network profile over the air and without physical access to the device it’s installed in.
Before we dive deeper, let’s explain two fundamental concepts: the SIM profile; and UICC or eUICC, the two types of logic that run a SIM card.
What’s a SIM profile/operator profile?
A SIM profile is a bundle of data that identifies a device to a cellular network. This bundle runs on an application that holds the IMSI (International Mobile Subscriber Identity), the authentication keys used to verify the device’s identity with the network, and the network access credentials.
UICC vs eUICC: How are they relevant to Remote SIM Provisioning?
UICC (Universal Integrated Circuit Card) is the logic (software) that stores a single profile in a chip on a removable SIM card. This profile logic consists of IMSI (International Mobile Subscriber Identity), security keys, and network access data, among other things. Traditionally, this profile was baked into a physical SIM card at the time of manufacture and was essentially fixed. If you needed to change operators, you needed a new SIM.
eUICC (Embedded Universal Integrated Circuit Card) is a logic architecture (software) that runs on a chip in SIM cards –the physical object– and stores multiple subscriber identities, i.e., multiple operator profiles. A user can manage the profiles stored in the eUICC.
In short, UICC holds one operator profile and eUICC can store multiple. As a result, to swap profiles in a UICC SIM, you need to physically remove the chip the logic is running on. But on an eUICC, since it already stores several profiles, GSMA’s technical standards define the architecture of how to swap among them without physically interacting with the device.
And that’s how these two terms are relevant to Remote SIM Provisioning. RSP is only possible with eUICC SIMs, as it allows for multiple profiles to be managed in the same logic. With RSP, a user can download a new profile to the SIM at any point during the device’s lifecycle, the same way software is updated over the air.
RSP is governed by standards published by the GSMA, the global industry body for mobile operators. There are currently three relevant standards:
- SGP.02: the original M2M eSIM standard, designed for industrial and IoT devices, using an operator-push model where the network operator initiates profile downloads.
- SGP.22: the consumer eSIM standard found in smartphones and smartwatches, where the end user selects and activates a profile themselves.
- SGP.32: the newest standard for eSIM IoT, built specifically for the constraints of IoT devices: low power, limited connectivity, and no user interface. [You can read our full breakdown of SGP.32 here.]
→ For a full breakdown of the three standards for Remote SIM Provisioning SGP.02, SGP.22, and SGP.32, read our dedicated comparison here.
RSP is, in its very essence, the function that enables the most desired benefit of eSIM: operator flexibility with the utmost ease and simplicity.
How remote SIM provisioning works
RSP involves several components communicating in a defined sequence. Here’s how a profile download works from end to end.
The key components:
- The eUICC: The SIM logic that stores and executes profiles. It can hold multiple profiles but only activates one at a time.
- The SM-DP+ (Subscription Manager – Data Preparation Plus): a server operated by the connectivity provider that prepares, stores, and encrypts profiles for download.
For consumer devices
- The LPA (Local Profile Assistant): The function running on the device that manages the connection between the eUICC and the remote servers.
For IoT
- The IPA (IoT Profile Assistant): The function running either on the device (IPAd) or the eUICC (IPAe) that manages the connection between the remote server and the eUICC.
RSP for consumer devices
From a user’s point of view, the remote SIM provisioning process is initiated by scanning a QR code – that is, , per the SGP.22 standard, the user placing the command to remotely provision a SIM.
The process, step by step:
- A new profile is prepared and encrypted on the SM-DP+ by the connectivity provider
- When the device connects, it checks for any waiting profiles and discovers one is ready
- The LPA/IPA initiates a connection to the SM-DP+, authenticates using mutual certificate-based verification, and downloads the encrypted profile.
- The profile is decrypted and installed on the eUICC. The new profile can then be activated immediately or at a scheduled time.
The entire process is designed to be secure and tamper-resistant. Profiles are encrypted end-to-end, and mutual authentication ensures that only the correct device can receive a given profile.
For IoT deployments, the flow looks slightly different than it does for consumer eSIM. Let’s dive a little deeper into Remote SIM Provisioning for IoT.
Remote SIM Provisioning for IoT: Why it’s different from consumer eSIM
It’s tempting to assume that if RSP works for smartphones, it must work equally well for IoT devices. The consumer model assumes certain things about the device: that it has a capable processor, reliable connectivity, a user interface, and a reasonably attentive human nearby who can confirm actions. In practice, the requirements are quite different due to the nature of IoT devices.
IoT devices typically have none of these. Here’s how a scaled IoT deployment actually looks:
- Constrained hardware
Many IoT devices run on low-power cellular modules with limited CPU and memory. Executing a complex RSP negotiation is non-trivial when you’re optimizing for milliampere-hours. - Intermittent connectivity
A device deployed on a shipping container or a water meter might only connect for a few seconds every few hours. The RSP flow has to account for this – it can’t require a persistent, high-bandwidth connection to complete. - No user interaction or interface
Nobody is standing next to an asset tracker in a warehouse to tap “confirm.” There probably isn’t even an interface to tap “confirm” on! The entire provisioning process must be autonomous. - Decades in the field
Consumer devices are replaced every few years. IoT infrastructure is expected to run for years, even decades, across multiple operator relationships and commercial agreements.
SGP.32, the new GSMA eSIM IoT standard, was designed to address all of this.
→ Curious to hear a first-person account? Read our interview with Saïd Gharout, Chair of the SGP.32 Working Group, where he tells us about why eSIM IoT was a need in the first place.
It introduces a lightweight protocol stack, asynchronous profile downloads, a single remote control panel, and an architecture that works without continuous connectivity. To enable these improvements, SGP.32 introduced two key architectural changes from the consumer model:
- The IPA (IoT Profile Assistant) replaces the LPA in order to operate without any user interface, and a new server-side component;
- The eIM (eSIM IoT Remote Manager). The eIM is a platform introduced to manage profile operations remotely, since there is no user to do so physically on the device.
→ Ready to dive deeper into SGP.32 and eSIM IoT? Read our walkthrough of SGP.32 here.
For IoT teams evaluating RSP, the practical implication is this: the standard matters depending on what type of device you are dealing with. An RSP implementation built on consumer eSIM (SGP.22) will impose constraints that simply don’t fit IoT use cases. You’ll be hard-pressed to find an operator ready to implement SGP.02. In the case of IoT, SGP.32 is the right foundation.
The real-world problems RSP solves
RSP is certainly a technical capability but above anything else, it facilitates operational benefits. Here are the concrete problems it removes from IoT deployments.
No vendor lock-in
Without RSP, the operator written to your SIM at manufacture is the operator you have for the life of the device. If pricing changes, coverage deteriorates, or a better option emerges, you’re stuck unless you physically replace the SIM. RSP turns operator selection from a one-time, permanent decision into an ongoing one.
Our CTO and co-founder, Henrik Aaagard, explains why it’s important:
“It’s about the relationship and partnership you make with a connectivity provider when you’re designing and building your product. You can change the profile afterwards, maybe because the commercial model doesn’t fit in the long term, or three years from now the commercial model of connectivity changes and you want a different commercial relationship with someone else. You’re not tied to the vendor you chose in the beginning. There can be very different strategic reasons for changing things down the line.”
→ Watch the full interview below or read it here:
Global inventory complexity
Many IoT teams maintain separate SKUs for different regions: device variant A goes to Europe with a European SIM, variant B goes to North America with a US SIM. This manufacturing process is very complex and creates logistical overhead and distribution risk. With RSP, you can manufacture a single SKU and provision the appropriate regional profile post-deployment, or even post-sale.
Henrik comments further:
“Before eSIM, you would need to manufacture your devices specifically for those markets and put a physical SIM with a specific operator into those devices. Anyone who’s been in the industry and done hardware knows that manufacturing, logistics, planning, how many devices to allocate to which market, not being able to take a portion of these devices and reschedule it for another market… All of that can suddenly disappear, because now you’re able to change that within the existing hardware whenever it makes sense.”
Eliminate the cost of physical SIM replacement at scale
Physical SIM replacement at scale is wildly expensive. Depending on where devices are deployed, it may mean sending a technician to a rooftop, a shipping container terminal, or a remote agricultural site. RSP replaces a logistics problem with a software operation.
Regulatory and commercial flexibility
Some markets require local operator relationships for compliance or routing reasons. Others have specific data residency requirements. RSP gives you the ability to adapt to those requirements without hardware changes.
End-of-life operator flexibility
A 10-year IoT deployment will almost certainly outlive at least one operator agreement. Operators sunset network technologies (2G and 3G shutdowns being the most widespread current example), change APN configurations, or withdraw from markets entirely. Any of these would traditionally mean a device recall or field service campaign. With RSP, it becomes a scheduled, remote profile update.
Remote SIM provisioning and SIM form factors
Let’s clear this out from the get-go: The form factor is a hardware decision; RSP is a software capability. They are independent of each other in the sense that RSP is not tied to any one form factor. However, whether a given form factor supports RSP depends entirely on whether it runs the eUICC logic underneath.
A SIM form factor refers to the physical shape and size –or, in the case of SoftSIM, the lack thereof!– of the SIM in your device. Historically this meant the size of the removable plastic card (Mini, Micro, Nano). Today it encompasses soldered chips, integrated silicon, and pure software implementations.
RSP works in conjunction with the SIM logic –in this case, eUICC– and the form factor of the SIM, in other words the physical component on your device.
Traditional removable SIM (1FF, 2FF, 3FF, 4FF)
The removable plastic cards that have existed since 1991, shrinking from full-size (1FF) to the nano SIM (4FF) familiar from modern phones. Traditionally, these were UICC SIMs, meaning the profile was fixed at manufacture. However, today there are traditional form factors fully supporting the RSP functionality.
We asked our own Laurent Wijgergangs, Customer Operations Coordinator and expert on all things form factor, how common eUICC and RSP functionality are on the traditional form factors. Here’s what he said:
“Plastic SIMs with eUICC logic are actually quite common. I expect that, as SGP.32 becomes more mainstream, plastic eUICC SIMs will become quite common in IoT.”
Embedded SIM (MFF2, MFF-XS)
Rather than a removable card, MFF2 and MFF-XS are chips soldered directly onto the device’s PCB. This makes them far more durable and resistant to vibration, moisture, and tampering. Critically, they also introduce eUICC support, which means they can carry multiple profiles and have those profiles managed remotely. MFF2 arrived in 2016 and MFF-XS in 2020, with MFF-XS offering a significantly smaller footprint and lower power consumption. These are the most common hardware basis for RSP in consumer devices today.
iSIM (integrated SIM)
Introduced in 2021, the iSIM integrates the SIM functionality directly into the modem or system-on-chip, eliminating it as a separate component entirely. This further reduces PCB footprint and power draw. iSIMs support RSP when built on an eUICC architecture.
SoftSIM (software SIM)
The most recent development in the timeline, SoftSIM eliminates the physical SIM component entirely. The SIM runs as pure software on the device’s existing hardware, removing constraints around chip sourcing and physical form factor. From an RSP perspective, SoftSIM offers the same remote profile management as an eUICC-based form factor, without requiring any dedicated SIM silicon at all.
Key takeaway
Remote SIM Provisioning can work on any form factor as long as it is prepared to run on eUICC. For SGP.32 or eSIM IoT in particular, you might want to make sure that the form factors are also SGP.32-compatible.
Wrapping up
Remote SIM provisioning is ultimately about removing a constraint that has quietly shaped IoT decisions for years: the assumption that connectivity is a consequential, one-off choice made at the point of deployment. For deployments that span borders, last decades, amass to thousands, and cost even more, that quickly becomes an expensive assumption. RSP replaces it with something far more useful: the flexibility to choose connectivity that adapts as your business, markets, and relationships evolve.
It’s worth keeping in mind that RSP is one powerful path to connectivity flexibility, but it comes with added architectural complexity. Before committing, ask yourself three questions:
- Does my deployment scale justify it?
RSP pays off when managing hundreds or thousands of devices across multiple regions or operator relationships; for smaller, stable deployments, the overhead may outweigh the benefit.
- How long will my devices be in the field?
The longer the expected lifecycle, the more likely you are to face operator changes, network sunsets, or shifting commercial terms – exactly the situations RSP is best positioned to address.
- How dynamic is my connectivity strategy likely to be?
If you anticipate switching operators, expanding into new markets, or adapting to regulatory changes over time, RSP is an option worth considering.
If your connectivity needs are geographically broad, a global IoT SIM may achieve the flexibility you need with considerably less complexity. offering access to 680+ networks across 180+ countries through a single profile, with non-steered network selection, one APN, and the freedom to switch operators if your needs change, all without the orchestration overhead of RSP.
