The Definitive Guide to the GSMA IoT eSIM Specification

---

Executive Summary

SGP.32 is the GSMA’s Remote SIM Provisioning specification built specifically for IoT. It defines how eSIM (eUICC) profiles are securely downloaded, managed, and switched in headless, large-scale IoT deployments — without human interaction, without QR codes, and without site visits.

It was released in May 2023 and reached its current version (v1.2) in late 2024, with testing, certification, and commercial rollout accelerating through 2025 and into 2026.

Unlike the earlier standards it builds upon — SGP.02 for M2M and SGP.22 for consumer smartphones — SGP.32 was designed from the ground up for the realities of modern IoT: constrained devices, global rollouts, long lifecycles, and the need for commercial flexibility at fleet scale.

It is not just a SIM specification. It is an ecosystem framework that changes how IoT connectivity is architected, provisioned, and managed over time.

---

The Problem SGP.32 Was Created to Solve

To understand SGP.32, you need to understand what was not working.

The industry previously relied on two GSMA specifications for remote SIM provisioning, neither of which was fit for modern IoT.

SGP.02: Built for Early M2M

SGP.02 was designed for industrial M2M deployments with long-term contracts, operator-controlled infrastructure, heavy backend integration, and static commercial relationships.

It required dedicated entities — SM-DP (Subscription Manager – Data Preparation) and SM-SR (Subscription Manager – Secure Routing) — along with tight coordination between mobile network operators. It relied on SMS-based transport, which is increasingly problematic as NB-IoT deployments often have limited or no SMS support.

SGP.02 works well in controlled environments such as smart metering frameworks, but it is operationally heavy, expensive to implement, and creates structural lock-in to the SM-SR operator.

For many IoT businesses today, that model is too rigid.

SGP.22: Built for Smartphones

SGP.22 was designed for consumer devices. It assumes a screen, a user, QR code scanning, and manual profile activation via a Local Profile Assistant (LPA) — typically an app on the device.

That is fine for phones. It is meaningless for smart meters, solar inverters, EV charge points, environmental sensors, industrial routers, and asset trackers.

IoT devices are headless. They sit in cabinets, on poles, in basements, and in plant rooms. There is no one scanning QR codes.

The Gap

The industry needed a specification that combined the remote management capability of SGP.02 with the more modern, IP-based architecture of SGP.22 — but redesigned for devices that have no screen, no user, and potentially severe constraints on power, bandwidth, and processing.

SGP.32 is that specification.

---

What SGP.32 Actually Is

SGP.32 (formally: GSMA SGP.32 — eSIM IoT Remote SIM Provisioning) defines the technical architecture for remotely provisioning and managing eUICC profiles in IoT devices that are network-constrained and/or user-interface-constrained.

It works in conjunction with SGP.31, which defines the high-level architecture and requirements. SGP.32 provides the detailed technical specification.

It introduces a modernised architecture that allows:

• Devices to ship with a bootstrap profile for initial connectivity
• Secure remote download of operator profiles over IP (no SMS dependency)
• Automated profile lifecycle management — download, enable, disable, delete
• Minimal or zero human interaction
• Suitability for constrained hardware with limited power and bandwidth
• Fleet-scale orchestration across thousands or millions of devices

It recognises that IoT deployments can involve tens of thousands of devices across multiple countries and networks, often with 10–15 year lifespans.

This is not incremental change. It is structural.

---

Understanding eUICC — The Foundation

Before going deeper into SGP.32’s architecture, it is essential to understand eUICC, because SGP.32 defines how eUICC is managed in IoT — and the terms are frequently confused.

What eUICC Is

eUICC stands for Embedded Universal Integrated Circuit Card. It is the technology that makes modern eSIM functionality possible.

But it is not a form factor. It is not a chip. It is not a brand name for a small SIM card.

eUICC is a capability layer — a secure, standards-based software architecture that enables operator profiles to be remotely provisioned, switched, and managed over the air, without physically touching the device.

