Most of the eSIMs shipped last year will never be touched by a human hand again. The Trusted Connectivity Alliance, the trade body for the companies that manufacture SIM chips, puts global eSIM shipments at 605 million units in 2025, up 18% on the year before, and its latest shipment estimate also notes a sharp rise in the number of subscription platforms that can download profiles under the new IoT standard, SGP.32.
That second point is the one that matters if you run connected devices for a living. A tracker bolted under a trailer, a meter in a basement, a camera on a dashboard: once those are in the field, nobody is driving out to swap a plastic SIM because a carrier contract changed or a device crossed a border. eSIM remote provisioning is the set of rules that lets you change the carrier inside the device from a desk, and SGP.32 is the version of those rules written for devices that have no screen, no keyboard, and sometimes only a few kilobytes of data a day.
This guide walks through the whole thing in plain language: what an eSIM and an eUICC actually are, what a profile is, why the GSMA (the global association of mobile network operators) had to write a third standard, what happens step by step when a profile downloads, and what to check before you roll it out across a fleet. Every acronym gets an everyday explanation the first time it shows up.
What remote SIM provisioning means for an IoT device
Remote SIM provisioning (RSP) is the process of loading a carrier’s identity onto a SIM, or changing it for a different carrier’s identity, over the air, without anyone touching the device. “Over the air” just means through the mobile network itself, the same way a phone gets a software update.
On an ordinary plastic SIM the carrier identity is burned in at the factory and never changes. If you want a different carrier, you want a different card. Remote SIM provisioning breaks that link. The physical chip stays put for the life of the device, and the carrier identity becomes a file you can download, switch on, switch off, or delete from a management console.
For an IoT device the practical difference is this. Say you have 2,000 asset trackers on rail wagons. They were shipped with a carrier that worked in the country of manufacture. Half of them now spend most of their time two countries over, where that carrier’s roaming deal is poor. With plastic SIMs you have a logistics job: find the wagons, open the housings, swap 1,000 cards, hope none of the seals fail. With remote provisioning for IoT you select those 1,000 devices in the console, push a new profile, and the swap happens on the next connection.
Who offers this at scale? Any connectivity provider that either runs or partners with a profile-preparation server (more on that below) and gives you a management platform to trigger downloads in bulk. The questions worth asking are less about whether a provider “supports eSIM” and more about which remote provisioning standard they support, which carriers’ profiles they can actually deliver in the countries you care about, and whether the bulk operations happen in a console you can use yourself or through a support ticket.
eSIM, eUICC and profiles: the three terms you need
These three words get used interchangeably in sales copy and they should not be. Each one has a precise meaning, and the differences are what make eSIM profile provisioning work.
eSIM (embedded SIM). An eSIM is a SIM that is built into the device rather than slotted into it. In its purest form it is a small chip (the MFF2 package, about 6 by 5 millimetres) soldered straight onto the circuit board. The important thing to understand is that the SIM itself never moves. What changes is the profile loaded onto it. Confusingly, the same remotely programmable chip is also sold in ordinary plastic card shapes (2FF, 3FF, 4FF), so “eSIM” in practice means “remotely programmable SIM” more than it means “soldered SIM.”
eUICC. The eUICC (embedded Universal Integrated Circuit Card) is the technical standard for the chip itself: a SIM chip that can hold more than one carrier profile at once and switch between them on command. eUICC is the hardware and the rulebook; eSIM is the everyday name people use for the same thing. When a buyer asks for “eUICC-enabled SIMs” they are asking for cards that can be remotely provisioned, as opposed to ordinary SIMs that cannot.
Profile. A profile is the bundle of data that makes a SIM belong to a particular carrier: the subscriber identity number (the IMSI), the secret keys used to prove that identity to the network, the network settings, and any small applications the carrier wants on the card. A profile is the thing that gets downloaded, enabled, disabled, or deleted during eUICC remote provisioning. One eUICC can store several profiles, but only one is active at a time.
What does this mean for a fleet tracking deployment? Your trackers are not “on AT&T” or “on Verizon” in any permanent sense. They hold an AT&T profile, or a Verizon profile, and that profile is a decision you can revisit. A vehicle sold into a new territory, a telematics contract that moves to a new carrier at renewal, a regional network that gets switched off: each of these becomes a profile change pushed from your console, not a truck roll.
What SGP.32 is and why the GSMA created it
SGP.32 is the GSMA’s technical specification for remote provisioning of eSIMs in IoT devices. It was published to replace the older machine-to-machine approach (SGP.02) for devices that are “network constrained” or “user interface constrained,” which is standards language for devices with a thin data connection, no screen, or both.
The GSMA is the industry association that mobile network operators and their suppliers belong to, and it is the body that writes the eSIM rulebooks so that a chip from one manufacturer, a profile from any carrier, and a management server from a third company all work together. Its published eSIM IoT technical specification describes SGP.32 as covering the remote provisioning and management of the eUICC in network-constrained and user-interface-constrained devices, the eUICC architecture for those devices, the interfaces between the pieces, and the security functions that hold it all together.
Why was a third standard needed? Because the two earlier ones each assumed something IoT devices often cannot provide.
The consumer standard assumes a person. Someone scans a QR code, taps “download,” and confirms on a screen. A pressure sensor on a pipeline has no screen and no person.
The older machine-to-machine standard assumes the carrier’s servers can push to the device using SMS-based commands and a heavyweight, carrier-controlled server relationship. That worked for connected cars with big modems and big budgets. It did not fit a battery-powered device sending a few bytes a day over a low-power network, and it made switching between carriers slow and expensive, because every carrier pair needed a bespoke integration.
SGP.32 sits in between. It borrows the download mechanism from the consumer world, which is light and widely deployed, but replaces the human with two pieces of software. These are the three new terms you need.
eIM (eSIM IoT remote Manager). The eIM is the server-side control tower. It is the component that tells devices which profile to download, which to enable, and which to delete. The device owner, or the connectivity provider on the owner’s behalf, operates the eIM. It is the place where “switch these 1,000 trackers to the new carrier” actually gets issued.
IPA (IoT Profile Assistant). The IPA is the small piece of software on the device, or inside the cellular module, that carries out the eIM’s instructions. It is the agent on the device. It talks to the eIM, fetches the profile from the preparation server, and hands it to the eUICC. It does the job the person with the phone would have done under the consumer standard.
SM-DP+ (Subscription Manager Data Preparation). The SM-DP+ is the server that holds carrier profiles, encrypts each one for the specific eUICC that will receive it, and hands it over during a download. Carriers load their profiles here; devices fetch them from here. The “plus” marks the newer version of this server used by the consumer and IoT standards, as opposed to the older SM-DP used in the machine-to-machine world.
If you remember one sentence from this section, make it this one: SGP.32 remote provisioning replaces the person tapping a screen with an eIM giving orders and an IPA carrying them out, so that a device with no screen and a tiny data budget can still change carriers from a desk.
SGP.02 vs SGP.22 vs SGP.32: which standard fits which device
There are three GSMA remote provisioning approaches in use today. They are often described as “M2M,” “consumer,” and “IoT.” The table sets them side by side.
| SGP.02 (M2M) | SGP.22 (consumer) | SGP.32 (IoT) | |
|---|---|---|---|
| Written for | Connected cars, industrial gateways, early machine-to-machine devices | Phones, tablets, watches | Sensors, trackers, meters, cameras and other devices with no screen or a thin data link |
| Who starts a profile change | The carrier’s or provider’s server pushes it (SM-SR) | The person holding the device pulls it (scans a code, taps download) | The eIM issues the instruction; the IPA on the device carries it out |
| Needs a person at the device | No | Yes | No |
| Needs SMS to reach the device | Usually yes | No | No; can use lightweight data protocols |
| Fits low-power networks (LTE-M, NB-IoT) | Poorly | Poorly | Yes, by design |
| Ease of moving between carriers | Slow; each carrier pair needs a bespoke server integration | Easy for one device, but manual | Designed for bulk, remote, multi-carrier switching |
| Status | Being phased out for new IoT designs | Current | Current; the direction of travel for new IoT designs |
A few plain-language notes on the table.
If a person will hold the device, use SGP.22. A ruggedised tablet issued to a driver is a consumer-style device even if the company that owns it is a logistics firm.
If the device is already deployed on SGP.02, it will keep working. The machine-to-machine standard is not switched off. What changes is that new designs are steering toward SGP.32 because the eUICC on an SGP.02 device cannot be migrated to SGP.32 remotely; the two standards use different profile-download mechanisms, so the choice is made at design time.
If the device has no screen and will live in the field for years, SGP.32 is the standard to design around. That covers most of what gets called IoT.
One honest caveat: not every deployment needs remote profile switching at all. The single largest telematics customer Trafalgar Wireless supports chose a single-network IoT SIM on purpose. For a fleet that lives inside one carrier’s footprint, one carrier relationship is simpler to bill and to troubleshoot, and remote profile switching adds a moving part it will never use. eSIM remote provisioning is the right tool when the device’s life will outlast your carrier decision, not a default for every project.
How an SGP.32 profile download works, step by step
Here is what happens, in order, when an IoT device receives a new carrier profile under SGP.32. The three actors are the eIM (control tower), the IPA (agent on the device), and the SM-DP+ (profile store).
- The device ships with a bootstrap profile. The eUICC leaves the factory with a starting profile already loaded, so the device can connect to some network the first time it powers up. Without this, the device would have no way to reach the servers that will give it its real profile.
- The device is registered with the eIM. The owner’s eIM is told the identity of the eUICC (its EID, a unique serial number for the chip) and which device it belongs to. This can happen in bulk from a manufacturing file.
- A carrier profile is prepared on the SM-DP+. The chosen carrier, or the connectivity provider acting for it, loads a profile onto the SM-DP+ and links it to the target EID. The profile is encrypted so that only that specific eUICC can open it.
- The eIM issues a download order. An operator selects the device (or a thousand devices) in the management console and instructs the eIM to download the new profile. The order waits until the device next checks in. This is the point where eSIM remote provisioning stops being a concept and becomes a queued job.
- The IPA on the device receives the instruction. When the device connects over its bootstrap profile, the IPA polls the eIM, or receives a lightweight trigger, and learns that a download is waiting, along with the address of the SM-DP+.
- The IPA fetches the encrypted profile from the SM-DP+. The eUICC and the SM-DP+ first prove their identities to each other using digital certificates issued under the GSMA’s certificate scheme. Only then does the profile package come down, still encrypted, and the IPA passes it to the eUICC to install.
- The eIM issues an enable order. Download and enable are separate steps. The new profile sits installed but inactive until the eIM says to switch it on. This lets you stage downloads in advance and flip the switch at a chosen moment.
- The eUICC enables the new profile and the device re-attaches to the network. The modem restarts its network registration using the new carrier identity. If the new profile fails to register within a set window, the eUICC falls back to the previously enabled profile so the device is never stranded. The IPA reports the result back to the eIM, and the console shows the device on its new carrier.
That is the whole eSIM profile provisioning loop. Nobody visits the device. The only thing the integrator has to design in is an IPA that the module or the device firmware can run, and a way for the device to reach the eIM on its bootstrap profile.
Switching carriers remotely: what happens on the device
Once a device holds more than one profile, switching between them is the same enable and disable sequence as the last two steps above, minus the download. The eIM sends an enable order for profile B; the eUICC disables profile A, enables B, and the modem re-registers. From the device’s point of view it is a reboot of the radio, not a reboot of the device.
Roaming is where the value of eUICC remote provisioning shows most clearly. A device that roams onto a foreign network with a home-country profile is a guest there, paying guest rates and subject to whatever limits the host network or the host country’s regulator sets. A device that downloads a local profile becomes a native subscriber. Same hardware, same SIM, different legal and commercial footing. For devices that spend their lives in one foreign market, a local profile is usually the better long-term answer; for devices that cross borders every week, a multi-network profile that roams well is usually simpler.
“Carrier-agnostic” is the phrase buyers use for what they want here, and it is worth pinning down. A carrier-agnostic setup for remote SIM provisioning is one where the eUICC, the eIM and the SM-DP+ are not owned by the carrier whose profile happens to be active. That is what lets you leave. If the provisioning servers belong to one carrier, you can download that carrier’s profiles beautifully and nobody else’s.
A designed carrier-swap workflow, then, has four parts: a bootstrap profile that reaches the eIM from anywhere you ship to; an eIM run by you or by a provider that is independent of the carriers; profiles from more than one carrier prepared on an SM-DP+ you can reach; and a fallback rule so that a failed switch reverts automatically.
Multi-IMSI versus eUICC profile switching. These two are frequently confused because both let a device use more than one carrier. A multi-IMSI SIM keeps several carrier identities (IMSIs) inside a single profile, and a small program on the card, an applet, picks which identity to present based on where the device is and which networks it can see. The switch is automatic, fast, and needs no server instruction. An eUICC, under SGP.32 remote provisioning, swaps entire profiles on command from the eIM. The multi-IMSI approach suits devices that move between countries constantly and need the card to sort itself out; eUICC profile switching suits devices whose carrier relationship needs to change deliberately, for commercial or regulatory reasons, years after they shipped. Trafalgar Wireless supplies both: multi-IMSI IoT data plans where two or more network profiles live in the same SIM and the applet selects the best one by location, and eUICC eSIMs where the whole profile is provisioned over the air. Fleet and asset-tracking operators with cross-border routes generally start with multi-IMSI; operators with long-life fixed installations, or who expect to renegotiate carriers, lean on eUICC.
Where profiles come from: bootstrap, factory (IFPP), and over-the-air
In IoT eSIM provisioning a profile has to get onto the eUICC somehow, and there are three routes. Which one suits you depends mostly on how many devices you build and where they go.
Bootstrap profile. This is the starting profile shipped on every eUICC so the device can connect on first power-up and then download its permanent profile. A good bootstrap profile roams widely (it has to work wherever the box gets opened) and is expected to carry very little data, because its only job is to reach the eIM. Some deployments never move beyond the bootstrap profile if it happens to be a strong multi-network profile already; that is fine for small volumes, and it is how many pilots run.
In-factory profile provisioning (IFPP). IFPP is loading the profiles at the factory, before the device ships. The eUICC is personalised on the production line with the bootstrap profile and, where the destination is known, the operational profile too, so the device arrives at its site ready to connect natively with no download step in the field. This is the answer to the question of which profile suits mass production of IoT devices: for high-volume builds heading to known markets, factory provisioning removes the first-connection risk entirely, and the over-the-air path stays available for later changes. It works with both plastic eSIM cards and embedded MFF2 chips. There is a fuller walkthrough in our earlier post on in-factory profile provisioning.
Over-the-air download. This is the SGP.32 path described above: bootstrap first, then eIM-driven download once the device is in the field. It is the right route when you do not know at build time where a device will end up, when the fleet is spread across many markets, or when you expect the carrier to change during the device’s life.
Most real programmes use two of the three. A common pattern is IFPP for the bootstrap plus over-the-air for the operational profile, so the factory does one thing for every unit and the field does the market-specific part.
Security in remote provisioning: what protects the profile
The question behind “is eSIM secure?” is really “who can put a profile on my device, and who can read it?” The SGP.32 design answers both.
Mutual certificates. Before any profile moves, the eUICC and the SM-DP+ prove their identities to each other using digital certificates issued under the GSMA’s certificate scheme. The eUICC manufacturer (the EUM) signs the chip; the SM-DP+ operator holds its own certificate. A server without a valid certificate cannot push a profile, and a chip without one cannot receive it.
Profile encryption per chip. The SM-DP+ encrypts each profile for one specific eUICC using keys agreed during that mutual authentication. Intercepting the download gives an attacker a blob that only the target chip can open.
The eUICC as a hardware vault. The keys inside a profile never leave the chip. The modem asks the eUICC to prove its identity to the network and the chip does the maths internally; the secret itself is not readable by the device’s own firmware, let alone by anyone on the network.
Control over the eIM. In SGP.32 the eIM is the only thing that can order a download, enable, or delete. Whoever holds the eIM credentials holds the keys to your fleet’s connectivity, so the access controls on the management console matter as much as the cryptography underneath. Ask any provider who can log in to it and how that access is logged.
Beyond the standard itself, the same protections you would apply to any IoT SIM still apply during IoT eSIM provisioning. An IMEI lock ties a profile to one device’s hardware identity so that a SIM pulled from a tracker will not work in a stranger’s modem. A private APN keeps device traffic off the public internet and inside a network segment you control.
Regional and regulatory points to check before you provision
Remote provisioning for IoT removes the physical barrier to changing carriers. It does not remove the legal ones. Four things to check for every country a device may operate in.
Permanent roaming rules. A handful of countries limit how long a foreign SIM may roam on their networks, or require that devices in permanent use hold a subscription with a local operator. Brazil and Turkey are the two that come up most often, and the rules change. If a device will live in one of these markets, plan for a local profile from day one rather than treating roaming as permanent.
Local-profile requirements and who can supply them. Being able to download a local profile technically is not the same as having a carrier in that country willing to issue one to your SM-DP+. Ask your provider, market by market, which carriers’ profiles they can actually deliver, not just which networks their roaming profile can see.
Which carriers support eSIM for IoT in each region. Support is uneven. In the United States, for example, Trafalgar Wireless provisions on AT&T and Verizon and covers T-Mobile through roaming, and our multi-network eSIMs reach over 500 networks in about 180 countries through one SIM source; but the ability to provision a native profile through eUICC remote provisioning, as opposed to roaming, still depends on carrier-by-carrier agreements in each country. Get the list in writing for the markets that matter to you.
Device approvals and data rules. A profile change does not alter the radio, but a device sold into a new market may still need type approval there, and some countries restrict where device data may be stored or routed. These are outside the eSIM standard but they will surface in the same project plan.
The practical advice is simple: list the countries, list the expected years in service, and ask the provider to map a profile source and a fallback to every row. A deployment that cannot answer “what happens in year four when this carrier changes its roaming terms” is a deployment that will need a truck roll.
What SGP.32 changes for a fleet or asset-tracking rollout
For a vehicle fleet or an asset-tracking estate, the change is less about the technology and more about what you no longer have to decide up front.
Under plastic SIMs, the carrier decision was permanent. You chose a carrier at purchase, and unchoosing it meant physical work on every unit. Under SGP.32 remote provisioning, the carrier decision becomes reversible, which changes three practical things.
Procurement can be staged. You can ship trackers with a strong bootstrap profile, prove the deployment, and negotiate carrier terms afterwards from a position of having devices already in the field.
Cross-border expansion stops being a hardware project. A fleet that adds routes into a new country can push a profile suited to that country to the affected vehicles only, and leave the rest alone.
End-of-life for a network becomes a scheduled task. When a carrier retires a 3G or, eventually, a 4G band that your devices rely on, the fix is a profile change to a carrier still supporting the band, not a fleet-wide hardware refresh.
The design cost is real but small: you need a module that can run an IPA, which most current LTE-M, NB-IoT and LTE Cat 1 modules from the main vendors can, and you need to choose a connectivity provider whose management platform exposes bulk profile operations. For fleets that already use a video-telematics or GPS-tracking platform, the eSIM management usually sits alongside it rather than inside it. Our page on IoT connectivity for transportation covers how that looks for vehicle fleets.
How Trafalgar Wireless handles eSIM provisioning
Trafalgar Wireless supplies eSIM and eUICC IoT SIMs, in the embedded MFF2 package and in the 2FF, 3FF, 4FF and tri-cut plastic formats, for companies deploying connected products at volume: fleet and video-telematics operators, asset-tracking providers, and manufacturers building connectivity into their own devices. Profiles are provisioned over the air in line with the GSMA eSIM specifications, so a device can be shipped with a bootstrap profile and receive or change its operational profile after deployment without a card swap. For manufacturers, we also support in-factory profile provisioning so that high-volume builds leave the line with the right profile already loaded.
All of it is managed through IoT Suite, our SIM management platform, where an operator can see every SIM, activate, suspend, provision and monitor usage in one console. Multi-network coverage is available across 500+ networks in 180+ countries, and multi-IMSI plans are available for devices that need the card to pick a network automatically as it travels.
Two observations from our own conversations shape how we advise on eSIM remote provisioning. First, the buyers who get the most out of eUICC are the ones replacing a provider they have outgrown; they know what a locked-in carrier costs and they specify eUICC deliberately. Second, the strongest single-network relationship we have is with a customer who chose single-network on purpose and has no need to switch. We do not push profile switching on projects that will never use it. We would rather ask what the device will be doing in year four and design the profile plan from there.
Frequently asked questions
Does SGP.32 work with LTE-M and NB-IoT devices?
Yes. SGP.32 was written specifically for devices with small data budgets and no user interface, which is exactly what LTE-M and NB-IoT devices are. The reason it fits is that it does not require the device to run the full consumer-style download client that a phone uses; the IPA on the device is deliberately lightweight, and the message exchange with the eIM is designed to work over the thin, intermittent links these low-power networks provide. The practical requirement is that the module vendor has implemented an IPA, which the mainstream LTE-M and NB-IoT modules now do.
Can I switch an eSIM profile without a data connection?
No. The device needs a working connection, usually over the bootstrap profile or the currently enabled profile, to receive the eIM’s instruction and, for a new profile, to download it from the SM-DP+. This is why the bootstrap profile matters so much in remote provisioning for IoT: it is the connection you fall back on to make any change at all. If a switch fails, for example because the newly enabled profile cannot register on any visible network within its time limit, the eUICC automatically reverts to the previous profile so the device is not stranded without service.
Is a multi-IMSI SIM the same as an eUICC eSIM?
No. A multi-IMSI SIM holds several carrier identities inside one profile and switches between them automatically using an applet on the card, with no server instruction needed. An eUICC eSIM holds whole separate profiles and switches them on command from an eIM, which is what remote SIM provisioning under SGP.32 means in practice and what lets you change carriers deliberately years after deployment. Both are sold as “multi-network”; they solve different problems.
Do I need SGP.32 if I already use multi-network SIMs?
It depends on how long the devices will live and how much your carrier relationships might change. You probably do need it for devices expected to run for five or more years, for deployments where the carrier contract is likely to move at renewal, and for devices going into countries with permanent-roaming limits that will eventually need a local profile. You probably do not need it for short-life or pilot deployments, for devices that stay inside one carrier’s home footprint, or for cross-border fleets that a good multi-IMSI plan already handles. Plenty of successful deployments run on multi-network plastic SIMs with no eUICC remote provisioning at all.
How long does a remote profile download take?
It depends on the network speed available to the device, the size of the profile, and how often the device checks in with the eIM. Over a healthy LTE connection the download itself is a matter of seconds to a minute or two; over NB-IoT it can take considerably longer, and the total time from issuing the order to the device running on the new profile is governed mostly by when the device next connects. Plan the timing around the device’s check-in schedule rather than the download speed.
Key takeaways
- eSIM and eUICC are not the same word. eUICC is the chip standard that can hold and switch multiple carrier profiles; eSIM is the everyday name for it. The SIM stays put; the profile is what changes.
- A profile is a downloadable carrier identity. It is what gets loaded, enabled, disabled, or deleted during eSIM remote provisioning.
- SGP.32 replaces the person with software. The eIM (control tower) issues orders; the IPA (agent on the device) carries them out; the SM-DP+ holds the profiles. That is what makes remote SIM provisioning possible on a device with no screen and a tiny data budget.
- Pick the standard at design time. SGP.22 for devices a person holds, SGP.02 for existing machine-to-machine estates, SGP.32 for new IoT designs. An SGP.02 device cannot be moved to SGP.32 remotely.
- Bootstrap, factory, or over-the-air. High-volume builds to known markets suit in-factory provisioning; unknown destinations suit over-the-air; most programmes use both.
- Multi-IMSI and eUICC solve different problems. Automatic in-card switching for constant travellers; deliberate profile changes for long-life or renegotiated deployments.
- The law does not change when the SIM does. Check permanent-roaming limits, local-profile availability, and carrier eSIM support for every country before you provision.
Where to go from here
The useful question is not “should we use eSIM” but “what will this device need to do in year four that we cannot predict today.” If the honest answer includes a carrier change, a new country, or a retired network band, remote provisioning belongs in the design. If it does not, a good multi-network SIM may be all you need, and there is no prize for over-engineering a tracker.
If you are a fleet, telematics, or asset-tracking operator weighing eSIM remote provisioning for a new deployment, or replacing a provider that has locked you to one carrier, Trafalgar Wireless supplies eUICC IoT SIMs, over-the-air profile provisioning, and the IoT Suite platform to manage them, with an account manager who is also your service manager. Talk to an IoT Connectivity Expert.
