Consumer eSIM vs IoT eSIM: SGP.22, SGP.32 and Other GSMA Architectures Explained

An eSIM in a traveller's smartphone and an eSIM in a remotely deployed electricity meter can both store downloadable mobile operator profiles. They do not necessarily use the same provisioning architecture or operational model.

Consumer eSIM was designed around devices with screens, operating systems, internet access and people available to approve installation. IoT deployments may involve thousands of unattended devices with limited power, intermittent connectivity, no camera and no practical way to scan a QR code.

The GSMA has therefore developed different remote SIM provisioning architectures for different environments:

• SGP.01 and SGP.02 define the established M2M architecture;
• SGP.21 and SGP.22 define the consumer architecture used widely by smartphones and other consumer devices;
• SGP.31 and SGP.32 define the newer IoT architecture for network-constrained or user-interface-constrained devices;
• SGP.41 defines architecture and requirements for in-factory profile provisioning, or IFPP.

The numbers matter, but they should not become the starting point for a commercial decision. The correct architecture depends on the device, deployment model, available connectivity, degree of user involvement, expected lifetime and party responsible for managing profiles.

Key takeaways

• Consumer, M2M and IoT eSIM architectures solve different operational problems. They are not simply different names for the same workflow.
• SGP.21 describes consumer eSIM architecture and requirements. SGP.22 provides the corresponding technical specification.
• SGP.31 describes the newer eSIM IoT architecture and requirements. SGP.32 provides its technical implementation specification.
• Consumer eSIM commonly uses an SM-DP+, a Local Profile Assistant and optionally an SM-DS. The user or device typically participates directly in profile download.
• The SGP.31/32 IoT architecture adds an IoT Profile Assistant and an eSIM IoT Remote Manager to support devices without a suitable local user interface and devices with constrained connectivity.
• The IoT architecture can use SM-DP+ infrastructure, but this does not mean that every consumer eSIM service is automatically suitable for SGP.32 fleets.
• The established M2M architecture uses components such as the SM-DP and SM-SR and is strongly server-driven. It remains relevant to existing automotive and industrial deployments.
• SGP.32 does not remotely upgrade every deployed M2M or consumer device. Support must exist across the eUICC, device software, connectivity path and management systems.
• A fleet may need to support more than one architecture during a long migration period.
• The best commercial platform separates profile provisioning, network connectivity and fleet lifecycle management instead of treating them as one feature called “eSIM”.

Why does eSIM need more than one architecture?

Remote SIM provisioning must work within the realities of the target device.

A smartphone normally has:

• a screen and settings menu;
• a user who can provide consent;
• Wi-Fi or another internet connection;
• an operating system with an eSIM interface;
• enough power and processing capability for an interactive installation;
• a camera, application or link handler.

A connected sensor may have none of those features. It may be installed underground, inside a sealed machine or across several countries. It may wake only periodically, communicate over a constrained radio technology and need to operate for ten years without manual attention.

An automotive manufacturer has another set of requirements. Vehicles may be produced in one country, shipped globally, assigned to different service providers and expected to support emergency calling, diagnostics and connected services throughout a long lifecycle.

One architecture cannot optimise equally for all of these conditions.

The GSMA specifications at a glance

This table is intentionally simplified. Each specification contains detailed roles, interfaces, security procedures and lifecycle functions. Businesses should confirm the applicable version and implementation with their eUICC, device, connectivity and platform suppliers.

What do the GSMA document numbers mean?

GSMA eSIM standards are divided into related documents.

Architecture and requirements documents

These describe the roles, use cases, principles and requirements for an architecture.

• SGP.01 covers the M2M architecture and requirements.
• SGP.21 covers the consumer architecture and requirements.
• SGP.31 covers the IoT architecture and requirements.
• SGP.41 covers in-factory profile provisioning architecture and requirements.

Technical specifications

These define the detailed technical procedures, interfaces, messages and security functions needed for interoperable implementations.

• SGP.02 is the technical specification for the M2M architecture.
• SGP.22 is the technical specification for consumer remote SIM provisioning.
• SGP.32 is the technical specification for the eSIM IoT architecture.