A traditional SIM card is manufactured with a single operator profile permanently written to it. To change operator, you change the physical card.

An eUICC can store multiple operator profiles simultaneously, download new profiles over the air, switch between active profiles remotely, and delete profiles that are no longer required. It can operate with a bootstrap profile for initial connectivity before the operational profile is loaded.

The Terminology Distinction

These terms are not synonyms, and conflating them leads to procurement mistakes:

• UICC = the Universal Integrated Circuit Card — the smart card platform
• eUICC = the smart card platform enhanced with remote profile management capability
• eSIM = commonly refers to the MFF2 soldered chip form factor, but technically describes embedded SIM with remote provisioning capability
• iSIM = eUICC capability integrated directly into a system-on-chip or modem

An eUICC can exist in a removable SIM card (2FF, 3FF, 4FF), a soldered MFF2 chip, a compact MFF4 module, or an iSIM within a system-on-chip. The form factor is irrelevant. What matters is that the device has an eUICC-capable secure element and the infrastructure to manage it.

eUICC Form Factors for IoT

Form Factor	Dimensions	Description	Typical IoT Use
2FF (Mini-SIM)	25mm × 15mm	Removable. Can be eUICC-enabled.	Legacy industrial devices, vehicles
3FF (Micro-SIM)	15mm × 12mm	Removable. Can be eUICC-enabled.	Mid-size IoT devices
4FF (Nano-SIM)	12.3mm × 8.8mm	Removable. Can be eUICC-enabled.	Compact trackers, consumer IoT
MFF2	5mm × 6mm	Soldered to PCB. Industrial grade.	Routers, meters, chargers, gateways
MFF4	2mm × 2mm	Soldered. Ultra-compact.	Wearables, compact sensors
WLCSP	<25% of MFF2	Wafer-level package.	Highly space-constrained devices
iSIM	Integrated into SoC	No discrete component.	Mass-market IoT, lowest cost/size

For most industrial IoT applications today — routers, gateways, meters, charge points — MFF2 with eUICC capability remains the default choice.

eUICC Security

The eUICC is a certified secure element. Chips from major silicon vendors (STMicroelectronics, Infineon, NXP) undergo Common Criteria evaluation, typically to EAL5+ level, providing tamper-resistant hardware, protected key storage, resistance to side-channel attacks, and secure boot processes.

Each operator profile on the eUICC is stored in its own Issuer Security Domain – Profile (ISD-P), providing cryptographic isolation between profiles.

SGP.32 builds on this secure hardware foundation. It does not weaken eUICC security — it preserves the strong cryptographic model while introducing the management architecture needed for IoT at scale.

---

How SGP.32 Works — The Architecture

The most important architectural difference with SGP.32 is philosophical.

SGP.02 was operator-centric. The SM-SR was typically controlled by the MNO, and changing SM-SR meant changing the entire management infrastructure — creating structural lock-in.

SGP.22 was user-centric. It required a human to initiate profile operations via a screen.

SGP.32 is solution-centric. It introduces a new orchestration model where the enterprise or device owner controls the provisioning lifecycle, not the operator and not a human user.

The Core Components

SGP.32 introduces three key components that work together:

eIM — eSIM IoT Remote Manager

The eIM is the central orchestration component. It is a server-side platform that manages profile lifecycle operations across an IoT fleet.

The eIM replaces the role of both the human user (from SGP.22) and the operator-locked SM-SR (from SGP.02). It acts as a “virtual user” that can issue commands to devices on behalf of the enterprise.

The eIM can:

• Trigger profile downloads from an SM-DP+
• Enable, disable, and delete profiles on target eUICCs
• Manage profile state across entire device fleets
• Queue and batch profile operations at scale
• Provide cryptographically verified confirmation of each operation

Critically, the eIM is portable. Unlike the SM-SR in SGP.02, the enterprise can change eIM providers without replacing hardware. This breaks the structural lock-in that plagued earlier M2M deployments.

