Earlier standards had limitations: 

• SGP.02 (M2M)
  Heavy SM-SR/SM-DP architecture
  Strong coupling to a “first operator”
  Complex, often SMS-based control
  Switching providers rarely done in practice   

• SGP.22 (Consumer)
  Optimized for smartphones and wearables
  Relies on a Local Profile Assistant (LPA) and user interaction
  Not ideal for unattended devices without user interface 

SGP.32 addresses these gaps by providing:  

• Remote provisioning without SMS or user interaction
• Support for constrained, low-power devices
• Flexible architecture with lightweight agents (IPAe/IPAd)
• Scalable orchestration via an IoT Manager (eIM)
• Better regulatory compliance (e.g. local profiles per country)
• Multi-profile and multi-operator resilience 

SGP.32 introduces four key components: 

The eSIM IoT Remote Manager (eIM) is the central control system that: 

• Tracks device and profile states 
• Applies provisioning policies 
• Decides which operator profile to deliver 
• Orchestrates downloads, updates, and fallback 
• Monitors success/failure and compliance across fleets   

IPAe is a lightweight profile assistant implemented inside the eUICC: 

• Part of the SIM OS / firmware 
• Certified together with the eUICC under SGP.32 
• Very small footprint and tightly controlled security environment 
• Simplifies compliance for device makers (less to certify on the device side)  

Best suited for: 

• Constrained devices (sensors, meters) 
• Simple firmware architectures 
• Deployments where purely cellular provisioning is acceptable 

IPAe typically requires an active cellular data connection to communicate for profile management, although alternative routing may be implemented by OEMs in custom architectures. 

IPAd is a profile assistant running on the device’s CPU/OS, outside the eUICC:

• Implemented as software on the device (e.g. Linux, RTOS, application MCU)
• Offers richer integration with device applications, logs, and power management
• Can use non-cellular connectivity (e.g. Wi-Fi, Ethernet) to reach the eIM/SM-DP+
• More flexible but requires separate certification and maintenance

Best suited for:

• CPE, routers, gateways
• POS terminals
• Telemetry and telematics units with capable processors
• Devices that can use Wi-Fi or wired backhaul for provisioning

SGP.32 reuses the SM-DP+ component from the SGP.22 architecture, ensuring continuity and interoperability across the ecosystem. In SGP.32, the SM-DP+: 

• Stores operator profiles 
• Prepares encrypted profile packages bound to each eUICC   
• Delivers profiles when requested (either directly or via the eIM)   
• Reports download and installation results back to orchestration systems 

While SM-DP+ remains the core profile-delivery engine, the “enhanced architecture” of SGP.32 comes from the introduction of IPAe/IPAd and the eIM, which replace the legacy SM-SR and enable lightweight, IoT-optimized provisioning workflows. 

SGP.32 defines two provisioning “modes” and associated protocol options, optimized for different device capabilities.  

In Direct Download, the IPA (IPAe or IPAd): 

1. Establishes a TCP/IP connection 
2. Talks directly to SM-DP+ (and, if needed, queries the eIM) over secure IP 
3. Downloads and installs the profile 
4. Reports the result 

Characteristics:  

• Uses IP-based protocols over TCP (e.g. HTTPS/REST) 
• Well-suited for devices with persistent or stable connectivity 
• With IPAd, this direct download can also occur over Wi-Fi or other non-cellular links if the device can reach eIM/SM-DP+ securely 

When to use: 

• Gateways, CPE, routers 
• POS and industrial controllers with stable power and bandwidth 
• Test setups, POCs, controlled industrial environments 

In Indirect Download, the process is mediated by the eIM and uses IoT-friendly protocols:  

1. IPA (IPAe or IPAd) communicates with eIM using lightweight messaging 
2. eIM decides which profile to provision 
3. eIM coordinates with SM-DP+ to prepare the profile 
4. IPA receives instructions and executes the download/installation 
5. eIM collects the result and may trigger further actions (fallback, retries, etc.) 

Key protocol aspects: 

• Typically uses CoAP over DTLS, with optional MQTT for device-cloud messaging depending on implementation. 
• Designed for constrained, power-sensitive devices with intermittent or short wake windows 
• Works well on NB-IoT, LTE-M, and deployments where constant IP connectivity is not realistic  

When to use: 

• Smart meters 
• Battery-powered sensors 
• Trackers with aggressive power-saving strategies 
• Deployments with unpredictable coverage 

Direct Download + TCP/IP 

• Simpler stack
• Good for capable devices with steady connections (often IPAd) 

Indirect Download + CoAP/MQTT/DTLS 

• More resilient to network constraints 
• Better for huge fleets and ultra-low-power devices 
• Centralized policy and compliance control via eIM 

Across device types, the SGP.32 lifecycle follows the same high-level pattern: 

• Device is assembled with an SGP.32-capable eUICC 
• IPAe and/or IPAd is integrated 
• Optionally, a bootstrap profile is preloaded for first connectivity 

• Device powers on
• Modem tries to attach using bootstrap or existing profile 
• If no bootstrap, other connectivity (e.g. Wi-Fi for IPAd) can be used to reach eIM 

• IPAe/IPAd identifies the device (EID + credentials) 
• eIM checks device state, policy, and target profile 

Depending on chosen mode: 

