SM-DP ( Subscription Manager for Data Preparation )

The SM-DP is used in an M2M RSP environment. It’s function is to take the raw profile information from an MNO, personalise it with the appropriate IMSI/Ki pair information and convert it into a form that is suitable for transmission by the SM-SR to the eUICC.


The process for a profile download in an M2M environment is as follows:

  1.  SMS sent to eUICC by the SM-SR via the SMSC belonging to the provider of the provisioning profile to trigger a session
  2.  eUICC requests that the device sets up a data session using BIP and the URL ( or IP address ) of the SM-SR ( contained in the SMS )
  3.  CAT_TP or HTTPS transport link established between eUICC and SM-SR ( ES5 )
  4.  A secure channel is established between the SM-DP and eUICC
  5.  A profile download is initiated by the SM-DP

Remote Application Management ( RAM ) or Remote File Management ( RFM ) can be implemented between the SM and eUICC using the data connection as per above or simply using SMS.

Consumer eUICC architecture

Consumer eUICCs are defined by GSMA documents SGP.21 and SGP.22. SGP.21 is a functional specification while SGP.22 defines the technical realisation of the functional spec. Within the GSMA SGP.21 is defined by the GSMA member operators ( MNO’s ), while the OEMs are tasked with producing SGP.22 which is the technical implementation specification.

The figure below describes the basic architecture used for Consumer eUICCs.


The consumer specification is a later addition than the M2M version. The separate functions of the SM-SR and SM-DP have been combined into a single function SM-DP+. This is responsible for both establishing a secure programming channel to the eUICC and manipulating and personalising the Profile that is provided by the MNO into a suitable format for download. Certificates loaded into each component above and issued by a trusted Certificate Issuer ensures that the whole process is secure.

The major addition is that of a Local Profile Assistant ( LPA ) in the device that allows the End user to control what profile is active and select new profiles. There is no need for a provisioning profile as the device can be connected to the Internet using WiFi.


The GSMA Consumer standard ( SGP.22 ) was specified later in than the M2M ( SGP.02 ) version. It consolidates the functionality of the SM-DP and SM-SR into a single component, called the SM-DP+. It’s function is to take the raw profile information from an MNO, personalise it with the appropriate IMSI/Ki pair information, convert it to the appropriate format for an eUICC and transmit the profiles to the eUICC.

In most cases the Local Profile Assistant ( LPA ) will be present in the device ( LPAd ), in which case the below architecture applies:


It is possible however to also have the LPA in the eUICC ( LPAe )


SM-DS ( Discovery Server )

The purpose of an SM-DS is to hold a list of profiles that are available to an end user in a consumer eUICC environment. This discovery service is currently operated by the GSMA although there are plans for alternative discovery services to be offered in the future. Further details of the GSMA service can be found here.

The sequence of events is as outlined in the diagram below.

eUICC and RSP certification

There are various bodies involved in the certification of the different elements involved in GSMA compliant eUICC applications.

The GSMA operate a scheme called Security Accreditation Scheme ( SAS ) that provides a certification of the site belonging to an organisation that provides Remote SIM Provisioning services. Details of the scheme and a list of approved sites is available on their web site.

GlobalPlatform tests and lists the actual certified eUICC chips on their website. Select “eUICC” from the drop-down to see the eUICCs that are currently approved.

The Global Certification Forum ( GCF ) operates a scheme to certify RSP compliance of consumer devices, the details of which are available on their website.

The GSMA implements a trusted system through the use of signed root certificates.


SAS certification ( SAS-UP and SAS-SM )

The GSMA operate a Security Accreditation Scheme ( SAS ).

Companies wishing to manufacture eUICCs must get their site accredited to SAS-UP ( SAS for UICC Production ) while those wishing to program eUICCs must get their site SAS-SM accreditation.

The schemes are in place mainly to ensure that the highly sensitive Profiles from the MNO’s are secure. They have components of ISO 27001 to ensure that an ISMS ( Information Security Management System ) and BCP ( Business Continuity Plan ) are in place. In addition they require that all of these procedures are operated in a High Security Area ( HSA ), over a secure network by trained personnel who comply with strict HR policies.

The GSMA currently use two outside companies to conduct the audits for SAS-UP, FML and ChaseWaterford

For SAS-SM they use NCC Group and SRC Security Research & Consulting GmbH

The audit usually takes about a week and is performed by both auditors.

A provisional approval is given once the site is able to demonstrate that they have all of the processes in place to meet the requirements but is not yet operating with real customers. This is sometimes called a ‘dry audit’. Another audit is conducted up to 9 months after provisional approval to finalise the certification. This is sometimes called a ‘wet audit’.

A list of SAS accredited sites is available on the GSMA web site.



SoftSIMs implement eSIM functionality in software and so presents a very low cost solution. This approach is very popular in Asia where it is considered essential to have a very low Bill of Materials ( BoM ). The implementation of a SoftSIM eSIM solution is proprietary as no standards bodies have got involved with this method yet.

The software that facilitates a profile download can execute in one of 3 ways:

  1.  On the GSM modem processor ( e.g. the Qualcomm or MTK chip ) but does not use a silicon trust zone and so does not offer a very high level of security. The manufacturers of the GSM modem chips have released demonstration code that can be used for this.
  2.  On the processor of the OEM device itself. Most of the large Chinese handset manufacturers ( such as Xiaomi and Huawei ) offer this kind of solution and refer to it as a ‘virtual SIM’ or ‘virtual roaming’ solution.
  3.  In an STK applet on the SIM processor chip inside a conventional SIM Java-card. This is usually implemented by sending a message via USSD to a server requesting a profile download and then sending the IMSI/Ki pair via an encrypted SMS


ETSI SSP ( Smart Secure Platform ), iUICC, iSIM and VPP

ETSI ( group SCPTEC#73 ) have been specifying a standard called Smart Secure Platform ( SSP ). The functional requirements for this standard are outlined in ETSI TS 103 465 and the technical requirements in ETSI TS 103 666. The standards are expected to be published in the next 3 months. The 3GPP anticipate incorporating this standard into Release 15 of their specification. This is the version that specifies 5G.

The ETSI SSP standard defines certain functions which ETSI call ‘bundles’ that can be implemented in the smart card such as eSIM functionality, payment and identity.

It is possible to go further than the current eUICC specifications and implement the eSIM functionality in the baseband modem chip itself. This approach is being referred to as iUICC ( Integrated Universal Integrated Circuit Card ) and is being driven by GSM modem manufacturers such as Qualcomm.

ARM Technology have announced a similar solution that makes use of the TrustZone technology on their SoC ( System On a Chip ) which they are calling iSIM.

GlobalPlatform have signed an MoU with the IoT Connectivity Alliance ( ICA ) to promote the use of their two secure component technologies, Secure Element (SE) and Trusted Execution Environment (TEE) in an IoT environment. It is envisaged that their Virtual Private Platform ( VPP ), details of which can be obtained here.

The GSMA have a working goup looking at specifying an iUICC solution.

Bearer Independent Protocol ( BIP )

A key requirement for eUICC’s to operate in a device ( see Annex G of SGP.02 ) is that the device supports Bearer Independent Protocol ( BIP ). This protocol exists only between the device and the eUICC and enables an eUICC to request the device to set up a data session with the SM server. This provides a much faster method of access to the eUICC than SMS. A good explanation of BIP can be found here.

Unfortunately not many devices in the field support BIP. Even though new devices are being designed to incorporate support for BIP, this has severely restricted the adoption of eUICCs