The eIM can be operated by the device manufacturer, the enterprise, the connectivity provider, or a third-party platform — whoever the device owner chooses.

IPA — IoT Profile Assistant

The IPA is the device-side component that handles communication between the eIM and the eUICC. It is the IoT equivalent of the LPA (Local Profile Assistant) in consumer eSIM, but designed to work without user interaction.

The IPA can be implemented in two ways:

• IPAd — running on the IoT device itself (in the device’s application processor or modem firmware)
• IPAe — embedded within the eUICC, which minimises device-side complexity

For many IoT device manufacturers, IPAe is the preferred option because it requires no firmware changes to the device. The profile management logic resides entirely in the SIM, with the device only needing to support basic Bearer Independent Protocol (BIP) and SIM Toolkit (STK) functions that most modern modems already provide.

SM-DP+ — Subscription Manager Data Preparation

SGP.32 reuses the SM-DP+ from the consumer specification (SGP.22). This is the server that hosts and encrypts eSIM profiles before they are downloaded to the eUICC.

This reuse is deliberate. It means SGP.32 can leverage the existing SM-DP+ infrastructure that mobile network operators have already deployed for consumer eSIM, reducing the barrier to adoption.

How These Components Interact

The provisioning flow works as follows:

1. The MNO prepares a profile and loads it onto their SM-DP+ server
2. The eIM triggers the operation — instructing the target device to download a profile
3. The IPA receives the instruction and establishes a secure connection to the SM-DP+
4. The eUICC authenticates with the SM-DP+ using mutual authentication and certificate-based trust chains
5. The profile is downloaded over an encrypted channel and installed in a secure ISD-P domain on the eUICC
6. The profile is enabled and the device registers on the new network
7. The eIM receives confirmation — a cryptographically signed verification that the operation succeeded

All of this happens over IP. There is no SMS dependency, which is critical for NB-IoT and LTE-M deployments where SMS support is limited or unavailable.

What SGP.32 Inherited

SGP.32 is sometimes described as a hybrid specification. It took the best elements of its predecessors while adding IoT-specific innovation:

Inherited From	What SGP.32 Took	What SGP.32 Changed
SGP.02 (M2M)	Remote management capability	Replaced operator-locked SM-SR with portable eIM
SGP.22 (Consumer)	SM-DP+ infrastructure, modern IP-based transport	Replaced user/screen with automated eIM orchestration
New in SGP.32	—	eIM, IPA (IPAd/IPAe), PSMO cryptographic authentication, fleet-scale operations

---

Why SGP.32 Matters Now

Several converging trends have made SGP.32 not just useful, but necessary.

1. Global Deployments Are Standard

Many IoT products are designed once and deployed globally. Managing multiple operators, regional roaming rules, regulatory requirements, and spectrum changes is no longer optional.

SGP.32 allows operator profile switching post-deployment. That matters when commercial terms shift or coverage realities change.

2. 2G and 3G Network Sunset

The UK and many global markets are shutting down legacy networks. Devices deployed five years ago may face network retirement before end-of-life.

With SGP.32, profile changes can be made remotely rather than replacing hardware — protecting the investment in deployed infrastructure.

3. Commercial Flexibility and Lock-In Reduction

Traditional M2M relationships often locked devices to specific operators at manufacture, creating long-term risk.

SGP.32 enables post-deployment operator changes, greater supplier competition, and reduced vendor lock-in. The portable eIM means even the management platform can be changed without touching hardware.

For enterprises, that translates into commercial leverage over the entire device lifecycle.

4. Scale and Automation

IoT is no longer niche. It is infrastructure.

Deployments in energy, utilities, transport, and smart cities can reach tens of thousands of endpoints. Manual SIM swaps are not viable. SGP.32 supports automated provisioning at fleet scale, with the eIM orchestrating operations across entire device populations.