The shorthand “SGP.22 eSIM” or “SGP.32 eSIM” is convenient, but neither number describes a different physical SIM format. The documents describe remote provisioning architectures and technical behaviour around a compatible eUICC and profile ecosystem.

How the consumer eSIM architecture works

The consumer architecture is the model most familiar to smartphone users. A customer buys a plan and adds it through device settings, a QR code, a carrier application, a notification, an activation link or an operating-system-supported transfer process.

SGP.21 defines the architecture and requirements. SGP.22 provides the technical specification.

Main consumer components

eUICC

The eUICC is the protected component that stores and manages operator profiles. It may store several profiles, although device design determines how many can be enabled simultaneously.

eSIM profile

The profile contains the operator subscription and protected credentials required for network authentication and service configuration.

SM-DP+

The Subscription Manager Data Preparation Plus prepares, protects and delivers profiles to eligible consumer devices.

Local Profile Assistant

The Local Profile Assistant, or LPA, operates on the device side. It supports profile download and management and mediates between the SM-DP+ and the eUICC.

On a smartphone, the LPA is normally integrated with the operating system's cellular settings and secure eSIM functions. The user may see a branded application or storefront, but protected profile operations remain controlled through the device platform.

SM-DS

The optional Subscription Manager Discovery Service can help a device discover that a profile is available. It enables journeys that do not rely entirely on manually entering an SM-DP+ address or scanning a conventional QR code.

A typical consumer provisioning flow

1. The customer buys or requests a mobile plan.
2. The operator or provider prepares or allocates a profile through the SM-DP+.
3. The device receives activation information or discovers the available profile.
4. The user approves installation where required.
5. The LPA establishes the required interaction with the SM-DP+.
6. The profile is securely downloaded and installed on the eUICC.
7. The user or system enables the profile.
8. The modem uses it to register with a permitted network.

The consumer architecture works well when a user can resolve prompts, confirm consent, select the appropriate line and provide internet connectivity for profile download.

Where consumer eSIM fits best

• travel eSIM for smartphones;
• primary mobile subscriptions;
• tablets and laptops with a suitable eSIM interface;
• smartwatches paired with a consumer account;
• applications in which the device owner actively chooses a provider;
• lower-volume equipment that has an accessible interface and can be individually managed.

Strengths of the consumer architecture

• mature support across many smartphones and operating systems;
• familiar QR-code and digital activation journeys;
• customer choice and consent are built into the operating model;
• common SM-DP+ ecosystem;
• direct retail and application-led distribution;
• support for multiple stored subscriptions on compatible devices.

Limitations for IoT fleets

The consumer model can become difficult when devices are unattended or lack a suitable user interface.

A fleet operator may not be able to:

• scan one QR code per device;
• approve a prompt on every screen;
• keep every device continuously connected during provisioning;
• recover a device physically after a failed download;
• depend on a consumer operating-system interface;
• coordinate thousands of profile changes manually.

This does not mean consumer architecture can never be used in an IoT-like device. A router with a screen, web interface and manageable fleet size may be able to use it. The operational test is more important than the product label.

How the established M2M eSIM architecture works

The M2M architecture was designed for remotely managed devices, particularly in automotive and industrial environments. Its principal GSMA documents are SGP.01 and SGP.02.

Unlike the consumer model, it does not assume that an end user will choose a plan and interact with an LPA on the device.

Main M2M components

SM-DP

The Subscription Manager Data Preparation function prepares and protects operator profiles for delivery.

SM-SR

The Subscription Manager Secure Routing function manages secure communication with the eUICC and supports remote profile lifecycle operations.

M2M eUICC

The eUICC supports the relevant M2M remote provisioning procedures and receives commands through the architecture.

General M2M operating model

The architecture is strongly server-driven. Management systems initiate profile download, enablement, disablement and deletion without depending on a consumer standing next to the device.

This suits equipment that is installed remotely and controlled through enterprise agreements. It has supported important connected-car and industrial deployments for many years.

Strengths of the M2M architecture

