What is SGP.31 and How Does it Relate to SGP.32?

If you’ve been researching IoT eSIM, you’ve probably discovered that the new GSMA standard isn’t a single specification. Instead, it consists of several closely related documents, each with a different purpose. Two of the most important are SGP.31 and SGP.32. They are often mentioned together, yet they are frequently misunderstood. SGP.31 is not an earlier version of SGP.32, nor does SGP.32 replace it. Instead, the two documents work together: one defines the architecture, while the other defines the technical implementation.

The easiest way to think about the relationship is this. SGP.31 establishes the architecture and requirements for IoT eSIM, while SGP.32 is the normative technical specification that vendors implement to achieve interoperability. Think of SGP.31 as the architectural blueprint and SGP.32 as the engineering drawings that manufacturers actually build from.

Understanding this distinction makes the rest of the GSMA IoT eSIM ecosystem much easier to follow.

In one sentence

SGP.31 defines the architecture and requirements for IoT eSIM. SGP.32 defines the technical interfaces, protocols and security mechanisms that implement that architecture. SGP.33 defines how implementations are tested for conformance.

[PLACEHOLDER: Insert SVG diagram of the SGP.31 -> SGP.32 -> SGP.33 stack]

Why are there two specifications?

The GSMA deliberately split the IoT eSIM standard into two complementary documents. Rather than creating one enormous specification covering everything from business requirements through to cryptographic message formats, the work was separated into:

• SGP.31 – eSIM IoT Architecture and Requirements
• SGP.32 – eSIM IoT Technical Specification

This approach allows the architectural principles and the normative technical details to be versioned separately, while keeping them tightly aligned. Software developers, chip manufacturers and platform vendors spend most of their time working with SGP.32. System architects, standards engineers and solution designers typically begin with SGP.31. Together they describe the complete IoT eSIM ecosystem.

Why did the GSMA split the standard?

At first glance it might seem unnecessary to have separate architecture and technical specifications. Why didn’t the GSMA simply publish one large document?

The answer is that they serve different audiences.

The architecture specification is primarily aimed at defining the overall system design, the responsibilities of each component and the functional requirements the ecosystem must satisfy. It provides a common blueprint for everyone involved in the IoT eSIM ecosystem.

The technical specification then builds on that blueprint by defining the interfaces, protocols, security mechanisms and workflows required to achieve interoperability between equipment from different vendors.

Keeping the documents separate allows the architecture to evolve without forcing every technical detail to be rewritten at the same time, while also making each specification considerably easier to understand and maintain.

Think of designing an aircraft

An analogy makes the relationship much easier to grasp, and because industrial IoT is fundamentally a systems engineering discipline rather than a construction project, aircraft design fits particularly well.

SGP.31 defines what the aircraft must achieve. It sets out the high-level goals and constraints:

• carry a given number of passengers
• fly a certain range
• use two engines
• meet safety and airworthiness regulations
• integrate navigation, hydraulics and avionics

It does not specify the exact bolt tolerances, the wiring harness layout or the firmware running inside each control unit. Those details come later.

SGP.32 defines exactly how those systems communicate. It specifies the interfaces each component exposes, the tolerances they must meet, the protocols they use to talk to one another and how different manufacturers can build compatible parts. That is the essence of the specification: several vendors can each build a component, and because they all follow the same technical rules, those components interoperate reliably.

That is precisely what SGP.32 does for IoT eSIM. It turns an architectural concept into something manufacturers can implement and certify.

What does SGP.31 actually define?

SGP.31 answers questions such as:

• What components exist within the IoT eSIM ecosystem?
• What responsibilities does each component have?
• Which systems communicate with each other?
• What security principles must be followed?
• What functional requirements must every compliant implementation satisfy?

It deliberately avoids defining the low-level protocols, message formats and implementation procedures that are covered by SGP.32. Instead, the architecture document establishes the overall design for remote provisioning of eUICCs in network-constrained and user-interface-constrained IoT devices.

The architecture introduced by SGP.31

One of SGP.31’s biggest contributions was defining an IoT-specific architecture built on the existing consumer eSIM framework, but redesigned for unattended, network-constrained devices. Rather than adapting the smartphone model wholesale, it recognised that industrial devices have completely different requirements.

Typical IoT devices may:

• have no screen
• have no keyboard
• have no camera
• have no user present
• operate on NB-IoT or LTE-M
• sleep for long periods
• remain deployed in the field for well over a decade

Traditional consumer eSIM workflows simply don’t fit that environment.

The most significant additions the architecture introduces are:

• eIM (eSIM IoT Remote Manager)
• IPA (IoT Profile Assistant)

SGP.31 also defines how these interact with existing GSMA components such as the eUICC and SM-DP+, creating an architecture specifically suited to industrial IoT deployments. In other words, the eIM and IPA are genuinely new, while the eUICC and SM-DP+ are reused from the consumer world and given new, optimised roles.

The architecture document also describes how these components relate to one another without pinning down every protocol in detail.

[PLACEHOLDER: Insert SVG diagram showing eIM, IPA, eUICC and SM-DP+ relationships]

What does SGP.32 define?

SGP.32 is the normative technical specification. It defines the interfaces, protocols, security mechanisms, message formats and workflows that every compliant implementation must follow to achieve interoperability.

In practice, the technical specification covers:

• message formats
• security procedures and cryptography
• protocol behaviour
• interface definitions
• state machines
• profile download and lifecycle procedures
• authentication methods
• error handling

These are the documents that software engineers actually implement. Without SGP.32, every vendor would interpret the architecture differently and interoperability would quickly disappear. The purpose of the technical specification is to ensure that an eUICC from one manufacturer can work with an eIM from another and an SM-DP+ from a third.

A simple comparison

Both documents are normative. The distinction is one of abstraction, not of authority.

A worked example

Imagine the architecture states:

“The eIM shall remotely instruct an IoT device to download a new operator profile.”

That is an architectural requirement. It tells you what must be possible, but not how.

The technical specification then answers questions like:

• Which server initiates communication?
• Which protocol is used?
• Which certificates are exchanged?
• Which messages are encrypted?
• How are failures reported?
• How is the profile activated?
• What happens if power fails halfway through?
• How is integrity verified?

Those implementation details belong entirely to SGP.32.

Why not simply extend SGP.22?

One question often asked is why the GSMA didn’t just update the consumer eSIM specification, SGP.22.

The answer lies in the interaction model. Consumer eSIM assumes there is always someone holding the device. A user scans a QR code, presses download, accepts prompts and confirms installation. Industrial IoT devices rarely have any of those capabilities.

Instead, the architecture introduces a server-managed model where profile changes can be initiated remotely by the eSIM IoT Remote Manager (eIM), allowing fleets of unattended devices to be managed without human interaction. The technical specification then defines the detailed protocols that make that architecture work, including support for lightweight transports suited to constrained IoT networks.

This is also why the IoT model replaces the smartphone’s Local Profile Assistant (LPA) with the IPA. The IPA is conceptually derived from the LPA but refactored for IoT, and it comes in two deployment models, IPAd and IPAe. Both are described architecturally in SGP.31 before being fully specified in SGP.32.

Does SGP.32 replace SGP.31?

No. This is probably the biggest misunderstanding.

They are not successive versions of the same specification. SGP.31 remains the architecture and requirements document. SGP.32 remains the technical implementation specification. Every compliant SGP.32 implementation is built upon the architectural principles defined in SGP.31.

How the standards fit together

The wider GSMA ecosystem becomes much easier to understand once you see the relationships between the three documents.

SGP.31
Architecture and Requirements
        │
        ▼
SGP.32
Normative Technical Specification
        │
        ▼
SGP.33
Conformance Test Specifications

In plain terms:

• SGP.31 says what should exist.
• SGP.32 says how it must behave.
• SGP.33 verifies that vendors have implemented it correctly.

It is worth stressing that SGP.32 is a technical realisation of the SGP.31 architecture, not merely “the next document in the list.” SGP.33 is itself a set of conformance and test specifications, published in multiple parts, but for most readers the simplified view above is enough.

[PLACEHOLDER: Insert SVG diagram of the three-tier standards stack with brief captions]

Why this matters for buyers

Most organisations purchasing IoT connectivity will never read either specification. However, understanding the distinction helps when evaluating suppliers.

Most organisations deploying IoT connectivity will never read either document. If you purchase an SGP.32-compliant platform, your supplier has already implemented the technical requirements defined by SGP.32, which themselves are based on the architectural principles established by SGP.31. In other words, SGP.31 matters because it shaped the design, even if SGP.32 is the specification vendors actually implement.

So when a vendor says “we support SGP.32,” they are usually referring to their technical implementation. Behind that implementation sits the architectural model defined by SGP.31. Likewise, when discussing eIM platforms, IPA implementations or remote profile orchestration, many of the concepts originate in the architecture document even though the interoperable behaviour is governed by the technical specification.

Frequently Asked Questions

Is SGP.31 older than SGP.32?

Yes. SGP.31 was published first because the architecture had to be defined before the technical implementation could be specified. The two documents now evolve together through aligned version updates.

Do manufacturers need both specifications?

Yes. SGP.31 provides the architectural framework, while SGP.32 provides the detailed technical requirements needed to build interoperable products.

Does SGP.31 contain protocols?

Not in detail. It identifies the architecture, interfaces and functional requirements. The protocol definitions, message structures and security procedures are contained within SGP.32.

Which specification should most people read?

For anyone trying to understand how IoT eSIM works conceptually, SGP.31 provides the architectural overview. For software developers, silicon vendors, eUICC manufacturers and platform providers implementing the standard, SGP.32 is the essential technical reference.

Final thoughts

The easiest way to remember the relationship is this:

SGP.31 asks, “What does an IoT eSIM ecosystem need to achieve?” SGP.32 answers, “Exactly how should every compliant implementation achieve it?”

Together they form the foundation of the GSMA’s IoT eSIM architecture. SGP.31 provides the architectural blueprint and functional requirements, while SGP.32 defines the protocols, interfaces and security mechanisms that allow eUICCs, eIM platforms and network operators to interoperate reliably. They are complementary documents, not competing standards, and understanding how they relate makes the wider SGP.31/32 IoT eSIM ecosystem much easier to navigate.

WordPress tags: SGP.31, SGP.32, SGP.33, IoT eSIM, GSMA, eUICC, eIM, IPA, SM-DP+, remote SIM provisioning, eSIM architecture, IoT connectivity, NB-IoT, LTE-M, eSIM standards