5. NB-IoT and LTE-M Compatibility

SGP.02 relied on SMS for transport. Many NB-IoT deployments have limited or no SMS support. SGP.32’s IP-based architecture removes this dependency, making it compatible with the full range of LPWAN technologies that are replacing 2G for low-power IoT.

---

SGP.02 vs SGP.22 vs SGP.32 — Comparison

Feature	SGP.02 (M2M)	SGP.22 (Consumer)	SGP.32 (IoT)
Target devices	Industrial M2M	Smartphones, tablets	IoT: sensors, routers, meters, trackers
Control model	Operator-centric	User-centric	Solution/enterprise-centric
User interaction	Minimal (operator-managed)	Required (QR code, app)	None (automated)
Profile manager	SM-SR (operator-locked)	LPA (on-device, user-driven)	eIM (portable, fleet-scale)
Device-side component	—	LPA	IPA (IPAd or IPAe)
Transport	SMS-based	IP-based	IP-based (no SMS dependency)
Profile delivery	SM-DP + SM-SR	SM-DP+	SM-DP+ (reused from SGP.22)
Lock-in risk	High (SM-SR tied to operator)	Low (user controls)	Low (eIM is portable)
Fleet management	Complex, per-device	Not designed for fleets	Native fleet-scale orchestration
Constrained device support	Limited	Not applicable	Designed for constrained hardware
NB-IoT compatible	Problematic (SMS dependency)	Not applicable	Yes (IP-native)
GSMA release	2013 (v3.x current)	2016 (v2.x current)	2023 (v1.2 current)
Market maturity	Established, legacy	Established, high volume	Commercialising 2025–2026

---

SGP.32 in Real-World IoT Applications

EV Charging Infrastructure

An EV charger deployed nationwide faces different network strength in rural versus urban areas, long lifespans, remote firmware update requirements, and strict security requirements.

With SGP.32, chargers can ship with a bootstrap profile, operational profiles can be switched if coverage proves inadequate, commercial contracts can evolve, and connectivity can be maintained without site visits. The eIM manages the entire fleet from a single platform.

Smart Metering and Utilities

Utility deployments demand long-term stability, regulatory compliance, and minimal operational disruption. If a network provider changes pricing, retires spectrum, or suffers service issues, SGP.32 allows profile migration without replacing installed devices.

This is operational resilience that was simply not achievable with fixed SIMs or even traditional M2M eSIM.

Industrial Routers and Gateways

Industrial cellular routers deployed in substations, cabinets, and remote sites typically have 10–15 year operational lifespans. They may outlive the networks they were originally configured to connect to.

With SGP.32, the connectivity layer can be updated without a site visit. A router like the Teltonika RUT241 eSIM model can have its operational profile changed remotely via the eIM, responding to coverage changes, commercial renegotiation, or network sunset.

Solar, BESS, and Distributed Energy

Energy infrastructure in remote or rural locations often faces challenging coverage conditions. SGP.32 provides the flexibility to test multiple operators and switch to the one that delivers acceptable performance at each site — all managed centrally.

Asset Tracking and Fleet Management

Tracking devices move across borders. SGP.32 enables connectivity management across multiple countries and operators without relying solely on roaming agreements, which are increasingly subject to regulatory restrictions such as permanent roaming rules in some European markets.

---

The UK and European eUICC Ecosystem

SGP.32 does not exist in isolation. It operates within an ecosystem of network operators, connectivity platforms, eUICC providers, silicon vendors, module manufacturers, and device makers.

Understanding who the key players are — and where they fit in the supply chain — is essential for making informed procurement and architecture decisions.

UK Mobile Network Operators

Operator	Parent	IoT Technologies	eUICC / eSIM Support
EE	BT Group	4G, 5G, LTE-M, NB-IoT	eSIM supported. IoT Hub platform.
Vodafone UK	Vodafone Group	4G, 5G, NB-IoT, LTE-M	eUICC via Global GDSP. Managed IoT platform.
Virgin Media O2	Liberty Global / Telefónica	4G, 5G, LTE-M	eSIM supported via O2 IoT platform.
Three UK	CK Hutchison (merging with Vodafone)	4G, 5G	IoT offering evolving post-merger.