• designed for centrally controlled devices;
• does not require a consumer user interface;
• established in long-lived automotive and industrial programmes;
• supports remote lifecycle management;
• fits tightly governed enterprise supply chains.

Operational challenges

The SM-SR plays a central role in the M2M model. Commercial and technical relationships around that component can make changes across providers more complex than buyers initially expect.

Challenges may include:

• integration complexity across several parties;
• long onboarding and certification programmes;
• dependency on the selected subscription-management chain;
• complicated ownership and migration arrangements;
• limited suitability for smaller or more flexible deployments;
• commercial friction when changing connectivity suppliers.

The established M2M architecture remains valid for deployments designed around it. A new IoT project should nevertheless compare it with SGP.31/32 rather than assuming that “M2M eSIM” is the only remotely managed option.

How the SGP.31/32 IoT architecture works

The GSMA developed the newer IoT architecture for eUICCs in network-constrained and/or user-interface-constrained IoT devices.

SGP.31 defines the architecture and requirements. SGP.32 provides the technical description of remote provisioning and management, the eUICC architecture, interfaces and security functions.

The design combines useful principles from earlier architectures:

• remote management suited to fleets;
• the ability to use SM-DP+ infrastructure from the consumer ecosystem;
• device-side functions adapted to constrained IoT equipment;
• management without requiring a person to operate a local screen.

Main IoT components

SM-DP+

The IoT architecture uses an SM-DP+ for profile preparation and delivery. This can reduce the need for an entirely separate profile-preparation ecosystem.

It does not mean that any SM-DP+ integration automatically provides a complete SGP.32 service. The IoT device, eUICC, management roles, interfaces and security procedures must support the relevant architecture.

IoT Profile Assistant

The IoT Profile Assistant, or IPA, provides device-side assistance for profile operations in the IoT architecture.

The function can be implemented in different locations:

• IPAd, where the IPA is implemented in the IoT device;
• IPAe, where the IPA is implemented in the eUICC.

The appropriate option depends on device resources, software control, eUICC implementation and deployment design.

eSIM IoT Remote Manager

The eSIM IoT Remote Manager, or eIM, supports remote management interactions with IoT devices and their IPAs.

The eIM enables an authorised fleet-management process to trigger and coordinate profile lifecycle operations without requiring a user to scan a QR code on each device. Its signed packages can support profile-download triggers, profile-state management operations, eIM configuration operations, requests for IPA or eUICC data and acknowledgements.

The eIM should not be confused with an SM-DP+. The eIM assists remote orchestration and management, while the SM-DP+ prepares and delivers profiles.

An eIM is central to remotely orchestrated fleet operations, but not every SGP.32 profile download has to start with an eIM instruction. The specification also supports IPA-initiated procedures, including use of configured SM-DP+ information and discovery mechanisms where implemented.

IoT eUICC

The eUICC must support the applicable IoT architecture and technical procedures. A device containing an embedded secure element is not automatically SGP.32-compatible.

A simplified remotely managed SGP.32 workflow

1. An enterprise or IoT service process identifies a device that requires a profile operation.
2. The authorised management environment uses an eIM to communicate the required action.
3. The device's IPA participates in the procedure.
4. The profile is obtained from an SM-DP+ through a supported direct or indirect download procedure.
5. The profile is installed and managed on the IoT eUICC.
6. The device uses the selected profile to connect under the applicable network and service policies.

In a direct download, the IPA communicates with the SM-DP+. In an indirect download, the eIM participates in obtaining and transferring the protected profile package through the defined interfaces. SGP.32 also includes discovery, profile rollback, fallback-profile and error-handling mechanisms.

The exact sequence depends on the use case, available connectivity, IPA implementation and technical configuration. The business value is that the operation can be managed at fleet level without a consumer-style interface on every device.

What does “constrained IoT device” mean?

Constraint can refer to more than physical size.

User-interface constraint

The device may have:

• no display;
• no keyboard or touchscreen;
• no camera for a QR code;
• no local operator;
• a sealed or inaccessible enclosure.

Network constraint

The device may have:

