Why Did SGP.32 Introduce CoAP in Addition of HTTPS for IoT eSIM Provisioning?

A smart meter on NB-IoT wakes up for a few seconds a day, sends its reading, and goes back to sleep. It has no screen, no user nearby, and a battery that has to last a decade. Ask that device to run the same protocol stack a phone uses to download an eSIM profile, and it either fails outright or burns through years of battery life doing it. That mismatch is exactly why SGP.32 doesn’t use the same transport as the standards before it.

What it is and how it works

The protocol choice has changed with every generation of the GSMA’s remote provisioning standards, and each change tracks the devices it was built for. SGP.02, the original machine-to-machine standard, used SMS to trigger profile changes, coordinated through a Subscription Manager Secure Routing (SM-SR) server that pushed instructions to the device. SMS worked because early M2M devices sat on 2G and 3G networks where it was universally available, but it’s a channel many newer IoT networks, including NB-IoT, don’t support at all.

SGP.22, the consumer standard, replaced that with HTTPS over TCP, paired with a QR code the user scans and a Local Profile Assistant (LPA) running on the phone that handles the download. That model assumes a screen, a user, and a device with the power budget of a smartphone. None of those assumptions hold for a battery-powered sensor.

SGP.32 drops both of those and defines CoAP (Constrained Application Protocol) over UDP, secured with DTLS, as its lightweight transport option, alongside the standard HTTPS/TCP path for devices well-connected enough to use it. CoAP keeps the same request-response shape as HTTP but strips out the overhead that makes plain TCP and TLS expensive to hold open on a constrained radio link. On the device side, an IoT Profile Assistant (IPA) replaces the LPA and speaks CoAP to the eIM, the server-side manager that decides what happens to a device’s profile and when.

Why it matters for IoT specifically

TCP’s overhead comes from the handshake it needs before any data moves, and TLS adds another handshake on top of that. On a well-connected phone that cost is invisible. On NB-IoT or LTE-M, where a device might have a data budget measured in kilobytes and a radio that’s asleep most of the day, that same handshake can eat a meaningful chunk of a device’s power and airtime just to say hello. UDP skips the connection setup entirely, and CoAP was purpose-built to run on it while DTLS still provides the authentication and encryption the profile exchange needs.

This is also what makes the provisioning model asynchronous rather than user-driven. A device doesn’t need to be actively browsing or scanning anything. It wakes on its own schedule, checks in briefly, and the eIM can push a profile change during that short window. That’s the difference between a model built around a person tapping a screen and one built around a sensor that spends 99 percent of its life asleep.

What can go wrong

The most common misunderstanding is treating CoAP as a lightweight or lower-security shortcut. It isn’t. DTLS provides the same category of cryptographic protection TLS does, adapted to run over UDP, and SGP.32 still requires mutual authentication between the eIM and the eUICC regardless of which transport carries it.

The second mistake is assuming every SGP.32 device has to use CoAP. It doesn’t. SGP.32 supports HTTPS over TCP as well, for devices with the power and connectivity to justify it, and CoAP as the option for genuinely constrained hardware. Picking the wrong one for your device class either wastes a battery budget you didn’t need to spend or asks a constrained radio to do something it can’t sustain.

The third is underestimating what a CoAP/DTLS stack asks of a module or firmware team. Not every existing modem or cellular module ships with a certified CoAP implementation, and interoperability between eUICC, module, and eIM is still something to verify directly rather than assume from a spec sheet, since compliance with SGP.32 on paper doesn’t guarantee two vendors’ implementations behave identically together in practice.

What to do about it

Three things worth checking before you commit to a device design. First, confirm with your module or chipset vendor that CoAP over UDP with DTLS is actually implemented and certified, not just planned. Second, ask whether your eUICC handles the CoAP stack itself (IPAe) or leaves it to your device firmware (IPAd), since that choice changes how much engineering work lands on your team. Third, size your power budget around the transport your device will actually use. A device on HTTPS/TCP and one on CoAP/UDP have meaningfully different energy profiles, and assuming the lighter one by default without checking your specific hardware is a common source of surprises late in a project.

The protocol change from SGP.02’s SMS to SGP.22’s HTTPS to SGP.32’s CoAP isn’t an arbitrary spec update. Each one matches the device it was designed for, and CoAP over UDP is what finally makes remote provisioning workable on hardware that has to survive years on a battery with no one watching it. Learn more about how eIM and the IPA work together once a device is on this stack.

This article was curated by Jan Lattunen, CCO Simplex Wireless

About the Author: Jan Lattunen manages Sales and Marketing for Simplex Wireless. Jan has 20 years’ experience in working with SIM card technology and was involved in launching the eSIM in North America with major carriers and OEMs. His expertise in telecommunications is around SIM cards. On a personal note, Jan is a family man and avid cyclist with advocacy for safety in the roads. You can connect with Jan on https://linkedin.com/in/JanLattunen