SGP.32 Challenges: The Traps That Break IoT eSIM Rollouts

SGP.32 does one job well: it gets an operator profile onto an IoT eUICC and switches it on, under the control of an eIM, without anyone touching the device. Almost everything a working deployment also depends on sits outside the standard. That covers the phone number, the IP address, the APN, voice and SMS, recovery behaviour, commercial access to profiles and the security of the eIM itself. This guide collects the traps that catch real SGP.32 rollouts, explains why each one happens, and links to the deeper pages on this site.

SGP.32 challenges at a glance

Most SGP.32 failures look identical from the outside: a device that is powered on and silent, or one that reports data while something else has quietly stopped working. The table maps the main traps to where they bite and what prevents them.

Trap	What goes wrong	What prevents it
Identity change	New IMSI, number, IP address and possibly APN after every switch	Device logic that reconfigures itself, and backend systems that do not depend on a fixed identity
Voice and SMS	Data works while calls, SMS commands or alarm messages stop	Checking voice and SMS support profile by profile, and testing both after a switch
Bootstrap	Lapsed in storage, roaming disabled, or blocked by permanent roaming rules	Shelf-life terms in writing, and pilots in the destination country
Download and power	Modem sleeps or battery fails mid-download	Application logic that keeps the modem awake until the operation completes
Recovery	Rollback and fallback are optional or untested	Deliberately failed switches in the pilot
Irreversible actions	Policy rules block disabling or deletion, and deleted profiles are gone	Asking about policy rules before download, and guarding delete operations
Interoperability	Certified components that still do not work together	Testing the exact eUICC, IPA and eIM combination
Lock-in	The first eIM, the profile menu or the contract limits switching	Migration and profile-access terms written into the contract
eIM security	Whoever controls the eIM controls the fleet	Strong admin controls, key custody and certificate planning
Versions and approvals	Wrong certification baseline, or a new operator needing new device approval	Asking which version a supplier is certified against, and checking network approval rules

Where the traps sit across an SGP.32 device's life. Each stage depends on a different party, which is why failures are hard to trace.

1. A profile switch changes the device's identity

Enabling a new operator profile is, in practice, a SIM swap. KORE's device guidance describes it as close to a live SIM change: the device ends up with a new IMSI, MSISDN, IP address and ICCID, and may need a new APN. The host has to notice the change and reconfigure itself. KORE also gives a US example where a fixed APN setting stops working once a device moves onto a Verizon profile, because that profile handles custom APNs differently (KORE).

SGP.32 does not solve the APN problem for you. Its own Connectivity Parameters exist only so the IPA can open a channel to the eIM, and they are defined as data settings such as the APN, login and password. Eseye's engineers make the same point from the field: the standard offers no way to prepare a device for multiple APNs (Eseye). Thingsdata puts the consequence bluntly: without APN logic on the device, a switch leaves it with a new profile and no working connection (Thingsdata).

The bigger risk is everything downstream that was built around the old identity.

What changes	What depends on it	What to test after a switch
IP address	Firewall allowlists, inbound access, IP-based authentication	Remote access and any source-IP rules
APN and routing	Private APN, VPN tunnels, managed platforms	Tunnel establishment and routing to back-end systems
MSISDN (phone number)	Authorised SMS senders, alarm receivers, caller ID checks	SMS commands in both directions and the number receivers see
IMSI and ICCID	Asset records, billing, connectivity management platforms	That inventory and billing systems follow the new identifiers
Voice and SMS service	Diallers, telecare, eCall, SMS alarms	A live call and SMS on the new profile

Eseye's enterprise guidance sums it up: a profile change has to happen alongside matching changes to every other part of the deployment (Eseye). For the IP addressing side of this, see our sister site's guide to networks, APNs and IP addressing.

2. Voice and SMS sit outside the standard

SGP.32 manages profiles, not services. Nothing in the profile download process checks whether the new profile can make calls or carry SMS. The device information an SM-DP+ uses for eligibility describes radio technologies and releases, not IMS voice.

That matters because services vary sharply between providers. Onomondo, for example, states that it does not support VoLTE because its core network has no IMS, and its IoT SIMs have no cellular calling (Onomondo). A device that switches onto a data-only profile keeps its data session and loses its voice service, and nothing in a data dashboard will show it.

SMS changes too. The device's number changes, so routers and alarm panels that only accept commands from authorised numbers, and receivers that expect messages from a known number, can stop working. On 4G and 5G, SMS can be delivered through different network mechanisms, and each operator profile may support a different mix. emnify, for instance, notes that SMS is not supported on NB-IoT at all.

For the voice background, IoTPortal's explainer covers what VoLTE is and why IoT SIMs often lack it.

3. The bootstrap profile is a single point of failure

A device needs a working connection to reach its eIM, and it gets that from the bootstrap profile loaded at manufacture. If bootstrap cannot attach, nothing else in SGP.32 can happen. Our page on eSIM bootstrap issues covers the mechanics; the field failures are more mundane.

