Introduction
The world of cellular IoT connectivity is undergoing a transformation. At the center of this shift is the IoT eSIM, built on the new SGP.32 standard. While earlier eSIM models promised flexibility, they often fell short - relying on outdated protocols or requiring tight operator coupling. SGP.32 changes that.
This new standard doesn’t just simplify switching providers. It helps enterprises navigate regulatory complexity, improve operational resilience, and deploy at scale—without sacrificing control or compliance.
As deployment timelines shrink and global reach becomes a requirement rather than a luxury, SGP.32 positions itself as a foundation for the next era of connected devices.
What’s New About IoT eSIM (SGP.32)?
Let’s put the evolution into perspective:
- M2M eSIM (SGP.02): Originally developed for automotive use cases, this standard relied heavily on SMS and static integrations with a first operator. Switching providers required significant technical effort—and was rarely executed in practice.
- Consumer eSIM (SGP.22): Optimized for smartphones and tablets, it supports multiple profiles but depends on user interaction and lacks the remote management capabilities needed for IoT.
- IoT eSIM (SGP.32): Purpose-built for connected devices. It uses the same type of profiles as SGP.22 but introduces remote, programmable provisioning without SMS or physical access—and without binding a SIM to a single operator.
This evolution makes it possible for enterprises to deploy at scale, remain compliant across jurisdictions and retain control over connectivity throughout a device’s lifecycle.
Want a deeper technical dive into how SGP.32 bridges the gap between M2M and consumer eSIM? Read this guide by Mario Bucci →
Beyond Switching: Five Strategic Use Cases for IoT eSIM
While provider independence has often been the headline feature of eSIM, the real value of SGP.32 lies in its ability to help enterprises navigate the complexity of global deployments—especially when compliance, localization, and resilience are non-negotiable.
1. Meeting Regulatory Requirements Without Operational Overhead
In markets like Brazil, regulations require foreign SIMs to disconnect after a set period—typically 90 days—unless a local profile is used. With IoT eSIM, there’s no need to develop region-specific hardware or manually manage SIM replacements. Instead, a compliant profile can be downloaded remotely, allowing the same device SKU to operate legally across diverse jurisdictions.
This reduces the burden of regulatory fragmentation and ensures enterprises can remain compliant without compromising scale or speed.
2. Serving Diverse Customer Preferences with a Single Product Variant
Device manufacturers, such as those building EV charging stations or industrial gateways, increasingly face demands from end customers who already have established connectivity contracts. One client may require a specific network; another, a different one. Rather than building bespoke variants, manufacturers can deploy a single hardware model and assign operator profiles post-deployment—ensuring a seamless, customer-aligned experience without logistical complexity.
3. Adapting to Evolving Connectivity Policies
In some regions, legal frameworks require local breakout, specific data routing rules, or formal operator registration. IoT eSIM allows for dynamic policy enforcement by enabling the device to switch to a locally approved profile—helping enterprises stay ahead of evolving regulatory demands without physical intervention.
4. Building Resilience into the Connectivity Layer
With SGP.32, devices can store multiple operator profiles on a single SIM. This provides a safety net: if the primary operator experiences a network issue or outage, the device can automatically fail over to another available profile. It’s a practical way to ensure business continuity—especially in mission-critical deployments like fleet management, medical telemetry, or infrastructure monitoring.
5. Enabling Low-Touch, Constrained Devices to Stay Connected
Many IoT deployments—such as smart meters, asset trackers, or environmental sensors—operate in power-sensitive environments with limited bandwidth and wake cycles. SGP.32 supports indirect provisioning through protocols like MQTT and CoAP, enabling profile management even on devices that can't maintain persistent IP connections or support traditional polling methods.
This opens the door to remote provisioning in previously inaccessible scenarios, without sacrificing device performance or battery life.
What Does an Enterprise Need to Get Started?
Successful adoption of SGP.32 requires coordination between enterprise systems and the connectivity provider. Key components include:
- eUICC: SIM hardware supporting multiple profiles (provided by SIM vendor)
- iPA (IoT Profile Assistant): Logic for profile lifecycle management (hosted on the device or SIM)
- eIM (eSIM IoT Remote Manager): Manages secure remote updates (provided by the connectivity provider)
- SM-DP+: Delivers operator profiles to devices (provided by the connectivity provider)
iPAe vs. IPAd: Choosing the Right Profile Assistant
There are two implementation options for the IoT Profile Assistant (iPA), each suited to different types of devices:
- IPAe (on SIM): Plug & play integration, pre-certified, best for fast rollout and wide compatibility. Requires cellular connectivity for all provisioning actions.
- IPAd (on Device): Requires custom implementation but allows fine-tuned power management and control. It also enables profile downloads over alternative interfaces—such as Wi-Fi—if the device can establish a secure connection to the eIM and SM-DP+.
Most enterprises will find IPAe more practical, while IPAd is ideal for low-power or highly specialized devices that require more control or non-cellular provisioning options.
Direct vs. Indirect Profile Download
The choice between direct and indirect profile download affects device behavior and network setup:
- Direct Download: Uses TCP/IP. Ideal for general IoT devices with persistent connectivity.
In IPAd-based implementations, direct downloads can also occur over Wi-Fi if the device can establish a secure connection to the eIM and SM-DP+.
- Indirect Download: Uses CoAP, MQTT, or DTLS. Best for low-power, constrained devices that can’t maintain constant IP connections.
Frequently Asked Questions
Does IoT eSIM require embedded SIMs?
No. It supports all standard form factors—Mini, Micro, Nano, MFF2, and even iSIM.
Can I use Wi-Fi to download eSIM profiles?
Yes—but only with IPAd, the IoT Profile Assistant hosted on the device. If the device (e.g. an iPad or industrial controller) is capable of managing a secure connection to the eIM and SM-DP+ over Wi-Fi, it can download profiles without a cellular connection.
This is not possible with IPAe, which resides on the SIM and requires an active cellular connection to handle profile provisioning.
Can I run my own SM-DP+ or eIM?
Yes—but most enterprises will benefit from managed services offered by connectivity providers, unless operating at hyperscale.
How emnify Helps
At emnify, we support both IPAe and IPAd configurations and provide:
- A global SuperNetwork purpose-built for scalable IoT
- Regulatory-compliant profiles in markets like Brazil, India, and beyond
- Interoperability testing across eUICC, iPA, and SM-DP+ vendors
- A fully managed eIM infrastructure for indirect provisioning
- Fast-track onboarding designed for enterprises without telecom expertise
Final Word
SGP.32 isn’t just the next generation of eSIM—it’s a blueprint for global IoT success. It removes the old constraints of single-operator lock-in, physical provisioning, and fragmented compliance processes. With the IoT eSIM, enterprises can finally deploy once and scale globally—without losing control, slowing down, or risking non-compliance.