• intermittent connectivity;
• limited bandwidth;
• high latency;
• restricted protocols;
• long sleep intervals;
• low-power wide-area connectivity;
• coverage only at certain points in its operating cycle.

Resource constraint

The device may also have limited:

• processing capacity;
• memory;
• power budget;
• application complexity;
• opportunities for firmware updates.

Not every constrained device has all these characteristics. The architecture must be evaluated against the actual hardware and operating conditions.

Consumer SGP.22 vs IoT SGP.32

The table does not decide every edge case. Some routers behave like consumer devices. Some industrial equipment has a powerful operating system and local interface. Some wearables are managed through a paired phone rather than directly.

Architecture selection should follow the actual lifecycle, not a marketing category.

SGP.32 vs the established M2M architecture

SGP.32 is often described as the successor to the earlier M2M model. That description is useful directionally but can be misleading operationally.

Existing M2M deployments will not disappear immediately. Vehicles, meters and industrial devices may remain active for ten years or longer. Their eUICCs and software were designed for SGP.01/02 and cannot necessarily be converted remotely to another architecture.

Key differences

What SGP.32 can improve

For suitable new deployments, the architecture can offer:

• a more scalable path for constrained IoT equipment;
• reduced dependence on consumer interaction;
• use of the broader SM-DP+ ecosystem;
• fleet-level orchestration through eIM functions;
• greater flexibility in designing connectivity supply chains;
• improved alignment between device makers, IoT service providers and connectivity providers.

These are architectural opportunities, not guaranteed commercial outcomes. Contract design, implementation quality, interoperability and exit rights remain critical.

What is in-factory profile provisioning?

Some devices need a suitable profile during manufacturing, testing or initial distribution. The GSMA's SGP.41 defines architecture and requirements for in-factory profile provisioning, or IFPP.

IFPP addresses a different stage from ordinary in-field profile management. It can help manufacturers provision connectivity during production rather than inserting a separately personalised SIM card or requiring the finished device to complete its first profile download only after deployment.

Potential benefits include:

• simplified manufacturing variants;
• automated profile assignment during production;
• earlier connectivity testing;
• reduced physical SIM handling;
• support for devices that need connectivity immediately after power-on.

In-factory provisioning should not be treated as the entire lifetime strategy. The device may still need remote profile and connectivity management after it leaves the factory.

Choosing an architecture by use case

Travel eSIM for smartphones

Likely choice: consumer architecture.

The customer has a compatible phone, can approve installation and can use a QR code, activation link or application. The commercial priorities are immediate fulfilment, clear instructions, coverage, pricing and support.

Employee smartphones managed by an enterprise

Likely choice: consumer architecture combined with enterprise device management and carrier processes.

The phones remain consumer-class devices even if purchased and administered by a business. Enterprise controls do not automatically turn them into SGP.32 IoT devices.

Managed routers

Possible choice: consumer or IoT architecture, depending on the router.

A router with a web interface and accessible installation process may use consumer eSIM. A large unattended fleet may benefit from an IoT architecture. Buyers must check exact modem, eUICC, firmware and management support rather than accepting “eSIM-ready” as sufficient.

Vehicle telematics

Possible choice: established M2M for existing programmes, SGP.32 for suitable new designs.

Automotive programmes have long lifecycles, safety requirements and complex supplier chains. Migration requires careful hardware and platform planning.

Smart meters and environmental sensors

Likely choice for new constrained designs: IoT architecture.

These devices may lack screens, operate on limited power and remain deployed for years. Fleet-level remote management is more appropriate than individual QR-code installation.

Payment terminals and kiosks

Possible choice: consumer or IoT architecture.

The decision depends on whether the terminal can expose a controlled local interface, whether field staff are available and how many devices require coordinated profile changes.

Factory-connected equipment

Possible choice: IFPP for initial provisioning combined with M2M or IoT lifecycle management.

The factory process can establish initial connectivity, while the deployed architecture governs later changes.

Questions to answer before selecting SGP.22 or SGP.32

