IPAd vs IPAe: choosing where the SGP.32 IoT Profile Assistant runs

IPAd and IPAe are the two places where the SGP.32 IoT Profile Assistant (IPA) can run. An IPAd is software in the IoT device itself, either in the host application or in the cellular module’s firmware. An IPAe is built into the eUICC by its manufacturer. One of the two must be active in every SGP.32 device. The choice shapes which modules you can use, how much memory and code the device needs, how you patch the agent, and how easy problems are to debug.

This guide explains what the IPA does, how each variant works, the trade-offs between them, how to tell which one a device uses, and what it means for testing.

What the IPA does

The IPA is the device-side agent in the SGP.32 architecture, the IoT counterpart of the consumer LPA. It sits between the network-side servers and the eUICC and:

• connects to the eIM over the ESipa interface, either polling for work or accepting pushed packages;
• parses profile download triggers such as an activation code;
• runs the profile download with the SM-DP+, directly or through the eIM as a proxy;
• hands signed eUICC Packages (enable, disable, delete and similar commands) to the eUICC and returns the signed results;
• forwards notifications to the eIM and SM-DP+;
• can trigger rollback to the previous profile, or the fallback mechanism, when connectivity is lost.

Whichever IPA is used, the eUICC side is the same: a set of IPA Services in the eUICC’s root security domain (ISD-R) that provide the EID, profile information, profile installation and command execution. The IPA cannot alter eIM commands, because they are signed for the eUICC, and it cannot read profiles, because they are encrypted for the eUICC.

IPAd: the IPA in the device

IPAd is the IPA implemented in the IoT device. It can live in two places:

• The host application on the device’s microcontroller or application processor, often as a library integrated with the device’s own management agent.
• The cellular module’s firmware, so the host only needs to use a few commands. Module makers have started shipping this; for example, SIMCom announced in March 2025 that SGP.32 firmware was being added to its LTE Cat 1 bis modules.

How an IPAd talks to the eUICC

According to SGP.32 v1.2 (section 3.8), the device first tells the eUICC it supports an IPAd through the TERMINAL CAPABILITY command. The eUICC only enables its ES10 functions if that support is declared. Before sending any command, the IPAd opens a logical channel and selects the ISD-R using the standard GlobalPlatform MANAGE CHANNEL and SELECT commands. The device must ensure that no other application can select the ISD-R.

When the IPAd runs on a host processor rather than in the modem, those APDUs usually pass through the modem’s AT interface, typically with the logical-channel commands defined in 3GPP TS 27.007 (such as +CCHO and +CGLA). Whether a given module exposes them, and whether it lets the host reach the ISD-R, is a module-specific detail worth confirming early.

How an IPAd talks to the network

An IPAd uses the device’s own IP stack: HTTPS over TCP, CoAP over UDP with DTLS, or a protocol the device already runs, such as LwM2M or MQTT. That flexibility is its main advantage. The IPAd can read the active profile’s connectivity parameters, such as the APN, from the eUICC if it needs them.

IPAe: the IPA in the eUICC

IPAe is the IPA implemented inside the eUICC. SGP.32 states that implementing an IPAe is optional, and that its technical implementation is specific to the eUICC manufacturer.

An IPAe cannot reach the network on its own. It relies on the modem through SIM Toolkit (Card Application Toolkit) mechanisms, chiefly the Bearer Independent Protocol. Annex A.2 of SGP.32 lists what the device must support for an IPAe, including:

• OPEN CHANNEL for a packet data bearer, plus SEND DATA, RECEIVE DATA, CLOSE CHANNEL and GET CHANNEL STATUS;
• data-available and channel-status events;
• TIMER MANAGEMENT and timer expiration, so the IPAe can schedule polling;
• PROVIDE LOCAL INFORMATION (the device IMEI);
• REFRESH, SET UP EVENT LIST, TERMINAL PROFILE and SMS-PP download.

How an IPAe is activated

When the device selects the ISD-R, the eUICC reports whether it supports an IPAe. If the device supports the required toolkit features, it may send an IPAe activation request. If the device declares that it has no IPAd, the eUICC activates its IPAe automatically, if it has one. If the device declares an IPAd and does not request activation, the IPAe stays off. The active IPA is also recorded in the eUICC’s information (the ipaMode field of eUICCInfo2), which an eIM can request remotely.

IPAd vs IPAe at a glance

	IPAd (in the device)	IPAe (in the eUICC)