IoT Connectivity Platforms and MVNOs

These specialist providers sit between MNOs and device deployers, offering multi-network IoT SIMs, eSIM provisioning, and connectivity management platforms.

Company	HQ	Proposition	eUICC / SGP.32 Position
Eseye	UK	Integration-led IoT connectivity. AnyNet eSIM. Device-level analytics.	eUICC + Multi-IMSI. Proprietary AnyNet platform.
1NCE	Germany	Flat-rate IoT connectivity. Developer-friendly APIs.	eUICC supported. Multi-IMSI. Low cost at scale.
emnify	Germany	Cloud-native IoT connectivity. IoT SuperNetwork. 190+ countries.	eUICC. SGP.32 roadmap. eSIM Provider of the Year 2025.
Wireless Logic	UK	Largest UK-HQ IoT connectivity provider. Multi-network. Strong channel.	Multi-IMSI. eUICC options. UK market leader.
Velos IoT	UK/Jersey	Global IoT connectivity. Enterprise-grade SIM lifecycle management.	eUICC. Multi-IMSI. Nomad eSIM platform.
1GLOBAL	UK	Full MVNO in 10 countries. GSMA-certified. White-label capability.	eUICC. GSMA certified. Kaleido Champion Vendor.
Pangea Connected	UK	UK IoT connectivity specialist. Strong in CCTV, retail, transport.	Multi-IMSI. eSIM roadmap.
1oT	Estonia	Unified global IoT platform. 190+ countries.	eUICC eSIM. Single-SKU global deployment.

eUICC OS Providers

These companies provide the eUICC operating system and SIM management software — the core enablers of remote provisioning.

Company	HQ	Key Products	SGP.32 Status
Giesecke+Devrient (G+D)	Germany	Sm@rtSIM platform. AirOn eSIM management. Converged SIM/SE.	SGP.02, SGP.22, SGP.32 supported.
Thales	France	eUICC OS. SM-DP+ infrastructure. iSIM (with Qualcomm).	SGP.02, SGP.22, SGP.32 supported.
IDEMIA	France	eUICC OS. Smart Connect platform.	SGP.02, SGP.22. IoT RSP support.
Kigen	UK	Kigen OS. iSIM. MFF4 eUICC. First market-ready eIM (SGP.32 v1.2).	SGP.32 leader. First production eIM.

eUICC Silicon Vendors

Company	HQ	Key Products	Form Factors
STMicroelectronics	Switzerland/France	ST4SIM series. ST33G1M2M.	MFF2, WLCSP, QFN8
Infineon	Germany	OPTIGA Connect eSIM. SLC37 secure controllers.	MFF2, WLCSP
NXP Semiconductors	Netherlands	SN100 series. Converged SIM/SE/NFC.	MFF2, WLCSP

Cellular Module Vendors

Company	HQ	Position	Note for UK/European Buyers
Telit Cinterion	Italy/US	Only Western vendor in global top 5. Former Thales module business.	Key Western alternative. RED Directive compliance lead. European engineering roots.
Quectel	China	Global market leader (~47% share). Extensive product range.	Added to US 1260H list Jan 2025. Geopolitical risk creating dual-sourcing discussions.
Fibocom	China	Growing global share. Automotive and industrial focus.	Growing Western presence. Similar geopolitical considerations to Quectel.
Nordic Semiconductor	Norway	nRF91 series for LTE-M/NB-IoT. Low-power specialist.	Strong in LPWAN IoT. Not full broadband modules.
u-blox → Trasna	Switzerland	Exiting cellular modules. Being acquired by Trasna.	Transitional. Watch Trasna for successor products.

Industrial Router and Gateway Manufacturers

