Skip to main content

Third Party SIM Applications: Now EUICC ME - Now YOU Don't!


The Embedded UICC (eUICC) is a hardware agnostic technology surface mounted on the telecoms device baseband. After installing and enabling an eUICC profile, it essentially becomes and acts like a SIM. On Consumer RSP devices End Users can load applications located underneath the MNO Security Domain (MNO SD) hierarchy in the enabled profile on the eUICC, which belongs to the MNO, rather than being installed in the eUICC independently of any particular profile.


It is expected that Consumer RSP and traditional SIM based mCommerce services and associated applications will converge to coexist on the same device. So what happens to these applications when the End User switches another profile? Where do the Mobile payment, Loyalty, Couponing, Mobile transit, etc go after switching profiles?


Currently there is no solution in GSMA’s M2M or Consumer RSP specifications that would allow any applications installed by the end user to ‘live on’ after the current profile where they were originally installed has been disabled and another profile has been enabled.


These ‘missing’ applications haven’t been deleted but they are no longer available or visible to the M2M Service Providers (SPs) or Consumer RSP’s End-Users, until they re-enable the profile where the ‘missing’ application was originally installed.


GSMA are aware of this issue, but the development of a solution has been put on hold. It’s not clear if it was due to time constraints, technical constraints or due to the fact that many of these applications previously installed on the SIM were expected to have been NFC applications aimed at mobile payment, transit, loyalty etc, which have now been replaced by alternative Host Card Emulation (HCE) solutions.

eUICC m2m consumer remote sim positioning



The main impact of this limitation in the GSMA’s specifications is not a pressing concern for the short-term for the Consumer RSP domain but is more so for the M2M domain. SPs send and receive data to/from their devices in the field to their M2M device management platforms providing ‘live’ feedback allowing the SPs to deliver services to their customers. This data is sent via the MNOs cellular network but if the data is not secured then the SP is relying solely on the MNOs security layer to protect the SP sensitive data, plus the MNO has the ability to view the sensitive SP data. Therefore, third party applications installed on the enabled profile in the eUICC will emerge to address these security concerns for the main M2M verticals - automotive, eHealth, Smart Cities and Smart Home. For example, in the automotive industry the data flow of an autonomous driving car will be critical to the safety of the passengers in the car, other vehicles around them and anyone else using the road network. Therefore the eUICC in the M2M domain provides the connectivity layer, but in addition the hardware security that it delivers offers a secure location to install applications to identify and authenticate the device to the SP platform.


In the case of Consumer RSP devices, it is expected that in the near future the eUICC will be used to hold applications such as a digital driver's license, which is not an ideal fit for the current HCE and tokenization trend, therefore the application would need to be available across different profiles. Not to rule out NFC SIM based payment, transit and loyalty applications for MNOs who still play in these verticals.


If we want to move third party applications between profiles or keep them available to all profiles, how do we do so - which is the best option? There are a number of different approaches or technical solutions that could be implemented:


  • Do not make third party applications available across all installed profiles. This approach would force the SP in M2M or the End User in Consumer RSP to manually re-install any previously installed applications. This is extremely inconvenient to the SP and the End-User and the issue of linking all the different instances of the same application would still need to be managed by the SP platforms.
  • Exchange third party application identifiers (AIDs) to try to automate the re-provisioning of the third party services. This approach would require the use of a notification mechanism to inform the SP platforms that the eUICC profile was about to be disabled and before it occurred all the AIDs installed on the eUICC would be ‘flagged up’ to the owner SPs in M2M and Consumer RSP where applicable. The SP platforms would then start to install and provision the identified replacement applications. Again the issue of linking all the different instances of the same application would still need to be managed by the SP platforms, unless they were all un-installed by the SP platforms prior to the platform being disabled. The complexity of the notification mechanism and also the un-installation then re-installation and re-personalization is far from an elegant solution.
  • Reserve memory in eUICC’s operating system for a Utility Security Domain (USD) associated to the Issuer Security Domain-Root (ISD-R) to store the third party application executable load files (ELFs) that can be used to create new third party application instances into the newly enabled profile on request of the SP platform via GlobalPlatform’s existing Scenario 2b Push Model or Scenario 3 Key Agreement Model. The ELFs in this approach then exist independently from any profiles and it involves less data traffic over-the-air (OTA) or over-the-internet (OTI) as only the perso stage of the third party application needs to be performed remotely. But again the above issues of the notification mechanism and also the un-installation then re-installation and re-personalization still exist.
  • Extend the USD approach by introducing a ‘storage’ application that can back up customer details before the applications disappear post profile switch, to eliminate the need to perso again OTA or OTI, after the new instance is installed in the new profile. But again the above issues of the notification mechanism and also the un-installation then re-installation still exists. Additionally, the End-User may not want to or need to move all their current third party applications to the new profile, adding further complexity to the final solution.
  • Extend the USD approach to use it as a ‘Central Services Security Domain’ (CSSD). In this approach all third party application instances are installed and personalised in their own third party Supplementary Security Domain (SSD) associated to the CSSD under the ISD-R, ensuring that the third party applications are available to any enabled profile. It may also be necessary to allow the installation of third party applications globally or under a profile (e.g. an MNO-specific application), but this highlights the issue of how to allow the SP or the End-User to choose their preferred option at install time? But other advantages of this option are that third party applications are only installed and provisioned once and there is no need for any notification, un-install/re-install mechanisms. The disadvantages to this approach is that the M2M and Consumer RSP specifications would need to be updated, plus potentially the core GlobalPlatform specifications to accommodate this type of functionality and overcome these and other potential issues:
    • When installing a new SSD/ELF/Third Party Application under the CSSD it would make sense to ensure that the new AID does not conflict with any AID within any existing profile (for disabled as well as enabled profiles). Otherwise there will be conflict if you try to enable a profile that contains an AID that already exists within the CSSD. This new functionality could be added to each profile, but a better solution would be to add it to the attributes of the CSSD.
    • When loading a profile, the AIDs of ELFs and Third Party Applications within the profile package need to be checked against the CSSD to determine if there are conflicts. This means that an entity on the eUICC needs to be able to examine the contents of every profile meaning that profiles may no longer be viewed as independent self-contained entities. Again a probable solution would be add it to the attributes of the CSSD, otherwise adding this to the profiles could be viewed as an unacceptable security concern.



The use of third party applications cannot continue to be ignored or put on hold by the GSMA, so the M2M and Consumer RSP specifications will eventually need to address this issue. Ensuring that future M2M and Consumer RSP architectures offer a flexible and compelling solution for SP and End-User services - not just for NFC SIM applications but for identification and authentication applications required to address security concerns regarding the data itself - is a key value add for the eUICC architecture of both M2M and Consumer RSP. If GSMA do not move to address these concerns, the strong and compelling value-add of the eUICC - namely, its role as a hardware secure element - will be missed, causing the eUICC to be viewed only as a connectivity solution when it can offer so much more.

Ultimately the RSP teams at GSMA will decide whether to solve this issue or not; and, if they do, which approach to take. However, it is not expected to be addressed in the next major release of the Consumer RSP specifications due in Q4 2017, and the clock is ticking as SPs start to investigate how to protect their data in the M2M and Consumer RSP domains, especially given the recent security breaches that have occurred.