SGP.32 Standard: Architectural Reality Beyond the Industry Hype

The IoT industry is currently fixated on a single acronym: SGP.32. While the promise of seamless switching makes for great marketing, the technical reality is far more demanding. At 1NCE, we recognize that SGP.32 is not a simple product you buy, but a complex architectural shift you implement. While it is a major step toward a software-defined SIM ecosystem, the road to a live deployment is paved with technical dependencies. 

Earlier eSIM Standards Already Solved Important Problems 

To understand why SGP.32 is challenging the status quo, we must look at the technical lineage that preceded it. Before SGP.32 appeared, two GSMA standards laid the foundation for remote SIM provisioning: 

• SGP.02 (M2M): This legacy industrial standard relies on a "push" model. The mobile network operator (MNO) controls profile switching through a Subscription Manager-Secure Routing (SM-SR) system. While robust, it is technically rigid and often requires costly, complex migrations between operator platforms. 

• SGP.22 (Consumer): This is the eSIM standard found in modern smartphones. It uses a "pull" model where a human user initiates a profile download, often by scanning a QR code via a Local Profile Assistant (LPA). Because it requires manual intervention, it is largely unsuitable for unattended IoT devices. 

Both standards work well for their intended environments, but IoT deployments often sit somewhere in between. Devices may not have screens or user interfaces or may operate unattended for years, and they are often managed as fleets rather than individually. That’s the scenario SGP.32 was designed for: 

• The "Pull" is Automated: Instead of a person scanning a code, a software component on the device (the IPA or IoT Profile Assistant) can "pull" a profile automatically based on pre-set rules. 

• The "Push" is Fleet-Wide: A cloud manager (the eIM or eSIM IoT Remote Manager) can "push" instructions to thousands of devices at once to go and "pull" a new profile. 

SGP.02 vs. SGP.22 vs. SGP.32 (Profile Switching) 

New Components of the SGP.32 Architecture 

SGP.32 introduces a slightly different architecture for managing connectivity profiles. Instead of relying primarily on operator-controlled infrastructure, the new specification adds components that allow device platforms and IoT systems to take a more active role. 

SGP.32 vs. SGP.22 

The standard introduces the following components that rewrite the rules of connectivity management: 

• IoT Profile Assistant (IPA): In the consumer world, the LPA is an app on your phone. In SGP.32, this is replaced by the IPA, which resides on the IoT device itself. The IPA can be implemented in two ways: IPAd (on the device software) or IPAe (on the eSIM chip itself). It acts as the critical proxy between the eSIM and the remote manager. 

• eSIM IoT Remote Manager (eIM): This is the "brain" of the operation. The eIM allows an IoT OEM to remotely enable, disable, or delete profiles across a fleet of devices from a centralized cloud platform. 

SM-DP+: The Subscription Manager-Data Preparation+ replaces the older SM-DP/SM-SR infrastructure, streamlining the delivery of encrypted operator profiles. 

Let’s consider that the transition to SGP.32 is not a software patch, while it requires a complete rethink of the device-to-cloud stack. 

Challenges to Implementation of SGP.32 

There is a significant amount of misinformation circulating in the market. To protect our customers from architectural risk, we have to be clear about what SGP.32 cannot do today: 

1. The Hardware Dependency: One of the most persistent myths is that SGP.32 can be retroactively applied to existing SIMs. It cannot. SGP.32 requires a new generation of eUICC-capable SIM hardware specifically designed to support the new command sets and IPA modules. 

2. Device-Side Integration: Because the IPA must reside on the device, implementing SGP.32 often requires a hardware or firmware redesign. For many companies with legacy hardware, the transition to SGP.32 is not a simple software patch but a major engineering undertaking. 

3. Supply Chain Maturity: The ecosystem is still catching up. From the availability of SGP.32-certified modules to the readiness of MNOs to provide compatible profiles, the supply chain is in a state of flux. 

4. Architectural Complexity: SGP.32 turns connectivity into a project. It requires defining who owns the eSIM, how bootstrap profiles are managed, and how the device handles profile switching in areas with poor coverage. 

SGP.32 is a powerful evolution, but its success depends entirely on solving these hardware and integration dependencies long before the first device ever hits the field. 

When Does SGP.32 Make Sense? 

One important thing to remember is that IoT deployments vary widely. Some projects benefit from simple connectivity models, where devices connect globally through roaming agreements. Others may benefit from more flexible connectivity strategies.  

You likely do not need SGP.32 if: Your primary goals are better coverage, lower costs, or a single SKU for global shipping. At 1NCE, we already solve these challenges through our standard Global SIM (GSIM) and our existing "Freedom to Switch" capabilities based on SGP.02. 

You should consider SGP.32 if: You are planning a large-scale international deployment where roaming is not sufficient due to local regulations (like in Brazil or Turkey), you are already planning a hardware redesign, and your technical team is prepared to run a structured enterprise integration project. 

The 1NCE Perspective is Pragmatism Over Promotion 

At 1NCE, our stance is clear: we are pragmatic supporters of SGP.32. We treat it as the next phase of our "Freedom to Switch" capability. For the right customers, it offers a path toward a truly software-defined SIM future. However, because of the current technical requirements, we offer SGP.32 support as a custom, project-based engagement led by our Solution Architects. 

The arrival of SGP.32 signals that the IoT industry is maturing. Connectivity is no longer a commodity you buy, but an architectural layer you build. We encourage our customers to look beyond the instant switching promises often heard in the industry. Instead, ask the hard questions: Is your hardware ready for an IPA? Do you have the infrastructure to manage an eIM? Is the added complexity worth the ROI compared to a high-quality global roaming solution? 

SGP.32 is an important step toward a seamless SIM future, and 1NCE is here to help you navigate that transition with technical credibility and architectural foresight. The future is software-defined, but the implementation must remain grounded in reality.