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.
🏠 eUICC.tech > SGP.23 Test Specifications > The GSMA eSIM Test Infrastructure
💡 Why this matters: You can’t test an eSIM ecosystem with production SIMs and live servers: you need a parallel universe of test certificates, test keys, test profiles, and simulated servers. SGP.23’s Annexes (A through K) define this entire parallel infrastructure, enabling deterministic, repeatable conformance testing without touching a live operator network.
Key takeaways:
- Test certificates and test keys (defined in Annex A.2) create a parallel PKI isolated from production GSMA certificates
- Six test profiles (operational, provisioning) with known ICCIDs and metadata enable repeatable test scenarios
- Nine simulator types (S_Device through S_SERVER) wrap each IUT in a fully controlled test environment
- Test environments are numbered (TE_eUICC, TE_P1-P3, TE_S1-SR2) and map to specific IUT types
- Test tools must implement DER encoding/decoding, APDU handling, TLS session management, and profile package generation
- Integrated eUICCs (SoC-embedded) use USB CCID test interfaces per Annex J
Every SGP.23 test case executes within a controlled test environment: a carefully specified arrangement of the Implementation Under Test (IUT) and the simulators that surround it. This article unpacks the infrastructure that makes eSIM conformance testing possible.
SGP.23 defines a complete parallel PKI hierarchy, completely isolated from production certificates. Annex A.2 specifies:
ES9+.InitiateAuthentication mutual auth)ES10b.PrepareDownload)Test eUICCs are pre-loaded with test certificates and keys, and pre-configured with the test CI’s public key in their euiccCiPKIdListForVerification and euiccCiPKIdListForSigning lists. This means test setups don’t touch the GSMA production CI: everything runs in a sandbox.
Annex E defines the profiles used in test cases. Each has a known ICCID, known metadata, and a known profile package (per the eUICC Profile Package Specification). References follow the pattern:
PROFILE_OPERATIONAL1, PROFILE_OPERATIONAL2, … : normal consumer profilesPROFILE_PROVISIONING1 : bootstrap/connectivity profiles (out of scope in SGP.23 v1.16)PROFILE_TEST1 : profiles with known OTA keys for Device Test Mode (out of scope)Each profile’s metadata specifies: ICCID, Service Provider Name, Profile Name, Profile Class, Profile Policy Rules (PPRs), and notification addresses. By using standardised profiles, test cases can verify that an eUICC correctly parses metadata, enforces PPRs, and sends notifications to the expected addresses.
Test environments replace every real-world counterpart of the IUT with a simulator controlled by the test tool:
| Simulator | What It Replaces | When Used |
|---|---|---|
S_Device |
Phone/modem | eUICC testing: sends APDUs over ISO 7816-4 |
S_SM-DP+ |
Profile factory server | eUICC, LPAd, SM-DS testing |
S_SM-DS |
Discovery server | eUICC, LPAd, SM-DP+ testing |
S_MNO |
Mobile network operator | SM-DP+ ES2+ testing |
S_LPAd |
Device-side LPA | eUICC, SM-DP+, SM-DS testing |
S_LPAe |
eUICC-resident LPA | eUICC testing |
S_EndUser |
Human user | Device/LPAd testing (person or software) |
S_CLIENT |
HTTPS client | TLS testing on SM-DP+/SM-DS |
S_SERVER |
HTTPS server | TLS testing on SM-DP+/SM-DS |
Each simulator is the responsibility of test tool providers. They must handle DER encoding/decoding of ASN.1 structures, APDU command/response parsing, TLS session establishment, and profile package generation.
A removable eUICC (Java Card, one of the form factors from ETSI TS 102 221) connected to a PC/SC reader or custom hardware. The test system implements S_Device, S_LPAd, S_MNO, S_SM-DP+, and S_SM-DS. The eUICC is tested over its contact interface (ISO/IEC 7816-4), with ES6, ES8+, and ES10x commands tunnelled through APDUs.
The eUICC manufacturer must provide products compliant with Annex G.2 (eUICC Initial States), ensuring a known starting configuration before each test run.
For eUICCs embedded in SoCs (System-on-Chip), where there is no physical UICC terminal interface, Annex J specifies a USB CCID test interface. The integrated eUICC must operate in card reader mode and support standard PC/SC messages (PC_to_RDR_IccPowerOn, PC_to_RDR_XfrBlock, PC_to_RDR_T0APDU, etc.). If USB is unavailable, an adapter (e.g., Bluetooth-to-USB) must be provided.
The manufacturer must ensure no other SoC subsystems interfere during testing.
JSON input data is used for all SM-DP+ and SM-DS testing (ASN.1 format is out of scope for these components). TLS parameters and configurations can be defined per test case.
SM-DS testing is the most complex, with seven environments covering:
A complete Device Under Test containing a GSMA-compliant test eUICC (removable or soldered, not removed during testing). The test eUICC is pre-loaded with test certificates and is not itself under test. Simulated SM-DP+ and SM-DS servers are deployed on the network, with the test root certificate configured in the device for TLS trust.
SGP.23 uses a notation system heavily:
#NAME_OF_CONSTANT : Fixed values defined in Annex A (e.g., #TEST_DP_ADDRESS1, #MATCHING_ID_1, #ACTIVATION_CODE_1)<NAME_OF_VARIABLE> : Dynamic values generated by the IUT or test tool (e.g., <EUICC_CI_PK_ID_TO_BE_USED>, <S_ENC>, <S_MAC>)#IUT_NAME_OF_SETTING : Vendor-provided implementation details (e.g., #IUT_RSP_VERSION, #IUT_LPAd_Confirmation, #IUT_SM_DP_ADDRESS)IUT settings (Annex F) cover product-specific information that test tool providers need: supported Java Card version, LPAd confirmation mechanisms, supported radio access technologies, and DLOA URLs.
Based on GSMA SGP.23 v1.16 (29 April 2025) : RSP Test Specification, Sections 3, Annexes A, B, E, F, G, J
| ← Previous: SGP.23 Overview: How eSIM Interoperability Is Tested | Section Index | Next: Testing the LPA: LDS, LPD, and LUI Conformance → |