1. Does the device have a usable local interface?
2. Will a person be present during initial provisioning?
3. Can the device scan, open or receive consumer activation information?
4. Is reliable internet access available before the new profile is installed?
5. How many devices must be managed?
6. Will profile changes be individual or fleet-wide?
7. How long will the devices remain in service?
8. Can the device firmware and eUICC support the required architecture?
9. Is the IPA implemented in the device or eUICC?
10. Who will operate or supply the eIM?
11. Which SM-DP+ platforms and profile providers are compatible?
12. What bootstrap or fallback connectivity is available?
13. What happens if a profile download is interrupted?
14. Can the device recover without physical access?
15. Which party is authorised to order and approve profile changes?
16. How will the fleet migrate to another connectivity provider?
17. Which certificates, compliance processes and production controls apply?
18. Which lifecycle events can the management platform actually observe?

Why bootstrap connectivity matters

Remote profile download requires a communication path. A new profile cannot help the device contact a provisioning service until it has been downloaded.

An IoT design therefore needs an initial connectivity strategy. Depending on the implementation, this may involve:

• an initial or bootstrap profile;
• factory or local connectivity;
• Wi-Fi or wired access;
• another active profile;
• a controlled commissioning network;
• connectivity provided through the device's deployment process.

The bootstrap arrangement must be assessed for coverage, cost, lifetime and supplier dependency. A profile that expires too early or works only in the manufacturing country may prevent later provisioning.

Resilience also matters. If the target profile fails to download or connect, the device may need to retain a working fallback path so that another operation can be attempted.

Device compatibility requires more than an eSIM logo

An “eSIM-capable” device may support only a particular architecture or workflow.

For a reliable deployment, verify:

• eUICC hardware and operating-system support;
• supported GSMA architecture and specification version;
• LPA or IPA implementation;
• eIM compatibility where required;
• SM-DP+ interoperability;
• modem and radio-band support;
• bootstrap and fallback behaviour;
• remote firmware update capability;
• profile storage and enablement limits;
• error recovery after power or network interruption;
• compliance and certification evidence.

A consumer eSIM router that accepts a QR code is not automatically an SGP.32 router. An embedded eUICC is not automatically manageable through every remote provisioning service.

Operational requirements for an IoT eSIM platform

Profile download is only one part of IoT fleet management.

A practical platform may need to provide:

• device and eUICC inventory;
• mapping between device, EID, profile, ICCID and customer asset;
• bulk operations with approval controls;
• scheduling and staged rollouts;
• status, retries and failure categorisation;
• connectivity policy and network visibility;
• usage monitoring and alerts;
• suspension and reactivation;
• audit history;
• access roles for customer organisations;
• API and webhook integration;
• bootstrap and fallback management;
• secure supplier handover and exit procedures.

The system should distinguish profile state from network state. “Profile enabled” does not prove that a sensor has attached to a network, reached its application endpoint or delivered usable data.

Commercial and contractual questions

Architecture decisions create long-term commercial dependencies.

Contracts should clarify:

• ownership of eUICCs, profiles and identifiers;
• control of the eIM, SM-DP+, SM-SR or related management accounts;
• rights to move profiles or devices to another provider;
• responsibility for bootstrap connectivity;
• service levels for provisioning operations;
• support for deployed specification versions;
• certificate renewal and lifecycle responsibilities;
• data access and retention;
• incident escalation;
• costs for downloads, swaps, enablement, storage and API use;
• treatment of devices after contract termination.

The lowest price per megabyte can become irrelevant if the fleet cannot change provider or recover from a failed profile transition.

Migration and coexistence

Large organisations should expect architecture coexistence.

A company may simultaneously operate:

• older automotive devices using SGP.01/02;
• smartphones using SGP.21/22;
• new sensors designed for SGP.31/32;
• factory-provisioned devices entering service through IFPP.

Replacing every device at once is rarely economic. The management layer should therefore maintain a clear inventory of architecture, eUICC capability, profile provider and available lifecycle operations for each device population.

A sensible migration approach

