The Road to eSIM Is Littered With Broken Promises

25.08.2025
guide-image

There’s no shortage of big promises in the eSIM space. Freedom-to-switch providers. Full lifecycle management. Total control. But take a closer look and you'll find something else buried beneath the marketing: failure.
 
There is a saying in German: die Straße ist gepflastert mit Leichen - the street is paved with dead bodies. It means many have tried, most have failed. In the world of the M2M eSIM (SGP.02), it’s an accurate description. The street is littered with overengineered systems, delayed deployments and “revolutionary” ideas that collapsed the moment they met reality.
 
At emnify, we chose a different path - focusing on the reality in front of us and solving for that. While others chase what eSIM might become in 18 to 24 months, we’ve made it work today, at scale, for real businesses.

The Overpromise of M2M eSIM

Much of the early excitement around the SGP.02 eSIM centered on remote provisioning of profiles. On paper, it made perfect sense: the ability to switch operators remotely, reduce logistics, and scale globally. In practice, it proved too complex, too expensive, and too closed-off to work for anyone outside of large automotives.

These systems were designed by and for industry giants with deep pockets and long timelines. The infrastructure costs alone put them out of reach for most businesses. And while these giants tried to engineer the perfect solution, the world moved on.

Consumer Devices, B2B Problems

As M2M eSIM (SGP.02) stalled, another story was unfolding. For years businesses had been using consumer devices like iPads, iPhones and Android tablets at scale in B2B operations. These devices are cost-effective, powerful and already eSIM-enabled. But when manufacturers began shipping eSIM-only models the well-oiled processes for physical SIM logistics and assembly became obsolete overnight, creating a new provisioning bottleneck. 

One of our customers shared how they ordered 6,000 eSIMs from their then-provider and quite literally received 6,000 individual A4 letters each containing a single QR code. For large deployments what should be a straightforward rollout became a manual, error-prone and time-consuming process.

The Consumer eSIM (SGP.22) was never built with business fleets in mind. It was designed for individuals to scan a QR code and activate a plan. That works until you need to deploy hundreds or thousands of devices across teams, countries, and workflows - at which point a simple consumer process becomes a massive operational challenge. 

This is the blind spot. Few are solving the reality of B2B deployments today, except us.

What We Solved and Why It Matters

We saw the gap and built around it. Instead of trying to reinvent Consumer eSIM, we integrated it into the business deployment flow - MDM systems, DNS filtering, automated provisioning. The eSIM profile delivery becomes part of the existing device rollout. No QR codes. No printouts. No broken workflows.

Discover Airlines shows what this looks like in practice. Their teams use iPads for their Electronic Flight Bags. With emnify integrated into their MDM, they deploy new devices with eSIMs already activated. No manual steps. No delays. Just control, scale and speed.

The Technology Everyone Said We Couldn’t Build

What makes this possible isn’t just the idea, it’s the infrastructure behind it. When we started emnify the telecom industry told us it couldn’t be done. Core networks were supposed to come from Ericsson or Nokia, not from a startup team of six. We ignored the so-called common wisdom and applied first principles to go fully cloud-native, building our own globally distributed core network from scratch. 

Our edge is that we own every piece of the network and SIM management stack. This lets us prototype fast, ship fast and adapt faster without waiting on vendor roadmaps or working around third-party limitations. When we see a real problem, we solve it not in 18 months but today. 

From Verticals to Value: Our Strategic Advantage

Another reason we move quickly is that we don’t build narrow, vertical solutions, we extract horizontal value. We look across industries like aviation, healthcare, logistics, and retail to identify common patterns, then solve the core job in a way that works everywhere.

Take eSIM logistics. Whether you’re equipping pilots, nurses, or field technicians, the requirement is the same: a simple, scalable, and controllable way to deploy and manage connectivity. That’s what we deliver.

Looking Ahead: SGP.32 and the Real Revolution

SGP.32, the next-gen standard, has generated significant buzz for its potential to address many of the shortcomings of past iterations. We believe in it. Unlike SGP.02, it is designed for broader adoption, with greater accessibility, flexibility and realism.

When it arrives, we’ll be ready. We see it as a growth lever. While some in the market fear the freedom-to-switch that SGP.32 enables, we embrace it. For every card we might lose to easier switching, we expect to gain four more because we deliver a superior product that businesses actually need. 

Final Thought

It’s this ability to solve today’s challenges while building for tomorrow that sets emnify apart. Our approach hasn’t gone unnoticed. In 2025 alone, we’ve been recognized as eSIM Provider of the Year at the MVNOs World Awards and received Platinum honors for eSIM Management Platform Innovation from Juniper Research. These awards underscore what our customers already know: when it comes to delivering real innovation in eSIM, emnify leads the way.

We’re not here to chase hypes. We solve real problems - clearly, efficiently and without unnecessary friction. That’s what made us the first to deploy a globally distributed cloud-native core. That’s what helped us master SGP.22 logistics when others ignored them. And that’s what will drive the next wave. Others can keep paving the street with failed eSIM promises. We’ll keep building what’s next - on solid ground.