Company	HQ	eUICC / eSIM Support	UK Relevance
Teltonika Networks	Lithuania	eSIM variants (RUT241 eSIM). Dual-SIM across range. eUICC-ready.	Market leader in UK SME/mid-market IoT routing.
Robustel	UK/China	eSIM models available. Dual-SIM standard. RCMS cloud management.	Growing. Competitive. UK-based support.
Peplink / Pepwave	Hong Kong/US	eSIM in newer models. SpeedFusion bonding. Multi-SIM.	Strong in transport, maritime, enterprise WAN.
Cradlepoint	US (Ericsson)	eSIM supported. NetCloud enterprise platform.	Enterprise segment. Premium pricing.

Standards Bodies

Organisation	Role
GSMA	Defines RSP specifications: SGP.02, SGP.22, SGP.31/32. eSIM certification.
ETSI	Defines physical and electrical specifications for UICC/eUICC form factors.
Trusted Connectivity Alliance	Defines eUICC Profile Package specifications. Slice SIM (SSIM) support.
GlobalPlatform	Defines secure element architecture and card management framework.

---

Security in SGP.32

Security is not an afterthought. It is central to the specification.

What Carries Over

SGP.32 preserves the strong cryptographic foundation of earlier standards. The eUICC remains a certified secure element (typically Common Criteria EAL5+) with tamper-resistant hardware and protected key storage. Profile download and management use mutual authentication, encrypted channels, and certificate-based trust chains.

What SGP.32 Adds

SGP.32 introduces Profile State Management Operations (PSMO) that are cryptographically authenticated by the eIM. This is new — it was not present in SGP.02 or SGP.22.

Every profile operation (enable, disable, delete) is signed by the eIM, and the eUICC provides a cryptographically verifiable confirmation back. This prevents unauthorised profile management — for example, from malware on the device attempting to switch profiles without authorisation.

The secure binding between eIM and eUICC ensures that only the authorised eIM can manage profiles on a given device. If the eIM binding needs to change (e.g., the enterprise switches management platform), there is a defined process for transferring eIM ownership.

Operational Security Benefits

Beyond the inherent architecture, SGP.32 provides practical security advantages:

• Profile rotation — if credentials are compromised, a new profile can be pushed remotely
• Operator migration — if a network operator suffers a security incident, devices can be moved to an alternative network
• Remote decommissioning — profiles can be disabled or deleted when devices are retired
• Fleet-wide incident response — the eIM can push profile changes across an entire fleet in response to a security event

For enterprises in regulated sectors — energy, utilities, transport, healthcare — these capabilities directly support compliance and risk management requirements.

---

Commercialisation Status — Where SGP.32 Stands Today

SGP.32 is real, but it is still early.

What Is Ready

• The core specification is finalised (SGP.32 v1.2, December 2024)
• Test specifications are complete (released early 2025)
• GSMA certification is available for eUICC, SM-DP+, and IPA components
• Kigen announced the first market-ready eIM in October 2024, compliant with SGP.32 v1.2
• Simplex Wireless, Webbing, and others have announced eIM platforms
• Vendors began achieving certifications from Q2 2025 onwards
• Initial commercial deployments are underway, including reported 1M+ connection projects

What Is Still Maturing

• The ecosystem of certified, interoperable components is still growing
• Cross-vendor interoperability testing (different eUICC OS + different eIM + different SM-DP+) is still in early stages
• Broad commercial availability of SGP.32-native eUICC hardware across all module vendors is not yet universal
• Enterprise tooling and integration with existing device management platforms is developing

Practical Guidance

ABI Research initially forecast 2.9 million SGP.32 profile downloads in 2025, growing to 194 million by 2029. Due to ecosystem maturation delays, the commercial acceleration is now expected primarily from H2 2026.

Kaleido Intelligence forecasts approximately 50 million SGP.32-compliant eSIMs under management globally by 2027.