1. Segment the installed base by device, modem, eUICC and architecture.
2. Identify which devices can support a new provisioning method and which require replacement.
3. Define future-device requirements using the target GSMA architecture explicitly.
4. Test interoperability with the actual eUICC, IPA, eIM and SM-DP+ combination.
5. Validate bootstrap, rollback and loss-of-connectivity scenarios.
6. Run a controlled pilot across representative countries and networks.
7. Migrate in stages with measurable success criteria.
8. Retain an operational path for legacy devices throughout their remaining lifecycle.

Architecture migration should never begin with a bulk profile switch and no tested recovery route.

Common misconceptions

“All eSIMs work with SGP.22 and SGP.32”

No. Compatibility depends on the eUICC, device software, provisioning components and supported architecture.

“SGP.32 is just consumer eSIM without a screen”

No. It introduces an IoT-specific management model with the IPA and eIM to address constrained devices and fleet operations.

“SGP.32 replaces every M2M eSIM immediately”

No. Existing M2M devices may remain operational for many years and may not be upgradeable to the new architecture.

“Using an SM-DP+ means the whole solution supports SGP.32”

No. The SM-DP+ is one part of the architecture. The device, eUICC, IPA, eIM and interfaces must also support the required procedures.

“IoT eSIM automatically provides multi-network coverage”

No. Remote provisioning changes how profiles are managed. Network access still depends on the commercial profile, operator and roaming agreements.

“A fleet can always change provider remotely”

Only if the complete technical and contractual design permits it. Bootstrap connectivity, authorisation, management ownership, compatible profiles and recovery procedures all matter.

“Every router should use SGP.32”

Not necessarily. A user-managed router may work well with consumer architecture. The correct choice depends on fleet scale, accessibility and lifecycle.

How SIM24.biz fits into the architecture decision

SIM24.biz supports businesses building branded consumer, physical SIM and IoT connectivity propositions.

The commercial starting point should be the product and device lifecycle, not a specification number selected in isolation. A travel brand serving smartphones has different provisioning requirements from a manufacturer deploying sealed trackers across several countries.

SIM24.biz can help a partner structure the required connectivity, platform and operational model. The exact support for a GSMA architecture, eUICC type, provisioning component or remote lifecycle function must be confirmed for the selected implementation and supplier combination. At the time of this draft, no public claim is made that SIM24.biz itself operates an eIM, SM-DP+, SM-SR or certified SGP.32 platform.

This distinction protects both sides. It avoids promising that a consumer QR-code product provides full IoT fleet management, or that an IoT eUICC can use any profile platform without compatibility work.

Conclusion

Consumer eSIM and IoT eSIM use the same broad idea: mobile operator profiles can be securely provisioned to a compatible eUICC. Their operating environments are fundamentally different.

The SGP.21/22 consumer architecture assumes a device capable of participating in an interactive profile-acquisition process. It uses components such as the SM-DP+, LPA and optional SM-DS and is well suited to smartphones, tablets and user-operated devices.

The SGP.31/32 IoT architecture is designed for devices constrained by connectivity, user interface or both. It introduces the IPA and eIM to enable remote fleet-oriented management while using SM-DP+ profile infrastructure.

The SGP.01/02 M2M architecture remains important across established automotive and industrial deployments. SGP.41 adds a separate option for provisioning profiles during manufacturing.

None of these standards eliminates the need for device testing, bootstrap connectivity, network agreements, fleet operations or clear supplier contracts. The right architecture is the one that can provision, connect, recover and migrate the actual device population throughout its intended lifetime.

Frequently asked questions

What is the main difference between SGP.22 and SGP.32?

SGP.22 is the technical specification for the consumer eSIM architecture, commonly used by interactive devices such as smartphones. SGP.32 is the technical specification for the IoT architecture designed for network-constrained or user-interface-constrained IoT devices and fleet management.

What is the difference between SGP.21 and SGP.22?

SGP.21 defines the consumer architecture and requirements. SGP.22 provides the detailed technical specification implementing that architecture.

What is the difference between SGP.31 and SGP.32?

SGP.31 defines architecture and requirements for eSIM provisioning in constrained IoT devices. SGP.32 specifies the detailed technical procedures, interfaces, eUICC architecture and security functions.

What are an IPA and an eIM?