I’d love to hear your perspective: where have you seen eSIM live up to the hype and where has it fallen short? How do you see the future of eSIM unfolding in your industry? Drop your thoughts here, let’s cut through the noise and talk about what actually works.

Ready to stop chasing eSIM promises and start scaling real deployments?

Let’s talk about how emnify can help you eliminate complexity and take control today.

Related Posts

Image for post What Is GSMA SGP.32? The Definitive Guide to the Next-Gen eSIM IoT Standard

What Is GSMA SGP.32? The Definitive Guide to the Next-Gen eSIM IoT Standard

Table of contents Introduction How does SGP.32 compare to SGP.02 and SGP.22? How SGP.32 Works: Key Components Explained IoT eSIM Architecture – SGP.32 Compliance & Standards: What You Need to Know Challenges & Implementation Considerations How emnify Supports SGP.32-Ready IoT Deployments Conclusion: Why SGP.32 Matters Introduction GSMA’s SGP.32 is the newest global SIM technology standard for IoT which finally makes remote profile management and profile switching a reality. It enables connected devices to securely download, manage, and switch SIM profiles over the air without requiring a user interface, QR codes, or physical SIM replacements. Unlike earlier GSMA standards designed for traditional machine-to-machine deployments, SGP.32 was defined specifically for modern IoT deployments, where physical SIM logistics and vendor lock-in have caused operational headaches for far too long. At its core, SGP.32 introduces a streamlined architecture that allows enterprises and connectivity providers to manage SIM profiles from any number of connectivity providers from one unified platform. At scale, this means, businesses are not locked into a single provider for their device’s full lifecycle and therefore are not burdened with costly SIM swaps when switching or adding new operators. Typical use cases for which this becomes extremely helpful to businesses deploying connected devices include: For manufacturers of connected devices (OEMs) that need devices to connect directly from the factory but don’t want the device to be locked to that specific network for their customers. Here SGP.32 enables that enables devices to be deployed with a bootstrap profile that gets the device online and SGP.32 enables any number of additional operator profiles to be added based on the device's deployment area. Providers of connected devices now have a built-in resiliency plan. In the past, if a business wanted to leave their connectivity provider it added complexity as it meant leaving their already deployed devices connected with their original operator (SIM swaps are too costly) and adding another provider for future deployments. This management of multiple operators added complexity and operational overheads. For providers of connected devices, SGP.32 also integrates a level of resiliancy that wasn’t available before. The fact that it is now possible to have multiple profiles on a single SIM means that a true ‘fallback’ option is available. What this means in reality? If the primary profile fails, the device can simply be switched to the backup operator. Not only does this protect uptime, but it also protects operations from unexpected events such as, outages, the operator switching off coverage in your deployment zone or even if the operator goes out of business. How does SGP.32 compare to SGP.02 and SGP.22? SGP.02 SGP.02 was designed for traditional M2M deployments. In theory, it enabled remote profile to download and switching. In practice, however, the architecture was complex, costly to integrate, and not well suited to low-power or bandwidth-constrained IoT devices. For most deployments, large-scale remote profile swapping simply wasn’t commercially feasible. SGP.22 SGP.22 was built for consumer devices like smartphones and tablets. It assumes a user interface, QR code scanning, and user-driven profile downloads. That works perfectly for phones, but not for 'screenless’ devices. SGP.32 SGP.32 is the first standard designed specifically for IoT fleets. It removes the need for user interaction, supports constrained environments like NB-IoT and LTE-M, and enables fully server-orchestrated profile lifecycle management at scale. How SGP.32 Works: Key Components Explained eUICC (Embedded Universal Integrated Circuit Card) Although not new or specific to SGP.32, the eUICC is crucial to enable remote profile management. The eUICC is the secure chip inside the SIM that can store multiple operator profiles. SM-DP+ (Subscription Manager Data Preparation+) The SM-DP+ is the secure server where eSIM profiles are stored, prepared, and encrypted for download to devices. Each profile has a unique identifier called an activation code, which is what devices use to retrieve the profile. The QR code used in consumer eSIM downloads is simply a graphical representation of that activation code. SM-DS (Subscription Manager Discovery Server) The SM-DS is a discovery service that devices can query to check if new eSIM profiles are available. If a profile is ready, it tells the device which SM-DP+ server hosts it so the profile can be downloaded. While commonly used in consumer eSIM deployments, it is often optional in IoT architectures where the platform already orchestrates the profile download. EID (eUICC Identifier) The unique ID assigned to every eUICC. It’s how the SIM is securely identified during remote provisioning. eIM (eSIM IoT Manager) The control layer introduced with SGP.32. It lets you remotely download, enable, disable, delete, and switch profiles across devices and fleets. The eIM can be a standalone platform or part of a traditional CMP like it is for emnify. Connectivity Management Portal Not new but as the name implies this is where you manage connectivity such as, adding removing coverage zones and changing plans. It is in the CMP that the eIM can be integrated so that SGP.32 functionality such as, adding or removing profiles can be managed from the same interface. IPA (IoT Profile Assistant) The IoT-native replacement for the consumer LPA. It runs on the device and handles profile discovery and downloads without needing a screen or user input. Activation Code Are required to activate the SIM by inputting them into the CMP/eIM. Bootstrap Profile A minimal connectivity profile that gets the device online for the first time so it can download its operational profile. Operational Profile The main operator profile used during normal device operation. Multiple operational profiles can live on the same SIM. Fallback Profile A secondary operator profile stored on the same SIM that can be activated if the primary one fails, protecting uptime and continuity. Polling Interval Is the frequency a device tries to connect to the eIM to understand if there is a new profile. IoT eSIM Architecture – SGP.32 SGP.32 Remote Profile Management Flow Explained The device connects using its existing profile The device is already online, typically via a bootstrap or operational profile. A profile download is scheduled on the eIM An operator profile is registered on the eIM using its activation code, preparing it for download to the device. The device checks the eIM for pending operations At its polling interval, the device contacts the eIM and discovers that a new profile is available, including which SM-DP+ server hosts it and which activation code to use. The IPA prepares the device The IPA establishes the secure session required to download the profile. The profile is retrieved from the SM-DP+ The encrypted operator profile is securely delivered from the SM-DP+ to the device. The eUICC securely stores the new profile The profile is installed on the eUICC but not necessarily activated yet. Profile activation is scheduled on the eIM A user or automated process configures the new profile to be activated. The device activates the profile During the next polling cycle, the device learns about the activation instruction from the eIM and the IPA activates the profile on the eUICC. The device switches connectivity The device begins operating on the new operator profile without any physical SIM change. Compliance & Standards: What You Need to Know SGP.32 is not just a new orchestration model. It is a GSMA-defined standard built on strict security, interoperability, and transport requirements. These compliance elements are embedded directly into the specification and are critical for secure, large-scale IoT deployments. Security All profile lifecycle operations between the eIM and the eUICC are cryptographically authenticated and integrity-protected. This ensures profiles cannot be downloaded, modified, or switched without proper authorization. Transport Protocols SGP.32 supports standard TCP/IP communication as well as lightweight protocols such as CoAP over UDP with DTLS encryption. This allows it to operate efficiently across a wide range of IoT environments, including low-power and bandwidth-constrained networks like NB-IoT and LTE-M. Challenges & Implementation Considerations Evolving Ecosystem SGP.32 adoption is still in progress across vendors, platforms, and standards bodies. Interpretations and support may vary as the ecosystem matures. Platform Maturity Not all IoT platforms will initially provide full eIM functionality, IPA support, or large-scale orchestration tooling. The depth of implementation will differ between vendors. Open Ecosystem vs. Closed Implementations While SGP.32 technically enables multi-operator profile management, not every provider will support open third-party profile orchestration. Some implementations may limit profile management to their own network ecosystem. Enterprises evaluating SGP.32 solutions should carefully assess whether cross-operator flexibility is genuinely supported in practice, not just in theory. Backward Compatibility Migration from older standards such as SGP.02 or SGP.22 is not possible. How emnify Supports SGP.32-Ready IoT Deployments As SGP.32 moves from specification to real-world deployment, the key question is not just compliance. It is implementation. The standard enables multi-profile, multi-operator orchestration. But whether that flexibility is truly available in practice depends on the platform operating the eIM layer. emnify’s cloud-native architecture was built around centralized, API-driven profile lifecycle management. Through its integrated eIM capabilities, enterprises can download, enable, disable, and switch both emnify and third-party operator profiles across fleets from a single control plane. This approach aligns directly with the architectural intent of SGP.32: operator independence at the profile level, not just at the hardware level. Rather than binding deployments to a single network ecosystem, emnify enables organizations to design IoT architectures where connectivity can evolve over time, whether adding new operators, localizing in new regions, or introducing fallback profiles for resilience. In practice, this means SGP.32 is not just supported, it is operationalized in a way that preserves long-term flexibility. Check our unique SGP.32 offer, the emnify Advanced eSIM. Conclusion: Why SGP.32 Matters GSMA SGP.32 marks a structural shift in how IoT connectivity is designed and operated. It moves the industry beyond hardware-bound SIM logistics and toward software-driven profile orchestration built specifically for headless, large-scale device fleets. By enabling secure, server-orchestrated lifecycle management, SGP.32 allows enterprises to add, change, and manage operator profiles remotely without physical intervention. Devices can ship connected from the factory with a bootstrap profile, reducing the need for multiple regional SKUs and eliminating much of the traditional SIM logistics associated with global deployments. At the same time, SGP.32 introduces the possibility of true provider independence. Enterprises can localize connectivity as deployments expand into new regions, add new operators over time, and avoid being locked into a single connectivity provider for the lifetime of a device. It also strengthens operational resilience. With the ability to store and manage multiple profiles on a single eSIM, organizations can introduce fallback connectivity options that protect uptime and reduce the operational risk of network outages or coverage changes. For organizations building global IoT deployments, understanding SGP.32 is no longer optional. It is foundational to designing connectivity architectures that remain flexible, scalable, and commercially adaptable over the full device lifecycle.