For enterprises planning new IoT deployments today, the pragmatic approach is:

• Design for SGP.32 — specify eUICC hardware that supports the IoT RSP specification
• Deploy with what works now — use Multi-IMSI, SGP.02, or proprietary pre-standard solutions for immediate needs
• Plan for migration — ensure your architecture can transition to SGP.32 as the ecosystem matures
• Test early — engage with eIM providers and validate interoperability with your target hardware

SGP.32 is not backward compatible with SGP.02. Existing SGP.02 fleets cannot be migrated — they will need to be replaced over time. New deployments should be designed with SGP.32 readiness as a baseline.

---

Procurement Considerations

When specifying SGP.32 capability for IoT projects, verify the following:

Hardware

• Does the eUICC support SGP.32 (IoT RSP), or only SGP.02 / SGP.22?
• Does the cellular modem support the AT commands and BIP/STK functions required for IPA operation?
• What eUICC form factor is required (MFF2, removable, iSIM)?
• What is the industrial temperature rating?
• How many profiles can be stored simultaneously?

eUICC OS and IPA

• Which eUICC OS is loaded (G+D, Thales, IDEMIA, Kigen)?
• Is IPAe supported (profile management logic on the eUICC), or is IPAd required (on the device)?
• Is the OS updatable post-deployment?

eIM Platform

• Who operates the eIM? Is it the connectivity provider, the device OEM, or an independent platform?
• Is the eIM GSMA-compliant? Is it certified?
• Can the eIM be changed without replacing hardware (portability)?
• What fleet management capabilities does the eIM provide?
• What APIs are available for integration with existing device management platforms?

Commercial Terms

• Who owns the eUICC — the device OEM, the connectivity provider, or the end customer?
• Are there eIM lock-in clauses?
• What are the per-profile provisioning costs?
• Is bootstrap connectivity included?
• What happens if you want to change eIM provider?

Getting these details right at the procurement stage prevents costly rework and commercial disputes over a 10–15 year device lifecycle.

---

Common Misconceptions

“SGP.32 means instant operator switching”

Not quite. SGP.32 provides the mechanism for remote profile switching, but the speed and automation depend on the eIM platform, the provisioning infrastructure, and the commercial agreements with operators. The specification enables flexibility — the ecosystem must support it.

“SGP.32 replaces SGP.02 immediately”

No. Many legacy deployments will continue using SGP.02 for years. SGP.32 is the future for new IoT designs, but existing SGP.02 fleets are not migratable. Plan for coexistence.

“All eSIM chips support SGP.32”

No. SGP.32 requires eUICC hardware running an OS that supports the IoT RSP specification, including IPA functionality. Not all early eSIM modules are compatible. Always verify.

“SGP.32 eliminates SIM management”

It transforms how SIM management works — from physical logistics to software-defined orchestration — but profile lifecycle management, provisioning coordination, and commercial oversight are still required. They simply become centralised and automated.

“SGP.32 is only for large enterprises”

The simplified architecture and portable eIM model specifically lower the barrier for SMEs and mid-market deployments. You do not need operator-scale infrastructure to benefit from SGP.32.

---

Frequently Asked Questions

What is SGP.32?

SGP.32 is the GSMA’s technical specification for Remote SIM Provisioning in IoT devices. It defines how eSIM (eUICC) profiles are downloaded, managed, enabled, disabled, and deleted remotely in headless, constrained IoT devices — without human interaction. It was released in May 2023 and is currently at version 1.2.

How does SGP.32 work?

SGP.32 works through three core components. The eIM (eSIM IoT Remote Manager) acts as a cloud-based fleet orchestrator, issuing profile management commands. The IPA (IoT Profile Assistant) sits on the device or within the eUICC, handling secure communication between the eIM and the SIM. The SM-DP+ (Subscription Manager – Data Preparation) hosts encrypted operator profiles for download. The eIM triggers the operation, the IPA facilitates it, and the eUICC authenticates and installs the profile — all over IP, all without human involvement.