The IoT Profile Assistant is the device-side function supporting profile operations in the SGP.31/32 architecture. It may reside in the device as an IPAd or in the eUICC as an IPAe. The eSIM IoT Remote Manager supports authorised remote management interactions with the IPA.

Does SGP.32 use an SM-DP+?

Yes. The IoT architecture uses an SM-DP+ for profile preparation and delivery. A complete solution still requires compatible IoT device, eUICC, IPA, eIM and management interfaces.

Is SGP.32 better than SGP.22?

It is better suited to certain IoT environments, not universally better. A smartphone travel eSIM normally fits consumer architecture. An unattended sensor fleet may fit SGP.32.

Does SGP.32 replace SGP.01 and SGP.02?

It provides a newer architecture for suitable IoT deployments, but existing M2M devices and platforms will coexist for years. Migration depends on hardware, software, contracts and device replacement cycles.

Can an existing consumer eSIM device be upgraded to SGP.32?

Not automatically. The device, eUICC and software must support the IoT architecture. A firmware update alone may not be sufficient.

Can SGP.32 switch a device between mobile operators?

It supports remote profile provisioning and management, which can enable operator changes when compatible profiles, authorisations, connectivity and commercial arrangements exist. It does not override device, contract or network restrictions.

Is SGP.32 required for every IoT deployment?

No. Some accessible routers or terminals may use consumer eSIM successfully. Existing industrial deployments may use the M2M architecture. The decision depends on the actual operational model.

What is SGP.41?

SGP.41 defines architecture and requirements for in-factory profile provisioning. It addresses profile delivery during device manufacturing and complements rather than replaces in-field lifecycle management.

Choose an eSIM architecture that fits the whole device lifecycle

SIM24.biz helps businesses design branded consumer and IoT connectivity propositions around real devices, operating conditions and management requirements.

Talk to SIM24.biz about the appropriate provisioning and connectivity model for your product or fleet.

Sources

1. GSMA, “eSIM Consumer and IoT Specifications”: https://www.gsma.com/solutions-and-impact/technologies/esim/esim-specification/
2. GSMA, “A Guide to eSIM Architectures”: https://www.gsma.com/solutions-and-impact/technologies/esim/gsma_resources/a-guide-to-esim-architectures/
3. GSMA, “SGP.21 v2.6, eSIM Consumer Architecture and Requirements”: https://www.gsma.com/solutions-and-impact/technologies/esim/gsma_resources/sgp-21-v2-6/
4. GSMA, “SGP.22 v2.7, eSIM Consumer Technical Specification”: https://www.gsma.com/solutions-and-impact/technologies/esim/gsma_resources/sgp-22-v2-7/
5. GSMA, “SGP.31 v1.3, eSIM IoT Architecture and Requirements”: https://www.gsma.com/solutions-and-impact/technologies/esim/gsma_resources/sgp-31-v1-3/
6. GSMA, “SGP.32 v1.3, eSIM IoT Technical Specification”: https://www.gsma.com/solutions-and-impact/technologies/esim/gsma_resources/sgp-32-v1-3/
7. GSMA, “M2M Specifications”: https://www.gsma.com/solutions-and-impact/technologies/esim/esim-m2m-specifications/
8. GSMA, “SGP.01 v4.3, Embedded SIM Remote Provisioning Architecture”: https://www.gsma.com/solutions-and-impact/technologies/esim/wp-content/uploads/2022/11/SGP.01-v4.3-1.pdf
9. GSMA, “SGP.02 v4.3, Remote Provisioning Architecture for Embedded UICC Technical Specification”: https://www.gsma.com/solutions-and-impact/technologies/esim/gsma_resources/sgp-02-remote-provisioning-architecture-for-embedded-uicc-technical-specification-v4-3/
10. GSMA, “SGP.41 v1.0, eSIM IFPP Architecture and Requirements”: https://www.gsma.com/solutions-and-impact/technologies/esim/gsma_resources/esim-ifpp-architecture-and-requirements/
11. Android Open Source Project, “Implement eSIM”: https://source.android.com/docs/core/connect/esim-overview