SGP.32 IPA-e vs IPA-d: Where the Intelligence Lives
In SGP.32, the IPA (IoT Profile Assistant) is the device-side component that receives management instructions from the eIM and executes profile operations on the eUICC. What most guides do not explain clearly is that the IPA does not have to live in the same place on every device. SGP.32 defines two distinct implementations – and the choice between them has significant consequences for your hardware design, your power budget, and your long-term management flexibility.
What Is IPA-d (Device-Based)?
IPA-d means the IoT Profile Assistant runs as software on the device itself – typically in the main processor or the router operating system. The IPA-d communicates with the eUICC chip via the standard SIM card interface, and it communicates with the eIM server over whatever network connection the device maintains.
This is how Teltonika implements eSIM management on the RUT241 and RUTX series. The firmware running on the router contains the profile management logic. When RMS (Remote Management System) pushes a command to switch profiles, it is the device-side software – the functional equivalent of an IPA-d – that receives and executes it.
Strengths of IPA-d
- Easier to update – the IPA logic is in firmware, so improvements can be pushed as software updates without touching the SIM chip
- More processing power available – the device processor can handle more complex management logic than a SIM chip
- Better suited to routers, gateways and well-powered devices
- Compatible with higher-level management APIs and vendor dashboards
Weaknesses of IPA-d
- If the device processor is in deep sleep or powered down, the IPA cannot respond to eIM commands
- The IPA is tied to the device OS – if the OS is compromised, so is the profile management
- More complex to certify for GSMA compliance because the software boundary is less defined
What Is IPA-e (eUICC-Based)?
IPA-e means the IoT Profile Assistant lives directly on the eUICC chip itself. The eUICC – the secure element – contains not just the profile storage but also the management logic. The IPA-e communicates with the eIM server directly, using the cellular connection provided by whichever profile is currently active on the chip.
This architecture is more common in highly constrained IoT devices – sensors, smart meters, and low-power environmental monitors where the main processor may be in deep sleep for hours or days at a time. With IPA-e, a profile update can be initiated and executed by the eUICC independently, without waking the main processor.
Strengths of IPA-e
- The SIM chip can receive and process eIM commands even when the main processor is asleep – critical for battery-powered NB-IoT devices
- Higher security boundary – the IPA logic runs inside the secure element, isolated from the device OS
- Smaller attack surface – there is no software layer between the eIM instructions and the eUICC execution
- Better suited to miniaturised hardware where the main processor has limited capability
Weaknesses of IPA-e
- Limited processing resources on the SIM chip constrain the complexity of management operations
- Updating the IPA itself requires a firmware update to the eUICC, which is more complex than a device firmware push
- Fewer vendors currently supply IPA-e certified chips – the ecosystem is smaller and hardware costs are higher
The 2026 Battleground: Which Will Win?
This is not a case where one approach wins outright. The split is likely to follow device category:
| Device Category | Recommended IPA | Reason |
|---|---|---|
| Industrial routers and gateways | IPA-d | Always-on, well-powered, benefits from firmware updates |
| Smart meters | IPA-e | Deep sleep cycles, must receive commands without waking processor |
| Asset trackers | IPA-d or IPA-e | Depends on battery profile and wake frequency |
| Environmental sensors | IPA-e | Extreme power constraints, long sleep periods |
| 5G RedCap devices | IPA-d | Sufficient processing power, faster update cycles |
| NB-IoT endpoints | IPA-e | Constrained networks and ultra-low power budgets |
What to ask your hardware vendor: Is the IPA device-based or eUICC-based? Can the device receive and process a profile update command while the main processor is in deep sleep? If the answer to the second question is no, you have an IPA-d implementation.
How to Specify This in a Hardware Procurement
When specifying eSIM-capable hardware for a deployment, add these questions to your technical checklist:
- Confirm IPA type: IPA-d (device processor) or IPA-e (eUICC-resident)
- For IPA-d: ask for the firmware update mechanism for the IPA software
- For IPA-e: ask for the eUICC specification and GSMA certification status
- For either: confirm CoAP over UDP support for constrained network environments
- For either: confirm asynchronous operation capability – can the eIM queue commands for devices that are currently offline?
For more on the SGP.32 architecture that defines these components, see the Architecture Guide. For hardware currently implementing these approaches, see the eSIM Hardware Guide.