SGP.32 vs SGP.02: Understanding IoT eSIM Standards

When evaluating IoT eSIM solutions, the GSMA standard behind the implementation matters. SGP.32 and the legacy SGP.02 standard create very different outcomes for operational flexibility, enterprise control, multi-operator portability, and long-term deployment costs.

This guide explains the key differences between SGP.32 and SGP.02, why SGP.02 is no longer suitable for new IoT deployments, and how to check whether your eSIM solution uses modern SGP.32 architecture.

What are SGP.02 and SGP.32?

Both are GSMA specifications for remote SIM provisioning, allowing network operator profiles to be downloaded to SIM hardware over the air. However, they were designed for different use cases and control models.

SGP.02: legacy M2M standard

Published: 2013
Purpose: Early machine-to-machine remote SIM provisioning
Control model: Operator-centric, with the mobile network operator controlling profile changes
Architecture: Often includes proprietary extensions
Status: Legacy standard

Key limitation: Enterprises cannot usually switch operators independently. They must coordinate with the current operator that controls the provisioning platform.

SGP.32: modern IoT standard

Published: 2018, with later enhancements
Purpose: Enterprise IoT remote SIM provisioning
Control model: Enterprise-centric
Architecture: Standardised and interoperable
Status: Current standard for new IoT deployments

Key advantage: Enterprises can control operator switching without relying on the current operator’s co-operation.

Fundamental architectural differences

Control and ownership model

SGP.02

Who controls provisioning:
The mobile network operator that issued the original SIM usually controls the provisioning platform.

Profile change process:

1. The enterprise requests an operator switch
2. The current operator must approve and facilitate the change
3. The current operator initiates the profile download
4. The new operator profile is installed

Problem: The current operator may have little incentive to help a customer switch to a competitor. This can create delays, additional fees, or practical lock-in.

Real-world impact:

An enterprise wants to switch from Operator A to Operator B for better coverage or pricing.

SGP.02 process:

• Contact Operator A: “Please provision Operator B profiles to our devices”
• Operator A may respond: “We do not support that operator”, “There is a provisioning fee”, or “Technical implementation will take several months”
• The enterprise remains dependent on Operator A

SGP.32

Who controls provisioning:
The enterprise, or its connectivity provider, controls provisioning through an independent platform.

Profile change process:

1. The enterprise initiates the operator switch through its management platform
2. The provisioning platform downloads the new operator profile
3. The current operator does not need to be involved
4. The new operator profile is activated

Advantage: The current operator cannot block, delay, or charge for a switch to another provider.

Real-world impact:

The same enterprise wants to switch from Operator A to Operator B.

SGP.32 process:

• Log into the management platform
• Select the relevant devices
• Choose the Operator B profile
• Initiate the download
• Complete the switch without Operator A involvement

This is the core difference: SGP.32 gives enterprises greater operational freedom.

Profile management architecture

SGP.02

SM-SR, Subscription Manager Secure Routing:

• Hosted by the mobile network operator
• Operator controls which profiles can be provisioned
• Often limited to the operator’s approved partners

SM-DP, Subscription Manager Data Preparation:

• Also operator-controlled
• Creates profiles only for approved networks

Result: The enterprise is locked into the operator’s ecosystem. It can usually only switch to approved networks, which may not include true competitors.

SGP.32

SM-DP+, enhanced data preparation:

• Can be hosted by a connectivity provider or neutral third party
• Creates profiles from participating operators
• Uses standards-based interfaces

SM-SR:

• Independent of any single mobile operator
• Controlled by the enterprise or its connectivity provider
• Can provision profiles from operators with compatible integration

Result: Enterprises gain greater flexibility to manage profiles across operators that support SGP.32.

Interoperability and vendor lock-in

SGP.02

Proprietary extensions are common.

The GSMA SGP.02 specification allowed significant vendor-specific customisation. Many implementations include proprietary extensions.

Impact:

• An SM-SR from Vendor A may not work with an eUICC from Vendor B
• Profiles created by one SM-DP may not work on another vendor’s platform
• The enterprise can become locked into a specific vendor ecosystem

Real-world problem:

An enterprise deploys 50,000 devices with Vendor A’s SGP.02 eSIM solution. In year three, Vendor A increases platform fees by 50%. The enterprise wants to move to Vendor B.

Discovery: Vendor A’s proprietary extensions mean the existing eUICC chips will not work with Vendor B’s SM-SR. The fleet is locked to Vendor A’s platform.

Cost: The enterprise must either accept the increased fees or replace the deployed devices.

SGP.32

SGP.32 is designed for stronger standardisation and interoperability.

Impact:

• SGP.32 eUICCs are designed to work with compatible SGP.32 platforms
• Profiles are more portable across compliant systems
• Enterprises have more flexibility to change connectivity providers without replacing devices

Real-world benefit:

An enterprise deploys 50,000 devices with Provider A’s SGP.32 eSIM solution. In year three, Provider A increases fees. The enterprise evaluates Provider B.

Process:

• Provider B provisions profiles to the existing eUICC chips
• The switch is completed remotely
• No device replacement is required

Result: SGP.32 reduces the risk of long-term platform lock-in.

Technical comparison

Certificate and security model

SGP.02

Certificate authority structure:

• Operator-specific certificate chains
• Limited standardisation of root certificate authorities
• Proprietary trust models may be used

Security:

• Profile encryption often uses operator-controlled keys
• Security procedures may vary between implementations

SGP.32

Enhanced security:

• Standardised certificate infrastructure
• GSMA-approved root certificate authorities
• Mutual authentication between relevant provisioning components

Profile protection:

• End-to-end encryption using standardised algorithms
• Profile binding to a specific eUICC
• Tamper-resistant profile storage

