Comprehensive technical knowledge base covering 12 GSMA eSIM specifications. 84+ articles on Remote SIM Provisioning — SGP.02, SGP.22, SGP.32, SGP.41, SGP.29, SGP.23, SGP.25, SGP.26 and more.
You’ve built Mission Control. It works in the simulator. But before you can command a real robot fleet, you need a license. You go to an independent testing agency, they run every drill in the book, and if you pass: you get certified. Now operators trust you with their robots.
That’s the certification journey for an eIM product. Passing SGP.33-3 test cases is the gateway from a lab prototype to a production-ready remote management server.
IoT eSIM isn’t a single-vendor world. A real deployment might have:
All these pieces come from different companies, but they must work together flawlessly. Certification gives everyone confidence that each piece holds up its end of the bargain.
Here’s what a real IoT eSIM deployment looks like: way more complex than consumer eSIM:
Operator (mobile company)
│
▼
┌──────────┐ ┌──────────┐
│ SM-DP+ │◄──►│ SM-DS │
│(Key Maker)│ │(Post Office)│
└────┬─────┘ └────┬─────┘
│ES9+' │ES11'
▼ ▼
┌─────────────────────────┐
│ eIM │ ← THIS is what SGP.33-3 certifies
│ (Mission Control) │
└────────────┬────────────┘
│ESipa
┌───────┴───────┐
▼ ▼
┌─────────┐ ┌─────────┐
│ IPA │ │ IPA │ ← Many robot devices
│(Device 1)│ │(Device 2)│
└────┬────┘ └────┬────┘
│ │
▼ ▼
┌─────────┐ ┌─────────┐
│ eUICC │ │ eUICC │
└─────────┘ └─────────┘
One eIM might manage thousands of robots, each with different eUICCs and IPAs from different vendors. That’s why certification is non-negotiable.
Before testing begins, the eIM vendor prepares:
| Feature | Question |
|---|---|
| O_S_TRID | Does the eIM send Transaction IDs with packages? |
| O_S_PKG_RETRIEVAL | Does the eIM support Package Retrieval mode? |
| O_S_ESIPA_HTTPS | Does the eIM use TLS on ESipa? |
The accredited lab sets up the General Test Environment with all four simulators and runs every applicable test:
Each test gets a verdict: Pass, Fail, or Inconclusive. Failed tests can be retried after fixes. Once all mandatory and applicable conditional tests pass, the product proceeds to certification.
Testing protocol behaviour is one thing. But the GSMA Security Accreditation Scheme (SAS) goes further:
An eIM must prove:
SGP.33-3 test cases indirectly verify SAS-relevant properties: TLS configuration, certificate validation, anti-replay mechanisms: but the full SAS audit is a separate process run by GSMA-accredited auditors.
Not everything is ready for certification yet:
| Interface | Status | Certification Ready? |
|---|---|---|
| ES9+’ (eIM→SM-DP+) | Fully defined ✅ | Ready: adapted from proven consumer tests |
| ES11’ (eIM→SM-DS) | Fully defined ✅ | Ready: adapted from proven consumer tests |
| ESep (eIM→eUICC) | Partially defined ⚠️ | Limited: most PSMO sequences still FFS |
| ESipa (eIM→IPA) | Requirements only ⚠️ | Not certifiable: all sequences FFS |
| Behaviour (Profile Enable) | One test case ⚠️ | Conditional only |
For today’s eIM vendors, the practical strategy is: certify ES9+’ and ES11’ first, conduct bilateral interoperability testing for ESipa/ESep, and track the specification as it evolves.
SGP.33-3 tests the eIM in isolation. But production deployment needs end-to-end testing with real eUICCs, IPAs, and servers: an area still marked “For Future Study” in the broader GSMA testing framework.
For now, vendors fill this gap with:
The certification path is still being paved: but the foundation (ES9+’ and ES11’ testing) is solid.
SGP.33-3 connects to at least five other GSMA documents: SGP.33-1 (IPA testing), SGP.33-2 (SM-DP+ testing), SGP.23 (consumer testing), SGP.26 (test certificates), and the GlobalPlatform DLOA framework. No specification is an island!
Kid-friendly version of GSMA SGP.33-3: eUICC IoT Manager Test Specification, Certification Path