The first fork: IPAd or IPAe
Before looking at any messages, there's an architectural decision that defines the rest: where the IPA (IoT Profile Assistant) lives. SGP.32 allows two physical variants, and the device picks one at design time.
IPAd — IPA on the device
The IPA runs as device software: either inside the modem firmware, or as an application on the host processor. It talks to the eUICC over the standard APDU interface, the same way any other application would use the SIM.
What you get: control. The OEM decides when the IPA tries to refresh the profile, what it does on network failure, what events it surfaces to the cloud. If your product has a serious OTA pipeline, this variant is real leverage — you can evolve the IPA logic with every firmware release without touching the eUICC.
What it costs: attack surface and code. The IPA holds cryptographic secrets; any compromise of the modem firmware is a potential IPA compromise. And it eats code budget — between 50 and 200 KB depending on the implementation.
IPAe — IPA inside the eUICC
The IPA runs as a Java Card applet inside the eUICC itself. The device sees it as another SIM function and talks to it over APDU; all the download, activation and rollback logic happens inside the chip.
What you get: near-turnkey integration. The eUICC vendor ships the chip with a GSMA-certified, validated IPAe. You don't have to add any logic to the device firmware beyond exposing an IP connection to the applet. For devices on tight code budgets, this is the reasonable option.
What it costs: flexibility. Any custom behavior — special retries, bespoke telemetry instrumentation, integration with your own event bus — is constrained by what the chip vendor's applet allows.
The full cast: six actors
Three actors external to the device, plus five components inside the eUICC. Worth knowing what each one does before looking at the protocol.
What's outside
- IPA (IoT Profile Assistant): the component you already know. On the device (IPAd) or inside the eUICC (IPAe). It's the client in the conversation with the eIM.
- eIM (eSIM IoT remote Manager): the server that commands the IPA. Three responsibilities: configure the IPA (who to talk to, with which certificates), deliver instruction packages, and record the state the IPA reports back.
- SM-DP+ (Subscription Manager — Data Preparation): the carrier's server. Prepares, encrypts and signs the profile the eUICC will receive. Same SM-DP+ as in SGP.22, and GSMA certification is mandatory.
- SM-DS (Subscription Manager — Discovery Service, optional): a discovery server. When the IPA doesn't know which SM-DP+ to ask for a profile, it queries the SM-DS, which returns the address. Useful for devices without a pre-configured bootstrap.
What's inside the eUICC
- ECASD (eUICC Controlling Authority Security Domain): the chip's cryptographic root. Holds the eUICC's identity certificate, signed by the manufacturer (Kigen, IDEMIA, Thales, etc.) under the GSMA hierarchy. Everything else derives from here.
- ISD-R (Issuer Security Domain — Root): the management domain. Knows which profiles are loaded, which is active, and executes the IPA's orders ("enable this, disable that").
- ISD-P (Issuer Security Domain — Profile): one per loaded profile. Each ISD-P encapsulates a full carrier profile (IMSI, Ki, network config) with its own encryption keys.
- Telecom Framework: the facade the modem sees. Exposes the standard SIM interface (PIN, IMSI, A3/A5 authentication) to the modem firmware, which doesn't need to know there's an eUICC behind it.
- Profile Package Interpreter: parses the encrypted package the SM-DP+ delivers and unpacks it into a new ISD-P. It's the piece that decodes the GSMA-standardized TLV profile format.
ESipa: the new conversation
The IPA ↔ eIM interface is called ESipa. It's SGP.32's own protocol contribution — doesn't exist in SGP.22 — and it's designed for the peculiarities of IoT: unreliable networks, devices behind NAT, thin bandwidth, high latency.
Two bindings: CoAP and HTTPS
ESipa defines two transports for the same logical messages:
- CoAP over UDP with DTLS: the IoT-native binding. Few-byte headers, designed for networks with small MTU and to conserve battery. Default on LPWA (NB-IoT, LTE-M).
- HTTPS over TCP with TLS: the IT-native binding. Easier to debug, traverses corporate proxies without tricks, fits standard monitoring infrastructure. Default on 4G/5G and on devices with generous bandwidth.
Both bindings carry the same message types at the logical layer — the IPA and the eIM don't know (and don't care) which transport the other side is using. The modem picks based on network capabilities.
Mutual authentication
TLS or DTLS, with certificates on both sides. The IPA proves it's a legitimate IPA instance by presenting the eUICC's identity certificate (signed by the chip vendor under the GSMA chain). The eIM proves it's the eIM the device was configured to talk to, presenting its own certificate signed under the eIM operator's chain.
Any attempt by an actor without the right certificate dies in the handshake. That's the heart of the trust model: no shared secrets, no manually-revocable tokens; everything is standard X.509 PKI.
What's on the wire: three message types
ESipa defines three primary message types between eIM and IPA. You'll recognize them in any packet trace or log:
EuiccPackageRequest (eIM → IPA)
The message that carries instructions for the eUICC. The payload can be one of three things:
- eUICC Configuration Order (eCO): changes the eUICC's configuration state without touching individual profiles — update metadata, register the authorized eIM, adjust global policies.
- Profile State Management Order (PSMO): operates on a specific profile. "Enable profile 3", "disable profile 1", "delete profile 5". The most common fleet-management verb.
- Profile Download Trigger: kicks off a profile download from a specific SM-DP+. Carries the SM-DP+ address, the activation code, and the parameters the IPA needs to start the session.
IpaEuiccDataRequest (eIM → IPA)
Asks "what do you have right now?" The IPA replies with an IpaEuiccDataResponse that enumerates the loaded profiles, which one is active, the available space, and the eUICC's capabilities. It's what the eIM uses to sync its model of the fleet's state.
EimAcknowledgements (IPA → eIM)
Asynchronous receipts. When the IPA finishes executing a EuiccPackageRequest, it replies with an EimAcknowledgement saying "OK, executed", or "failed, here's the error code". The eIM correlates it with the original package and updates state.
Two routes a profile takes home
When the eIM issues a Profile Download Trigger, the IPA has to go fetch the profile from the SM-DP+. SGP.32 defines two paths for that transfer.
Direct download
The IPA opens a TLS connection directly with the SM-DP+ the eIM pointed at, mutually authenticates (the Common Mutual Authentication defined by GSMA), requests the profile, receives it end-to-end encrypted for the eUICC, and installs it. The eIM doesn't participate beyond the trigger.
Used when the IPA has normal IP connectivity and the SM-DP+ is reachable from the network the device is on.
Indirect download
When the IPA can't reach the SM-DP+ directly — say, it's behind a private APN that only routes to corporate servers, or on an operator network that doesn't forward to arbitrary public hosts — the eIM acts as a proxy. The eIM downloads the profile from the SM-DP+ on its side and forwards it to the IPA through the ESipa channel it already had open.
Important: the profile is still end-to-end encrypted for the eUICC. The eIM transports the encrypted blob but doesn't have the keys to decrypt it. That's what makes a third-party-operated eIM safe: it sees when profiles move, but not what's inside them.
When the migration fails: the rollback procedure
This is the feature that turns SGP.32 from a useful spec into something you'd actually trust with a 50,000-device fleet. In SGP.02, a failed migration meant the device went silent and someone had to drive to it. In SGP.32, the IPA can roll back on its own.
The mechanics: before activating a new profile, the IPA records which profile was previously active and the exact moment it was disabled. If after a configurable window (typically 24 to 72 hours) the eUICC hasn't received a "commit" message from the eIM over the new profile's network, the IPA assumes the migration didn't work and re-enables the previous profile.
For this to work properly, the eUICC needs some sensible notion of time. If the device has GPS or NTP, it resolves it that way; if not, the eUICC clock has to be populated from the modem at every boot. The spec leaves this to the integrator, but it's the single most common practical trap in SGP.32 pilots.
Who vouches for whom: the certificate chain
Four cryptographic roots, organized in a hierarchy that GSMA defines in SGP.21:
- GSMA Root CA: the global root. Signs each eUICC manufacturer's CA and each SM-DP+ operator's CA.
- EUM CA (eUICC Manufacturer): one per chip vendor. Signs the identity certificate of each eUICC that ships from the factory.
- SM-DP+ CA: one per SM-DP+ operator. Signs the certificate of each operational SM-DP+ instance.
- eIM CA: traditionally the eIM operator's own CA. GSMA is working on a common list to ease interoperability, but as of today it's the least standardized piece.
Revocation is handled with standard CRL/OCSP. If an eUICC is compromised (chip extraction, key leak), its certificate is revoked; from then on, neither the eIM nor the SM-DP+ accept handshakes from that identity.
What most pilots get wrong
- Network restrictions. If your private APN or static-IP setup doesn't route to arbitrary hosts, you'll need indirect download. Confirm this with the APN operator before you start — it usually requires whitelisting the SM-DP+'s IP range.
- Clock sync. Rollback depends on knowing what time it is. Devices without GPS or reliable NTP are the ones that suffer. Solve it with NITZ from the mobile network or with a timestamp field in every ESipa message.
- eUICC memory. Each profile takes between 30 and 100 KB inside the eUICC. Typical industrial eUICCs hold 4 to 8 simultaneous profiles; that caps your fallback and multi-market strategy.
- IPA update path. If you go with IPAd, the IPA code ships with your firmware. Plan the IPA's own update path with the same seriousness as the application's.
- Roaming testing. The SM-DP+ may be on another continent. Verify latency and MTU from the country where the device will actually be deployed — pilots sometimes work in the office but fail in the field due to timeouts.
Frequently asked questions
What's the difference between IPAd and IPAe in practice?
IPAd (IPA on the device) lives in the modem or application firmware, so the OEM controls it and can add custom retry logic or instrumentation — at the cost of more device-side code and a larger attack surface. IPAe (IPA in the eUICC) runs as a Java Card applet inside the eUICC itself: the chip vendor maintains it, there's less device-side code, and the integration is closer to plug-and-play, at the cost of less customization. New device with a serious OTA pipeline → IPAd gives you more leverage. Integration cost is the constraint → IPAe.
Do I need to run my own eIM?
No. The eIM can be operated by the OEM in-house, by an integrator, or contracted as a service from an MVNO that offers it. The important property is that you're no longer locked to the eUICC vendor — not that you have to build the platform. Part 3 covers when each option makes sense.
What happens if a profile download is interrupted halfway through?
The IPA never activates a partial profile. If the transfer is cut, the device stays on the previous profile intact, and the eIM sees that state on the next IpaEuiccDataResponse. The download retries when connectivity is back. This is very different from SGP.02, where a half-completed migration could leave the device in a mixed state.
Can the eIM see the plaintext profile?
No. The profile is end-to-end encrypted between the SM-DP+ and the specific eUICC that's going to receive it. In the indirect download flow the eIM forwards the encrypted blob, but it doesn't have the keys to decrypt it. That's what makes it safe for the eIM to be operated by a third party.
Does SGP.32 require LPWA (NB-IoT, LTE-M) or does it work over standard 4G/5G too?
It works over any IP bearer. ESipa runs over either CoAP/DTLS (typical of LPWA, byte-optimized) or standard HTTPS/TLS (typical of 4G/5G and of deployments behind a corporate proxy). The modem and device OS choose the binding; the rest of the protocol is identical.
What's coming in Part 3
Part 3 is the deployment guide. What pieces to buy and from whom, the tradeoff between running your own eIM and contracting it, multi-market with a single hardware SKU, fleet management at scale without losing track, the actual state of interoperability between vendors in 2026, and the long RFP checklist.
If you came here looking for the executive summary, the short 5-minute briefing is still the entry point. If you want to recap why SGP.32 exists before making technical decisions, go back to part 1.