The JCF will be holding a Series of 6 FREE Webinars in Q4 of 2026 – below are the session details and registration access. WHAT WILL YOU LEARN?The Java Card Webinar Series will provide you with an …

sysmocom cannot add the capability to upload raw entire profiles as that would require a rather comprehensive manual security review of the profile before being able to approve it. If there is sufficient commercial interest (i.e. volume of esim profiles) or funding for the feature development, what we can do is to add the option for users to add java applets to eSIM profiles as part of the profile manager, or we can manually create a profile type/template with the java applet included. Both would require the related effort to be paid for. sales@sysmocom.de is the correct point of contact for commercial inquiries like this.

sysmocom cannot add the capability to upload raw entire profiles as that would require a rather comprehensive manual security review of the profile before being able to approve it. If there is sufficient commercial interest (i.e. volume of esim profiles) or funding for the feature development, what we can do is to add the option for users to add java applets to eSIM profiles as part of the profile manager, or we can manually create a profile type/template with the java applet included. Both would require the related effort to be paid for. sales@sysmocom.de is the correct point of contact for commercial inquiries like this.

I have already confirmed it to be working with the sysmoEUICC1-C2T card and the local SMDP+ and Sysmocom appears to offer a commercial service at https://esim.sysmocom.de (in partnership with Invigo for the SMDP+ commercial/GSMA certified part). It offers a bunch of templates but no option to upload a complete profile, that’s why I asked.

I have already confirmed it to be working with the sysmoEUICC1-C2T card and the local SMDP+ and Sysmocom appears to offer a commercial service at https://esim.sysmocom.de (in partnership with Invigo for the SMDP+ commercial/GSMA certified part). It offers a bunch of templates but no option to upload a complete profile, that’s why I asked.

I have finally made progress on this and tested my applet against the sysmoEUICC1-C2T and it works fine, now I want to deploy it to an eUICC inside a test phone (Google Pixel 7A). I’m trying to use the esim.sysmocom.de site for it but it does not appear to support custom profiles, only sysmocom templates. Is there any way to upload our own for production testing?

To load the profile with applet into a production grade soldered esim in a consumer device you will need to go through a GSMA certified SMDP+ from an accredited platform vendor. If you use a removable plastic card you can load it through a test SMDP+ platform. Oamocom has one that you can run locally on your PC that will inject the profile or if you want to use a phone you need the same as above but running GSMA test certificates (sgp26)

To load the profile with applet into a production grade soldered esim in a consumer device you will need to go through a GSMA certified SMDP+ from an accredited platform vendor. If you use a removable plastic card you can load it through a test SMDP+ platform. Oamocom has one that you can run locally on your PC that will inject the profile or if you want to use a phone you need the same as above but running GSMA test certificates (sgp26)

Who creates the OS for parts like the OC1230 or SE052, with all the security domain stuff? Infineon and NXP do their own OS? Or do they farm that out to G+D? I notice Infineon sells the OC1230 like an EUICC, but I dont think they wrote the OS??

Who creates the OS for parts like the OC1230 or SE052, with all the security domain stuff? Infineon and NXP do their own OS? Or do they farm that out to G+D? I notice Infineon sells the OC1230 like an EUICC, but I dont think they wrote the OS??

Exactly — the MEP distinction is important. With SGP.22 MEP, the virtual-eUICC separation means the profiles can coexist without the AID namespace being treated as one flat profile namespace, despite sharing the physical chip/UART. The ISD-R ↔ ISD-P case is different, and the ARA-M collision is the interesting edge case: those applications can end up in the same effective AID namespace despite belonging to different security-domain branches. That makes it a platform/GlobalPlatform application-selection issue rather than JavaCard Shareable-interface firewalling. So I’d separate the cases as: **SD-to-SD within one profile → Shareable governed by JavaCard context/AID policy.** **ISD-P-to-ISD-P under MEP → virtual-eUICC isolation.** **ISD-R/SSD ↔ ISD-P → AID collision can still occur.**