• Direct: IPA connects via TCP/IP to SM-DP+ and downloads profile 
• Indirect: IPA exchanges messages with eIM over CoAP/MQTT; eIM coordinates with SM-DP+ and instructs IPA to install the profile 

Depending on chosen mode: 

• Profile is installed on the eUICC 
• Becomes operational profile 
• Bootstrap may be kept for fallback or disabled

• Device may receive updates 
• Additional local profiles (for regulatory reasons) 
• Fallback profiles (backup subscription) 
• Regional operator profiles as it moves 

Certain profile deletion and fallback behaviors are strictly governed by SGP.32 security rules to prevent unintended loss of connectivity. 

Device firmware must be able to: 

• Run IPAe (from eUICC) and/or IPAd (on the device) 
• Establish secure channels to eIM/SM-DP+ 
• Implement retry and back-off logic 
• Persist state across reboots 
• Handle power-loss mid-download safely 

• eUICC supporting SGP.32 
• Modem supporting selected RATs (2G–5G, LTE-M, NB-IoT) 
• Sufficient flash/RAM for:
  Profile storage
  Encryption buffers
  Agent code (especially for IPAd) 

• At least one initial connectivity path: 
  • Bootstrap cellular profile, or
  • Wi-Fi / Ethernet (for IPAd) 

• Ability to reach eIM and SM-DP+ via supported protocols (TCP/IP, MQTT, CoAP, DTLS) 

Device must be able to reach: 

• eIM (using TCP/IP, CoAP/DTLS, or MQTT depending on configuration)
• SM-DP+ (using HTTPS/TLS for direct download) 

• Typically have Linux or robust OS 
• Often connect via Ethernet or Wi-Fi as well as cellular 
• IPAd + Direct Download is common 
• Multi-operator profiles used for resilience and performance 

• Medium-power devices
• Often indoors, sometimes behind NAT/firewalls 
• Can use direct or indirect download 
• Fallback profiles (backup subscription) are critical for payment continuity 

• Extremely power-constrained
• Long sleep cycles 
• Often NB-IoT or LTE-M 
• IPAe + Indirect Download (CoAP/MQTT/DTLS) is ideal 

• Mobile across networks and countries
• Coverage can be sporadic 
• Indirect download with policy-based profile selection works well 
• Fallback and regional profiles are key  

• Harsh environments 
• Long lifecycle (10+ years) 
• Need robust retries and rollback strategies 
• Bootstrap + indirect mode recommended 

The eIM can apply rules such as: 

• “Use local operator X in region A; operator Y in region B” 
• “Switch profile if QoS falls below threshold” 
• “Apply local profile to comply with regulation after 90 days of roaming”  

Fallback can be triggered when: 

• Primary profile cannot attach 
• Device repeatedly fails to register 
• QoS is consistently poor 
• New profile fails after activation (rollback to previous)  

Possible causes: 

• Incorrect APN 
• Forbidden roaming 
• Weak radio conditions 

Actions: 

• Validate APN and credentials 
• Check signal and RAT settings 
• Consider alternative bootstrap operator 

Typical API families: 

• Device / eUICC APIs
  Register device
  Query state
  List associated profiles 

• Provisioning APIs
  Trigger operational profile download
  Assign local/regional profiles
  Schedule changes 

• Lifecycle APIs
  Enable / disable / delete profile
  Set fallback profile (backup subscription) 

• Monitoring APIs
  Logs and error retrieval
  Status dashboards / webhooks 

Possible causes: 

• Wrong URL or credentials 
• TLS / DTLS handshake failure 
• Firewall blocking MQTT/CoAP ports 

Actions: 

• Verify eIM endpoint and certificates 
• Check firewall & routing rules 
• Confirm protocol support (MQTT/CoAP vs HTTPS) 

Possible causes: 

• Unstable connectivity 
• Timeout due to long sleep intervals 
• DP+ unreachable 

Actions: 

• Tune retry window and back-off strategy 
• Use indirect mode for constrained networks 
• Verify SM-DP+ endpoint reachability 

Possible causes: 

• Overly aggressive rules 
• Poor coverage on primary profile
• Misinterpreted QoS metrics 

Actions: 

• Review fallback thresholds in eIM 
• Check coverage/QoS logs 
• Adjust policies and retest 

Possible causes: 

• Firmware bugs or mismatched state machines 
• Incomplete implementation of SGP.32 flows 
• Version incompatibility 

Actions: 

• Update agent firmware
• Reset provisioning state and re-enroll device 
• Validate implementation against official test cases 

1. Use Indirect Download with Lightweight Protocols for Constrained Devices
   CoAP/MQTT/DTLS via eIM is better for low-power devices than always-on TCP/IP.  
2. Choose IPAe for Simplicity, IPAd for Flexibility
   IPAe simplifies certification and suits simple hardware.
   IPAd unlocks Wi-Fi provisioning, richer logic, and advanced control.

3. Always Design a Fallback Strategy
   Plan what happens if a new profile fails — rollback paths are critical in remote deployments. 

4. Test Across Multiple Networks and Regions
   Especially important where regulations require local profiles (e.g., time-limited roaming). 

5. Align Orchestration Policies with Business Rules
   Regulatory rules, SLAs, and customer-specific operator choices should be reflected in eIM policies and automation.