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-1 eUICC Testing > eUICC Certification: From SGP.23-1 Tests to SAS-UP Approval
💡 Why this matters: Passing SGP.23-1’s 797 pages of test cases isn’t just an engineering milestone: it’s a regulatory and commercial gateway. An eUICC that can’t produce a valid DLOA (Digital Letter of Approval) backed by SAS-UP accreditation cannot be deployed in production devices. Understanding the certification workflow: from declaring optional features through test execution to final approval: reveals what separates a prototype eUICC from a production-ready one.
Key takeaways:
- Certification begins with the vendor declaring optional features and providing IUT settings (Annex F) : this determines the exact test suite
- The Applicability Table (Table 5) maps every test case to M (mandatory), N/A (not applicable), or Ci (conditional) based on the vendor’s declarations
- A test execution passes only if the entire test procedure is carried out successfully; inconclusive results occur when setup issues prevent proper evaluation
- The SAS accreditation number embedded in
EUICCInfo2links tested eUICCs back to SAS-UP audited manufacturing sites- The final deliverable is a GlobalPlatform Digital Letter of Approval (DLOA), referenced in SGP.23-1 via GPC_SPE_095
- SGP.23-1 certification feeds into SGP.23 system-level testing, where the certified eUICC participates as a known-good component
- The GSMA runs regular Test Events where vendors bring implementations for formal conformance assessment
The certification path for an eUICC is a multi-stage process that transforms SGP.23-1’s test cases from a specification document into a commercial credential. This article traces the journey from a vendor’s first declaration through to the DLOA that unlocks production deployment.
Before a single test case executes, the eUICC vendor must declare what their product supports. This declaration has two parts:
The vendor fills out a comprehensive capabilities declaration across 30+ options:
| Category | Example Options |
|---|---|
| Cryptographic Curves | NIST P-256, BrainpoolP256r1, FRP256V1, SM2 |
| LPA Features | LPAe support, LPA Proxy |
| Profile Management | RPM, Enterprise Profiles, Device Change, OS Update |
| MEP | MEP-A1, MEP-A2, MEP-B, MEP-B without Refresh |
| Form Factor | Integrated eUICC (SoC-embedded) |
| Unique Behaviours | One-time key reuse for retry, catBusy error handling, 2 PIR support |
Each option is declared as true or false. A vendor may declare both values for the same option: but must provide separate samples configured for each value.
Vendor-specific implementation details that the test tool needs:
#IUT_RSP_VERSION : Which SGP.22 version the eUICC implements#IUT_LPAd_Confirmation : How the device-side LPA confirms user operations#IUT_MEP_LSI_OPTIONS : LSI indication method (MANAGE LSI or T=1 NAD byte)#IUT_EUICC_MULTIPLEXING_LSI_INDICATION : MEP multiplexing configurationThese settings ensure the test tool correctly configures its simulators to match the eUICC’s expected interface.
The Applicability Table (Table 5, spanning pages 11–21) maps every test case to an applicability code based on the vendor’s declarations:
| Code | Meaning | Example |
|---|---|---|
| M | Mandatory: must pass regardless of options | TC_eUICC_ES8+.InitialiseSecureChannel : every eUICC must handle secure channel setup |
| N/A | Not applicable: impossible in this context | TC_eUICC_ES10b.GetEUICCInfo2_RSP_V2.1 : SGP.23-1 targets V3.1, so V2.1 is N/A |
| Ci | Conditional: applies only if specific options are set | C001 = IF O_E_NIST THEN apply NIST-specific PrepareDownload tests |
Conditional codes use Boolean expressions with nesting: IF ... THEN (IF ... THEN ... ELSE ...) ELSE .... This produces a tailored test suite: an eUICC supporting only NIST P-256 gets a different set of applicable tests than one also supporting Brainpool, MEP, and RPM.
Critical rule: If the vendor declares both true and false for an option (providing multiple samples), the test tool must run all applicable tests for each sample independently.
The eUICC must arrive at the test lab in a defined initial state (Annex G.2):
PROFILE_OPERATIONAL1 installed (usually in Disabled state)A clean-up procedure (Annex G.2.6) allows resetting the eUICC to its initial state between test runs.
SGP.23-1 defines three outcomes for every test execution:
This three-state model prevents false negatives: if the test infrastructure has a problem, the eUICC isn’t penalised.
All eUICC tests run in one of two environments:
While SGP.23-1 doesn’t prescribe a specific test report format, the structure is implicit in the specification:
euiccSignPIR, euiccSignRPR) was verified against #PK_EUICC_SIGThe report serves as evidence for the DLOA application and may be reviewed during SAS-UP audits.
The SAS accreditation number (sasAcreditationNumber) is the critical link between SGP.23-1 testing and SAS-UP manufacturing certification:
SAS-UP (Security Accreditation Scheme for UICC Production) audits the eUICC manufacturing site : not the eUICC design. It verifies:
SGP.23-1 test cases verify that:
sasAcreditationNumber in EUICCInfo2 responsesWithout this verification, an eUICC cannot be deployed commercially: the sasAcreditationNumber is checked during SGP.23 system testing and by operators during profile provisioning.
Upon successful completion of all applicable test cases, a Digital Letter of Approval (DLOA) is issued per GlobalPlatform specification GPC_SPE_095 [19]. The DLOA:
The DLOA Registrar and Management System are referenced in SGP.23-1’s architecture diagram (Section 3.1), connected via the ESdloa interface: though this interface is out of scope for SGP.23-1 testing.
An eUICC certified through SGP.23-1 becomes a “known-good” component for SGP.23 system-level testing:
This layered approach means an SM-DP+ vendor testing under SGP.23 doesn’t need to worry about eUICC bugs: they’re using a pre-certified eUICC.
The GSMA organises regular Test Events where vendors bring implementations for formal assessment:
SGP.23-1’s document history (Annex L) shows a steady stream of CRs (Change Requests) arising from Test Events: each one clarifying a test procedure that proved ambiguous during real-world testing. The document evolved from v2.0 Draft 0 (April 2018) through v3.1.3 (October 2023) with contributions from STMicroelectronics, FIME, and the eSIMWG3 working group.
sasAcreditationNumber) in EUICCInfo2 connects SGP.23-1 compliance testing to SAS-UP manufacturing site certificationBased on GSMA SGP.23-1 v3.1.3 (27 January 2025) : RSP Test Specification for the eUICC, Sections 2.1, 2.2, 3, Annexes F, G, L; GlobalPlatform GPC_SPE_095
| ← Previous: eUICC Security Testing: Certificates, Keys, and Channels | Section Index |