Exactly — the MEP distinction is important. With SGP.22 MEP, the virtual-eUICC separation means the profiles can coexist without the AID namespace being treated as one flat profile namespace, despite sharing the physical chip/UART. The ISD-R ↔ ISD-P case is different, and the ARA-M collision is the interesting edge case: those applications can end up in the same effective AID namespace despite belonging to different security-domain branches. That makes it a platform/GlobalPlatform application-selection issue rather than JavaCard Shareable-interface firewalling. So I’d separate the cases as: **SD-to-SD within one profile → Shareable governed by JavaCard context/AID policy.** **ISD-P-to-ISD-P under MEP → virtual-eUICC isolation.** **ISD-R/SSD ↔ ISD-P → AID collision can still occur.**

@fkamanzi thansk for your insight and explanation in the topic. It reflects also my understanding, but is much more clear than I would have been able to put it. One comment: In SGP.22 v3.x with MEP (multiple enabled profile) I expect there is also no AID clash as there are basically separate eUICCs virtualized on the same phyiscal chip. While they do share the same physical UART, there were some extensions at the TPDU T=0 transport level to separate the different virtual eUICCs at the lowest transport level from each other. Another comment: The AID clash does however happen if applications are installed in the ISD-R (or any other SSD below the ISD-R) and the the ISD-P. This is what we’re seeing with the ISD-R installed ARA-M applet clashing with any ARA-M present in the ISD-P (see section in sysmoEUICC1 user manual about this topic). I brought this up with leaders of at least one GSMA eSIM working group, but it seems it is nothing they want to investigate / follow-up

@fkamanzi thansk for your insight and explanation in the topic. It reflects also my understanding, but is much more clear than I would have been able to put it. One comment: In SGP.22 v3.x with MEP (multiple enabled profile) I expect there is also no AID clash as there are basically separate eUICCs virtualized on the same phyiscal chip. While they do share the same physical UART, there were some extensions at the TPDU T=0 transport level to separate the different virtual eUICCs at the lowest transport level from each other. Another comment: The AID clash does however happen if applications are installed in the ISD-R (or any other SSD below the ISD-R) and the the ISD-P. This is what we’re seeing with the ISD-R installed ARA-M applet clashing with any ARA-M present in the ISD-P (see section in sysmoEUICC1 user manual about this topic). I brought this up with leaders of at least one GSMA eSIM working group, but it seems it is nothing they want to investigate / follow-up

These are two separate lifecycle questions, and the SAIP model keeps them apart. On selectability: applet instantiation and selectability are not the same state. When the ProfileInstaller works through the SAIP, ApplicationInstance PEs create and register the applet instances, and the processData field carries install-time personalization that the applet consumes through its install/personalization hook — the applet is instantiated and receiving data, but that is not the same as being SELECTable over the radio/APDU interface. Selectability is gated by the applet’s lifecycle state and the profile’s own state. During installation the profile is in Disabled state, so nothing in it is reachable from the ME; the applet being “alive” enough to consume processData at install time does not make it externally selectable then. So no, processData does not imply the applet is selectable while the profile installs — it means the installer is driving the applet’s personalization, in-card, before the profile is ever enabled. On AID clash: the isolation boundary is what prevents it. Each profile lives in its own ISD-P, and per the GSMA rule an ISD-P has no visibility of any other ISD-P, so AID uniqueness only has to hold within the one profile being installed, not across profiles. Two different profiles can legitimately carry the same applet AID, and that is fine precisely because JCRE/GP resolution is scoped inside the ISD-P — a SELECT by AID is resolved within the active profile’s context, never across the boundary. Within a single SAIP, the installer is building one profile’s namespace, so the only clash you could create is duplicate AIDs inside that same profile, which is an authoring error the installer will reject, not a cross-profile collision. The one caveat worth stating: this holds because only one profile is Enabled/selectable at a time on a consumer eUICC (and even under MEP the profiles stay isolated). If you are reasoning about SGP.32 (M2M/IoT), the same ISD-P isolation applies, so the cross-profile AID-clash concern does not arise there either. If you have a concrete SAIP where two ApplicationInstance PEs in the same profile share an AID, that is the only real clash, and that is a profile-authoring fix, not a platform behaviour.