This page covers the technical architecture of SGP.32 – the eIM, IPA, eUICC, and SM-DP+ components and how they interact. If you are new to the standard, start with what SGP.32 is first. For definitions of every term used here, see the SGP.32 glossary.
The SGP.32 Architecture
The SGP.32 architecture is built around a simple principle: move profile management control from the device to the server. This single shift – from pull to push, from user-initiated to server-initiated – is what makes IoT eSIM management practical at scale.
Four components form the core of SGP.32. Two are new to IoT eSIM: the eIM and the IPA. One is the established secure element hardware: the eUICC. One is deliberately reused from SGP.22: the SM-DP+. All four components are certifiable against SGP.32 v1.2, the current stable version of the specification.
The eIM (eSIM IoT Manager)
The eIM is the server-side brain of the SGP.32 system. It manages the complete lifecycle of eSIM profiles across device fleets – deciding which profile goes to which device, when, and under what conditions.
The eIM communicates with IoT devices via the ESipa interface. This interface supports both HTTPS (for well-connected devices) and CoAP over UDP with DTLS (for constrained NB-IoT and LTE-M devices). This dual-transport capability is what makes SGP.32 viable across the full range of IoT hardware, from LTE routers to NB-IoT sensors with kilobyte monthly data budgets.
What the eIM replaces
In SGP.02, the SM-SR (Subscription Manager Secure Routing) served a broadly similar function but created tight coupling between the operator and infrastructure provider. Multi-operator flexibility was difficult and expensive, and SM-SR configuration had to be locked in at eUICC manufacture. The eIM removes these constraints. It can be associated with an eUICC at any point in the device lifecycle, and multiple eIMs can be associated with a single device simultaneously – giving enterprises genuine control over their connectivity without operator lock-in. See how SGP.32 compares with SGP.02 and SGP.22 for a full breakdown, and eIM portability for how eIM switching works in practice.
The IPA (IoT Profile Assistant)
The IPA runs on the IoT device itself. It replaces the LPA (Local Profile Assistant) from SGP.22. The LPA was designed with a user in mind – QR code scanning, activation code entry, profile selection. The IPA has none of these user-facing functions. It exists purely to receive remote instructions from the eIM and execute them on the eUICC.
The IPA comes in two variants with different implementation tradeoffs. IPA-d (device) runs on the host processor, giving the device firmware team direct control but adding to the software stack they must maintain. IPA-e (eUICC) runs inside the secure element itself, offloading the SGP.32 software stack from the device firmware but requiring an eUICC that supports the embedded IPA implementation. See the full IPA-e vs IPA-d guide for the tradeoffs and which variant suits which deployment type.
The eUICC (Embedded Universal Integrated Circuit Card)
The eUICC is the physical secure element – the chip soldered onto the device PCB that stores SIM profiles. Under SGP.22, the eUICC was managed by the user via the LPA. Under SGP.32, it is managed by the eIM via the IPA. The eUICC is the only component physically present in every IoT device in the fleet.
Certified SGP.32-compatible eUICC chips from Kigen, Thales, and others are commercially available. For a guide to which hardware is certified and what to look for when specifying modules, see the eSIM hardware guide.
The SM-DP+ (Reused from SGP.22)
The SM-DP+ prepares, stores, and delivers eSIM profiles. SGP.32 deliberately reuses the SM-DP+ infrastructure from SGP.22, which is already widely deployed by operators globally. Operators who already support SGP.22 can begin serving SGP.32 devices by adding eIM capability to their existing stack, without rebuilding their profile delivery infrastructure from scratch. This was a deliberate GSMA design decision to accelerate operator adoption.
How the Components Interact
A typical SGP.32 profile download sequence works as follows:
- The enterprise instructs the eIM to provision a specific operator profile to a target device
- The eIM contacts the SM-DP+ to prepare the encrypted profile package
- The eIM sends a trigger to the device-side IPA via HTTPS or CoAP/DTLS
- The IPA initiates a secure connection to the SM-DP+ and downloads the profile
- The IPA installs the profile in the eUICC and reports success to the eIM
- The eIM records the completed operation and updates the device status in the fleet registry
For devices in deep sleep, steps 3 to 6 happen asynchronously – the eIM queues the instruction and the device processes it when connectivity is next available. This is one of the most important practical differences between SGP.32 and earlier standards: the system does not require a device to be awake and responsive at the moment an operation is initiated.
Transport detail: SGP.32 supports HTTPS for well-connected devices, and CoAP over UDP with DTLS for constrained environments. CoAP is defined in RFC 7252 and is designed specifically for machine-to-machine communication over low-bandwidth, lossy networks – exactly the conditions NB-IoT and LTE-M devices operate in. The choice of transport is determined by the device capability and is configured at the eIM level.
Security in SGP.32
All profile lifecycle operations in SGP.32 are cryptographically authenticated and integrity-protected. Profiles cannot be downloaded, modified, or switched without proper authorisation from a verified eIM. The chain of trust runs from the GSMA Certificate Issuer through the eUICC Manufacturer (EUM) to the eUICC itself, and every Profile State Management Operation (PSMO) is signed and verified before execution.
This cryptographic authentication for individual profile operations was not present in SGP.02 in the same form. It provides enterprises with an auditable, verifiable record of every profile change across their fleet – increasingly important given regulatory requirements such as the EU Cyber Resilience Act, which mandates ongoing security accountability for IoT devices. The full SGP.32 security model is covered in the eSIM security guide.
Current specification
This architecture is defined in SGP.32 v1.2, the current stable and certifiable version of the GSMA specification. Certified implementations of all four components are commercially available. For the full picture of which vendors have certified and where commercial deployments stand, see SGP.32 v1.2: The Current Specification Explained.