Result: SGP.32 provides a more consistent security model.

Profile download process

SGP.02

Download initiation:

1. The operator-controlled SM-SR sends a download trigger by SMS or data
2. The eUICC contacts the SM-SR for the profile download URL
3. The SM-DP provides the profile
4. The eUICC installs the profile

Limitations:

• SMS-based triggers can be delayed, blocked, or lost
• Error recovery may be limited

SGP.32

Enhanced download process:

1. The provisioning platform sends a trigger using available mechanisms
2. The eUICC performs authentication with the SM-DP+
3. The SM-DP+ provides an encrypted profile with integrity checks
4. The eUICC validates, installs, and confirms installation

Improvements:

• More robust triggering options
• Better error detection and recovery
• Clearer status reporting throughout the process

Profile lifecycle management

SGP.02

Limited lifecycle control:

• Enable or disable profiles
• Delete profiles
• Basic status queries

Often not standardised:

• Profile updates
• Profile metadata management
• Granular policy control

SGP.32

Comprehensive lifecycle management:

Profile states:

• Downloaded
• Enabled
• Disabled
• Deleted

Operations:

• Enable or disable installed profiles
• Delete profiles to free storage
• Update profile metadata
• Query detailed profile status
• Set profile policies

Result: SGP.32 gives enterprises finer control over profile lifecycle management.

Migration path: SGP.02 to SGP.32

Can SGP.02 devices migrate to SGP.32?

Usually not.

Why:

SGP.02 eUICC chips were designed for the SGP.02 architecture. They may use:

• A different certificate structure
• Different security mechanisms
• A different command set

SGP.32 platforms are not generally designed to communicate with SGP.02 eUICC chips.

Exception: Some chip manufacturers produced hybrid eUICCs that supported both SGP.02 and SGP.32. These were more common during the transition period and should not be assumed.

Practical impact:

If devices were deployed with SGP.02 eSIM technology, they may not be remotely upgradeable to SGP.32. New deployments should use SGP.32-capable eUICC hardware.

Identifying what you have

Ask your connectivity provider:

1. Is our eSIM solution SGP.02 or SGP.32 compliant?
2. Can we provision profiles from multiple operators, or only approved partners?
3. Who controls the SM-SR: us, you, or the mobile operator?

Red flags:

• “Our proprietary eSIM solution”
• “Profile switching requires co-ordination with the current operator”
• “We support our partner operators only”

Green flags:

• “GSMA SGP.32 compliant”
• “You control profile provisioning through our platform”
• “The platform supports remote provisioning through standardised architecture”

Decision framework: verifying SGP.32 compliance

Questions to ask providers

Standards compliance:

• Is your eSIM solution GSMA SGP.32 compliant?

Control and ownership:

• Who controls the provisioning platform?
• Can we switch operators without involvement from the current operator?

Interoperability:

• Can we provision profiles from SGP.32-compliant operators where commercial agreements are in place?
• Can another compatible provider manage our existing eUICC chips in future?

Operator access:

• Which operators can you provision profiles from?
• Can new operators be added as they become available?

Red flags indicating SGP.02 or proprietary architecture

• “Our eSIM platform” without reference to SGP.32
• “Operator switching requires co-ordination with the current operator”
• “We support our partner operators”
• Vague answers about standards compliance
• “Proprietary enhancements for better performance”

Green flags indicating true SGP.32

• Clear reference to GSMA SGP.32 compliance
• Enterprise-controlled operator switching through a platform or API
• Interoperable SGP.32 architecture
• Clear documentation explaining the provisioning model

SGP.32 best practice for new deployments

1. Mandate SGP.32 in RFPs and contracts

Specify:

• The eSIM solution must be GSMA SGP.32 compliant
• The enterprise must retain control over profile provisioning, directly or through its provider
• The solution must support provisioning from compatible SGP.32 operators
• Interoperability with other SGP.32 platforms should be supported

Include testing:

• The pilot should demonstrate provisioning from at least two operators
• The enterprise should be able to initiate provisioning without current operator involvement

2. Test interoperability during the pilot

Do not rely on marketing claims alone.

During the pilot:

1. Provision the initial operator profile
2. Switch to a different operator profile
3. Confirm that the enterprise can control the process
4. Verify provisioning status visibility

If the provider cannot demonstrate multi-operator provisioning, the solution may not provide the flexibility expected from SGP.32.

3. Maintain platform independence

Even with SGP.32:

• Understand whether your provider controls the provisioning platform on your behalf
• Ensure contract terms allow you to migrate if needed
• Confirm that the eUICC architecture supports future provider flexibility

Best practice:

Use a connectivity provider with a proven SGP.32-ready platform, while ensuring your commercial terms preserve future flexibility.

4. Document control and governance

Define who can provision profiles.

Governance should include:

• Role-based access control
• Approval workflows before mass profile changes
• Audit logging for profile downloads and changes

Why this matters:

SGP.32 gives enterprises more control, but that control needs governance. Accidental mass provisioning of the wrong profile can create a major operational incident.

OV eSIM and SGP.32 readiness

OV supports modern eSIM and eUICC architectures designed for remote provisioning, lifecycle control, and global IoT deployment.

With OV, builders can manage connectivity through OV ONE, our in-house Connectivity Management Platform. OV ONE gives teams visibility and control across SIM lifecycle management, monitoring, provisioning, and API-first workflows.

OV provides IoT connectivity across 180+ countries and 600+ networks, helping teams deploy connected products globally without connectivity complexity.

To discuss eSIM and SGP.32 readiness for your deployment, contact: connectivity@worldov.com

© 2026 OV. All rights reserved.