Implemented by	Device maker, IoT platform or module vendor	eUICC manufacturer
Status in SGP.32	Device option	Optional for eUICCs; implementation is vendor-specific
Path to the eUICC	ES10a/ES10b commands over a logical channel to the ISD-R	Internal to the eUICC
Path to the network	Device IP stack: HTTPS, CoAP/DTLS, LwM2M, MQTT	SIM Toolkit (BIP channels) through the modem
Device requirements	Firmware or host code, a TLS/DTLS stack, ISD-R access through the modem	Modem support for the listed toolkit commands
Device resources	Uses device flash, RAM and CPU	Very little on the device
Transport flexibility	High; can reuse existing device protocols	Limited to what the eUICC vendor built
Update path	Device or module firmware update	Tied to the eUICC; in-field changes depend on the vendor and are far more restricted
Debugging	Logs available on the device	Mostly opaque; requires APDU or toolkit traces
Lock-in	Device or module firmware	eUICC vendor

The trade-offs in practice

Device resources

An IPAd needs code space, RAM and a secure transport stack. On a Linux gateway that is trivial. On a coin-cell sensor with a small microcontroller it can be the deciding factor, and an IPAe, or an IPAd inside the module, saves the host from carrying it.

Module support

An IPAe only works if the modem’s SIM Toolkit implementation is complete and robust. BIP support varies between module families and firmware versions, and LPWA modules with aggressive power saving can interfere with toolkit timers and channels. An IPAd on the host needs the module to expose logical-channel access to the eUICC. An IPAd in the module removes both concerns but ties you to that module’s firmware roadmap.

Security

An IPAe runs inside tamper-resistant hardware. An IPAd inherits the device’s security, which SGP.32 treats as the device maker’s responsibility. In both cases the critical assets are protected end to end: eIM commands are signed and replay-protected, results are signed by the eUICC, and profiles are encrypted for the eUICC. A compromised IPAd can block or delay operations, but it cannot forge them.

Update path

Bugs in an IPAd can be fixed with a firmware update. Fixing an IPAe means relying on the eUICC vendor, and code inside a deployed secure element is much harder to change. Because SGP.32 is still young, with versions 1.1, 1.2 and 1.3 published between 2024 and 2026, the ability to patch the agent matters.

Interoperability with the eIM

The IPA and eIM must agree on the delivery mode, the secure connection and the download mode. With an IPAe, the eIM may also need to provide TLS trust data when it associates with the eUICC, which SGP.32 recommends when the IPAe retrieves packages over HTTPS or CoAP/DTLS. An eIM that has only been tested with IPAd devices may not do this.

How to tell which IPA a device uses

1. Read the documentation. Module datasheets and AT command manuals state whether the firmware includes SGP.32 IPA support. eUICC product sheets state whether an IPAe is available.
2. Ask the eIM. The eIM can request eUICCInfo2 from the device; its ipaMode field reports whether the IPAd or the IPAe is active. It can also request the IPA Capabilities, which list supported download modes and transports.
3. Look at an APDU trace. The device’s TERMINAL CAPABILITY command shows whether it declares IPAd support, and the ISD-R SELECT response shows whether the eUICC supports an IPAe.
4. Watch the traffic. An IPAd usually appears as an application on the device or module making its own connections. An IPAe appears as SIM Toolkit OPEN CHANNEL activity initiated by the card.

What this means for testing

The IPA is where SGP.32 meets real hardware, so it is where many field failures start. Tests should be run on the exact combination you will ship: the same module and firmware, the same eUICC, the same IPA variant and the same eIM.

• IPAd: test after every device or module firmware update, check that logical-channel access to the ISD-R works on each module variant, and confirm the polling schedule survives power-saving modes.
• IPAe: confirm the modem’s toolkit support on every module and firmware variant, check that BIP channels open on each operator’s APN, and verify that toolkit timers still fire when the device uses PSM or eDRX.
• Both: after every profile switch, verify that the device re-attaches, that the IPA can still reach the eIM on the new profile, and that rollback or fallback recovers the device when it cannot.

Lab conformance against SGP.33-2, the GSMA IPA test specification, proves the agent follows the standard. Field validation proves it works on live networks. The step-by-step plan is in our guide on how to test SGP.32 devices.

SimCheck.ai runs those field checks on real cellular modems with real eSIM profiles, installing SGP.32 profiles through a cloud eIM and then verifying attach, data and MQTT connectivity on LTE-M, NB-IoT or LTE. See SGP.32 IoT eSIM testing for how teams validate device, eUICC and eIM combinations before rollout.