Simplex Wireless lists them in its October 2026 pilot guidance: a bootstrap profile that lapsed while devices sat in storage, a device switched on abroad with roaming disabled, and an APN that was wrong in the destination country. Its advice is to age some pilot units on purpose, get bootstrap shelf-life terms in writing, and ship a few units through the real logistics route so the first power-on happens where customers will do it (Simplex Wireless).

Regulation adds another layer. Bootstrap profiles usually roam, and Wireless Logic's guidance notes that Turkey, China and India do not permit permanent inbound roaming, while Brazil limits it to 90 days (Wireless Logic). In those markets the bootstrap has to be good enough to reach the eIM quickly and pull a local profile.

4. Downloads need power, time and an awake modem

Most eSIM management traffic is small, but a profile download is not. KORE puts it at roughly 30 KB to 50 KB of data (KORE). Eseye notes that the modem has to stay on until the download completes, so the device application must coordinate with it rather than putting the modem to sleep on its usual schedule (Eseye).

Battery devices using power saving modes are the most exposed. Eseye also acknowledges a small but real risk that a failed switch leaves a device with no connectivity at all, which is costly for a battery-powered device in a remote location (Eseye).

5. Recovery is optional, and often untested

SGP.32 includes recovery mechanisms inherited from the M2M world: rollback, fallback and an emergency profile (Trusted Connectivity Alliance). The wording in the specification matters, though. In v1.2 the IPA may roll back if a newly enabled profile fails to provide connectivity, and may trigger the Fallback Mechanism on a permanent loss of connectivity. How that loss is detected is left to the implementation. CSL also describes the Fallback Mechanism as optional (CSL).

Implementations differ in detail. Eseye's documentation, for example, says its devices enable the fallback profile after up to 23 minutes when the active profile loses connectivity or is rejected, and that the fallback profile cannot be deleted (Eseye). Two points follow. First, a fleet's ability to recover depends on how its vendor built recovery, not on the standard. Second, a device that falls back onto a profile with fewer services, such as no voice or a different APN, has recovered its connection but not its function.

Simplex's pilot advice applies here too: test the second switch, not just the first, and cause failures on purpose to watch the recovery path work (Simplex Wireless).

6. Some actions cannot be undone

Operator profiles can carry Profile Policy Rules. Microsoft's eSIM documentation summarises the two that matter most: PPR1 means the profile cannot be disabled, and PPR2 means it cannot be deleted (Microsoft). A profile with these rules is a hard technical lock, whatever the commercial contract says, so ask whether any profile carries them before it goes onto a fleet.

Deletion is also permanent in practice. Telnyx's documentation warns that a deleted eSIM profile cannot be downloaded again and has to be replaced with a new one (Telnyx). Clean-up scripts that delete unused profiles across a fleet deserve the same caution as any other irreversible bulk action.

7. Certified components can still fail to work together

SGP.32 leaves room for choice, and every choice is a chance for mismatch. The specification lets eIM instructions be fetched by the device or pushed to it, and the eIM and IPA must support the same mode and the same secure connection method, either HTTPS or CoAP over DTLS. Indirect profile download, where the eIM fetches the profile for the device, needs support declared on both sides. An IPA built into the eUICC (IPAe) is optional. Our comparison of IPAe and IPAd explains why that choice matters.

Simplex Wireless warns that two implementations can each comply with SGP.32 and still not work together. Error reporting is one example: eUICC families encode errors differently within the range the specification allows, so an eIM tested against one chip family can fail silently on another. Its advice is to ask the eIM vendor to name the eUICC families it has actually tested (Simplex Wireless).

Labels can mislead as well. Techship notes that some products sold as SGP.32 are SGP.22 with proprietary extensions, and recommends checking that eUICC reset and eIM removal work as the specification defines (Techship). Onomondo adds that each profile has to be confirmed on your specific eUICC and eIM combination, not merely possible in principle (Onomondo). At the modem level, the same gap is covered in our SGP.32 modem compatibility guide, and older SGP.02 devices cannot be upgraded to SGP.32 in software at all (KORE).

8. Lock-in moves rather than disappears

SGP.32 removes the hard-wired operator lock of SGP.02, but control can still settle elsewhere. This is the argument of our editorial SGP.32 didn't end operator lock-in, it moved it, and the field evidence keeps supporting it.

The first eIM. The eUICC must support operations to add and change eIMs, but an eIM is not obliged to expose them to the customer. If the initial eIM will not allow another to be added, the fleet stays dependent on it. euicc.co.uk examines this in its piece on Onomondo's independent eIM.
Migration needs cooperation. Moving to a new eIM relies on the current provider to start the transfer, so migration terms belong in the contract. See our guide to eIM portability.
The profile menu. Onomondo notes that a vendor can decline to orchestrate downloads from operators it does not sell, making the lock commercial rather than technical (Onomondo).
Operator support and cost. Velocity IoT reports uneven operator support across regions, separate commercial agreements for each operator, and switching and hosting fees that add up (Velocity IoT). emnify makes the same point: whether cross-operator choice is real depends on how the platform implements the eIM layer (emnify).