What is SGP in eSIM?

SGP stands for SIM Group Project — the GSMA working group responsible for defining eSIM specifications. The main SGP specifications are: SGP.02 (M2M remote provisioning), SGP.22 (consumer eSIM for smartphones), and SGP.31/SGP.32 (IoT-specific eSIM architecture and technical specification). These define how eUICC profiles are provisioned and managed across different device categories.

What is eIM in SGP.32?

The eIM (eSIM IoT Remote Manager) is the central server-side component introduced by SGP.32. It orchestrates all profile lifecycle operations — download, enable, disable, delete — across an IoT device fleet. It replaces the human user from SGP.22 and the operator-locked SM-SR from SGP.02. The eIM is portable, meaning enterprises can change eIM providers without replacing hardware, and it uses cryptographic authentication for every profile operation.

Is SGP.32 backward compatible with SGP.02?

No. SGP.32 is not backward compatible with SGP.02. Existing SGP.02 fleets cannot be migrated to SGP.32 — they would need new eUICC hardware. However, SGP.32 reuses the SM-DP+ from SGP.22, and the eIM can communicate with existing SM-DP+ infrastructure.

What is the difference between IPAd and IPAe?

IPAd is the IoT Profile Assistant running on the IoT device itself (in firmware). IPAe is the IoT Profile Assistant embedded within the eUICC. IPAe is often preferred for IoT because it requires no firmware changes to the device — the profile management logic resides on the SIM, and the device only needs to support standard BIP/STK functions.

Is SGP.32 relevant in the UK?

Yes. The UK’s multi-operator environment, ongoing 2G/3G network sunsets, and long-lifecycle infrastructure projects in energy, utilities, EV charging, and transport make profile flexibility highly valuable. SGP.32 directly mitigates network retirement risk and supports commercial flexibility across the UK’s competitive operator landscape.

How many profiles can an eUICC store?

This depends on the hardware memory capacity and eUICC OS. Typical implementations support between 5 and 24 profiles, though only one profile is active at a time on a single radio interface.

When will SGP.32 be widely available?

The specification and certification framework are ready. The first certified products appeared in 2025. Broad commercial deployment is expected to accelerate from H2 2026, with significant scale through 2027. Enterprises should design for SGP.32 readiness now, even if they deploy with existing solutions in the short term.

Does SGP.32 work with NB-IoT?

Yes. Unlike SGP.02 which relied on SMS transport, SGP.32 uses IP-based communication. This makes it fully compatible with NB-IoT and LTE-M deployments where SMS support is limited or unavailable.

---

Conclusion

SGP.32 is not marketing terminology. It is a structural evolution in how IoT connectivity is provisioned and managed.

It was created because traditional M2M eSIM (SGP.02) was too heavy and operator-locked, consumer eSIM (SGP.22) was unsuitable for headless devices, IoT deployments became global and large-scale, commercial flexibility became essential, network sunsets introduced lifecycle risk, and SMS-based provisioning was incompatible with modern LPWAN technologies.

The specification introduces a clean separation of concerns: the eIM for fleet orchestration, the IPA for device-side execution, and the SM-DP+ for profile delivery. It puts control in the hands of the enterprise rather than the operator, while maintaining the strong security foundations that the eUICC platform provides.

In real-world applications, its value is clear: reduced lock-in, greater resilience, improved lifecycle management, lower operational cost, and strong security foundations.

It sits within a broader ecosystem of eUICC hardware, cellular modules, industrial routers, antennas, connectivity platforms, and cloud systems. It does not replace those components. It strengthens them by ensuring the connectivity layer can adapt over time.

The ecosystem is still maturing. Not everything is certified and interoperable today. But the specification is finalised, the first products are in market, and the direction is clear.

For any organisation serious about deploying IoT infrastructure in the coming decade, designing for SGP.32 is no longer optional. It is foundational.