Your IoT Network Data Exists. Getting an Answer From It Shouldn’t Take This Long.
June 12, 2026
IPAe vs IPAd: Why the SIM-Side Approach Matters for Retrofits
SGP.32 gives you two paths for connecting devices to an eIM. One requires no changes to your deployed hardware. The other does. Here’s the practical difference.
When companies first hear about SGP.32, the question that comes up fastest isn’t “what can it do?” It’s “what do we have to change?” For most SMEs with hundreds or thousands of devices already in the field, that’s the right question.
The answer hinges on a specific design choice inside the SGP.32 specification: whether the IoT Profile Assistant (IPA) — the component that handles communication between the device and the eIM server — lives on the SIM card or on the device itself.
The two IPA approaches: where they live and what they require
SGP.32 defines two variants of the IoT Profile Assistant:
IPAe (IPA on the eUICC) is embedded directly in the SIM card. The logic for receiving, executing, and confirming profile management commands runs on the eUICC — the chip inside the SIM. The device it’s installed in doesn’t need to know about any of this. It just needs to support Bearer Independent Protocol (BIP) and SIM Toolkit (STK) commands, which the vast majority of modern cellular modems already do.
IPAd (IPA on the Device) is a software component that runs on the device’s operating system or application layer. It handles the same profile management communication — but this time, it’s the device doing it, not the SIM. That means the device needs to have IPAd integrated: the software must be present, updated, and correctly configured before the device can participate in SGP.32 profile management at all.
The distinction matters immediately once you have hardware in the field. IPAe is a SIM-side capability — you carry it with you when you swap the card. IPAd is a device-side capability — it’s either there or it isn’t, and adding it after deployment typically means a firmware update or an OS-level change.
How this differs from previous specs
The consumer eSIM standard, SGP.22, relied on the LPA — Local Profile Assistant — which ran on the device OS and required user interaction to trigger profile downloads. It worked for smartphones because users are present and the OS is actively managed. Neither of those conditions applies to most IoT fleets.
SGP.32 replaced the LPA with the IPA specifically to remove the device OS dependency — but it hedged: device-firmware integration (IPAd) is still available for situations where the engineer wants device-side control, while eUICC-embedded integration (IPAe) is available for situations where the device shouldn’t need to change.
The consumer eSIM transition took years partly because it required OEMs to integrate LPA support at the OS level. SGP.32’s IPAe path exists precisely to avoid repeating that problem for IoT. A SIM card that carries its own IPA client makes any compatible device SGP.32-capable without waiting for module makers, OEMs, or OS vendors to ship an update.
The earlier M2M standard, SGP.02, kept profile management tightly coupled to the MNO’s SM-SR server — enterprises had no direct control. SGP.32 breaks that coupling regardless of which IPA variant you use. But only IPAe does it without touching the device.
What this means in practice for deployed fleets
If your devices are already in the field on physical SIMs or legacy eSIM, IPAe is almost always the practical path. The device doesn’t care that the SIM has changed — it still sees a cellular modem presenting normal connectivity. The only configuration change is on the modem side: BIP and STK need to be active.
Most modern modems from the major manufacturers — Quectel, Telit, Sierra Wireless, Fibocom, Cinterion — have BIP support built in but disabled by default. We’ve documented the exact AT commands for each in our guide to enabling BIP/STK on your modem. Once that’s done, the IPAe-enabled SIM handles everything else: it opens the channel, contacts the eIM, and processes profile commands autonomously, without any host-side coordination.
IPAd deployments are different. Adding IPAd to an existing device means writing or integrating new software, testing it against the device OS, pushing a firmware update, and validating across the whole fleet. For devices that are actively managed, have capable hardware, and sit on a maintained development roadmap — this can make sense, especially when deep device-side control over profile operations adds value. But for a fixed IoT installation that’s been running in a remote enclosure for two years with no established firmware update path, IPAd isn’t a retrofit option.
Where it goes wrong
The most common failure mode we’ve seen from our fieldwork with IPAe deployments is treating BIP enablement as a formality. It isn’t. Each modem manufacturer uses a slightly different command set, and some require specifically disabling manual STK triggering for autonomous BIP operation to work. Enabling BIP incorrectly produces no visible error — the modem appears functional, but the IPAe client can’t open its channel to the eIM, and profile operations fail silently.
The second failure mode is assuming that any eUICC-based SIM automatically includes IPAe. It doesn’t. A SIM can be eUICC-compliant under SGP.22 without carrying an IPAe client for SGP.32. If you’re sourcing SIM cards for an SGP.32 deployment, confirm explicitly that IPAe is present and ask the vendor which eIM configurations they support.
A third failure, specific to IPAd, is version drift: the device OS gets updated independently of the IPAd component, and an API change breaks the integration. This doesn’t affect IPAe deployments — the SIM is isolated from OS changes — but it’s a real maintenance burden for large IPAd fleets where firmware cycles aren’t tightly controlled.
The choice between IPAe and IPAd isn’t purely technical — it’s about which side of the stack owns the profile management capability, and what it costs to bring the other side up. For most SMEs with devices already deployed, IPAe is the answer that doesn’t require touching the hardware.
If you’re evaluating SGP.32 eSIM management for an existing fleet and want to talk through your specific device landscape, our engineering team in Atlanta is the right starting point. Explore the xoSIM to see how Simplex delivers IPAe-enabled SGP.32 compliance in a single SIM card.
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