Our checklists of what to ask an eSIM provider and what to ask a hardware provider turn these into contract questions.

9. The eIM is now the most valuable target

SGP.32 replaces the human approval step of consumer eSIM with signed instructions from the eIM, which the eUICC accepts without local confirmation. P1 Security points out what that means for risk: whoever can change which eIM is associated with a fleet has, in effect, taken the fleet. The realistic threats are those of any management console, including administrator accounts without multi-factor authentication, API flaws that let one tenant act on another tenant's devices, and weak custody of the eIM signing key (P1 Security).

Certificates need planning too. The IPA has to trust the eIM's TLS certificate or the authority that issued it, and eIM certificates can be revoked. Over a 10 to 15 year device life, certificate rotation and trust updates should be designed in from the start, not discovered when a certificate expires.

10. Versions, certification and network approval

SGP.32 v1.3 was published on 28 May 2026, but formal certification still tracks v1.2. Our SGP.32 v1.3 explainer covers what changed. Suppliers are moving: Kigen has announced what it describes as the first security-certified automotive eSIMs supporting v1.3 (IoT Business News). The useful question for any supplier is which version it holds formal certification against, and when it expects to certify against v1.3.

Network approval is a separate hurdle. Onomondo notes that the device itself carries GCF or PTCRB certification for its profile assistant (Onomondo). In North America that is not the end of it: AT&T requires its own device approval on top of PTCRB, and other carriers run comparable programmes (Spilma). Switching a fleet onto a new operator's profile can therefore mean a new device approval, not just a new profile.

11. Emergency profiles and eCall

SGP.32 includes an Emergency Profile, designed for vehicle eCall. While it is active, the eUICC rejects eIM management instructions, memory resets and fallback with an ecallActive error, so an emergency call is never interrupted by fleet management. v1.3 refines this handling, and Kigen's v1.3 automotive eSIMs list emergency profile handling among their supported features (IoT Business News).

The trap is the profile behind it. In the EU, vehicle eCall systems have had to support packet-switched Next Generation eCall from 1 January 2026, as the European Emergency Number Association noted in its submission to BEREC. NG eCall is an IMS emergency call, so the Emergency Profile has to deliver working VoLTE emergency calling wherever the vehicle is. The European Emergency Number Association has warned that with permanent roaming profiles NG eCall may not work unless compatible VoLTE roaming has been negotiated (EENA).

What to test after every profile switch

Most of these traps are caught by one habit: treating every profile switch as a change that needs verifying, not just a command that returned success.

The device re-attaches and opens a data session on the correct APN.
Remote access, VPN tunnels and IP allowlists still work with the new address.
SMS works in both directions, and authorised-number lists and alarm receivers recognise the new number.
Voice devices register for IMS and complete a test call, including emergency or alarm receiving centre calls where relevant.
Inventory, billing and the connectivity management platform show the new IMSI and ICCID.
Rollback and fallback behave as expected when the switch is deliberately made to fail.
A second switch, to a different network, works on live devices before the fleet relies on it.

Frequently asked questions

What are the main SGP.32 challenges?

The main challenges sit outside the profile switch itself: the device identity changes, voice and SMS are not checked, bootstrap profiles can lapse or be blocked, recovery is optional, certified components can fail to interoperate, and control of the eIM becomes the new point of lock-in and risk.

Does an SGP.32 profile switch change the IP address and phone number?

Usually, yes. Enabling a new operator profile behaves like a SIM swap, so the device normally gets a new IMSI, ICCID, phone number and IP address, and may need a different APN. Anything built around the old identity has to be updated.

Does SGP.32 check whether a profile supports voice or SMS?

No. SGP.32 manages profile download and state. Whether a profile includes voice or SMS depends on the operator and the profile content, so both have to be checked profile by profile and tested after a switch.

Can a failed SGP.32 switch leave a device offline?

It can. Rollback and fallback are defined in the specification but depend on how each implementation detects loss of connectivity, so recovery has to be tested by deliberately failing a switch during a pilot.

Can an operator stop a profile being disabled or deleted?

Yes. Profile Policy Rules can prevent a profile from being disabled (PPR1) or deleted (PPR2). Ask whether any profile carries these rules before it is downloaded to a fleet.

Which SGP.32 version should hardware be certified against?

Version 1.2 remains the certification baseline, even though v1.3 was published on 28 May 2026. Ask suppliers which version they are certified against and when they expect to certify against v1.3.

SGP.32 Challenges: The Traps That Break IoT eSIM Deployments