IPA.d vs IPA.e: What IoT architects need to know before choosing an eSIM strategy

The SGP.32 specification from the GSMA defines the architecture for remote SIM provisioning (RSP) in Internet of Things (IoT) deployments using an embedded universal integrated circuit card (eUICC), commonly referred to as an embedded SIM (eSIM). RSP extends provisioning beyond the factory gate, enabling SIMs to receive operator profiles securely over-the-air throughout the entire operational lifetime of the device. The RSP model replaces the need to embed SIM technology using SIM chips that were pre-loaded with MNO-specific profiles during factory provisioning or to go through on-site configuration at the point of deployment using the highly secure but cumbersome traditional SIM manufacturing process.

IoT architects will have encountered the eSIM ecosystem, seeing eSIMs as a way to enable in-factory profile provisioning (IFPP). IFPP allows the devices leave the factory with a working connectivity profile installed without using physical SIM cards. However, until now, eSIM usage has been enabled using a consumer specification (SGP.22) or an M2M specification (SGP.02). Neither specification efficiently addresses the scale and requirements of today’s IoT device fleets.

SGP.32 extends the previous model beyond manufacturing and enables connectivity profiles to be managed securely throughout the operational lifetime of a device fleet. Within that lifecycle framework, the eUICC stores connectivity profiles securely within the device, profiles are prepared and packaged by the subscription manager data preparation plus (SM-DP+) which is responsible for secure profile hosting and delivery. The eSIM IoT manager (eIM) manages provisioning across device fleets and handles orchestration for the device lifecycle and these operations are executed by the IoT profile assistant (IPA).

Choice by design

SGP.32 introduces an architectural choice of where the IPA should operate. The specification allows the assistant to run in two modes – IPA.d or IPA.e. An IPA.d operates in the device host or module environment while an IPA.e is inside the secure element of the eSIM or eUICC. Either approach is fully compliant with the GSMA ecosystem and both interact with the same provisioning infrastructure and the eIM. The core difference between IPA.d and IPA.e is where connectivity lifecycle decisions are executed within the system architecture.

The architectural distinction between the two models is straightforward. IPA.d places the device-level connectivity control logic in the device host, while IPA.e places that logic inside the eSIM secure element. At the fleet level, lifecycle orchestration remains coordinated by the eIM, which manages provisioning and profile operations across devices.

Device behavior and system capabilities

The difference in location determines how connectivity policies interact with device behavior and how lifecycle operations are triggered within the system. The location of device-level lifecycle logic influences how connectivity policies interact with device behavior.

When lifecycle logic resides in the device host (IPA.d), connectivity policies can respond directly to device telemetry, power conditions or the application state. When lifecycle logic resides in the eSIM secure element (IPA.e), provisioning workflows are handled within the SIM environment. This reduces the amount of lifecycle logic that must be implemented in device firmware but also limits direct interaction with device applications.

As IoT devices become more capable, connectivity policies increasingly interact with device state and application behavior. The location of lifecycle logic therefore affects how closely connectivity management can align with device functionality.

Operational trade-offs

Architectural choices influence how devices are manufactured, provisioned and managed at scale, as set out in the table below:

In environments where lifecycle logic resides in the device host, firmware participates directly in provisioning workflows and connectivity decisions. When lifecycle logic resides in the eSIM, provisioning operations occur within the SIM environment while the device host acts primarily as an interface. The broader structure of the IoT ecosystem often determines which model will be easier to operate.

Many architectural comparisons assume that device vendors, connectivity platforms, and provisioning infrastructure operate independently, so, in fragmented environments, embedding lifecycle orchestration within the eSIM can simplify device integration. However, in ecosystems where these are closely integrated, device-centric orchestration can simplify lifecycle operations and provide greater control over connectivity behavior. In these environments, the architectural question shifts from minimizing complexity to determining where the connectivity control plane should reside.

Security and operator policy considerations

Security boundaries differ depending on where device-level lifecycle logic resides.

When lifecycle logic resides in the eSIM, provisioning operations are isolated within the secure element environment. This separation can simplify security certification and protect sensitive provisioning functions.

In certain deployments, a more tightly coupled IPA.e, eIM and operator‑policies can restrict profile switching or limit device‑initiated lifecycle operations. Although compliant with GSMA specifications, these mechanisms can introduce a degree of provider lock‑in over the device’s operational lifetime.

When lifecycle logic resides in the device host, lifecycle orchestration becomes part of device firmware. This increases development responsibility but allows connectivity policies to interact more directly with device behavior.

Decision framework

Another factor that shapes architectural decisions is the increasing intelligence of IoT devices. As devices take on more responsibility, including edge analytics, local data processing and adaptive connectivity behavior, connectivity policies increasingly interact with application logic and the device state.

At the other extreme, devices can have very limited resources both in connectivity and processing power. IPA.d supports indirect profile download using constrained protocols such as CoAP, enabling profile delivery to highly resource‑constrained IoT devices that cannot perform full HTTPS‑based downloads.

Architects should therefore consider their operational priorities and decide between IPA variants accordingly, as illustrated in the table below. The most appropriate architecture depends on how devices are manufactured, deployed and managed throughout the lifecycle of the fleet.

Future-proofing considerations

IoT deployments frequently remain operational for many years, so architectural choices should consider how connectivity ecosystems will evolve. The GSMA roadmap already points toward SGP.42, which extends lifecycle orchestration capabilities for IoT environments. Security models are also evolving and the industry is preparing for post-quantum cryptography (PQC) to address cryptographic risks associated with future quantum computing capabilities.

Connectivity environments are becoming more heterogeneous as well. Non-terrestrial networks (NTN) and emerging 6G architectures will introduce hybrid connectivity models combining terrestrial and satellite networks. As connectivity ecosystems become more diverse, architectures capable of coordinating device behavior, network conditions and provisioning infrastructure will adapt more easily to changing situations during a device’s deployment.

SGP.32 provides a flexible framework for managing IoT connectivity throughout the lifecycle of connected devices. The choice between IPA.d and IPA.e determines where device-level connectivity logic resides – in the device host or within the secure element of the eSIM – while fleet lifecycle operations remain coordinated by the eIM.

Each approach reflects different operational priorities. Some deployments favor standardized SIM-centric orchestration, while others benefit from device-centric lifecycle control. Large IoT ecosystems often encounter both models. Understanding how each architecture aligns with device capabilities, operational workflows and ecosystem structure is therefore essential when designing resilient connectivity strategies.

If you are evaluating SGP.32 architectures for your deployment, consider starting with a technical discussion about how connectivity will operate across the lifecycle of your devices. Contact our team now.