The eSIM story is no longer just about downloading a mobile profile instead of inserting a plastic SIM. As eUICC technology spreads across smartphones, connected devices and IoT deployments, the secure element underneath it is being asked to do more — sometimes hosting several profiles, applications and services controlled by different stakeholders.

That flexibility is useful. It is also where security gets more complicated.

The GSMA has responded with SGP.27 v1.0, the Protection Profile Module for Application Isolation in the eUICC. Published on 17 July 2026 and designed to work with SGP.25 v2.1, the module adds stronger safeguards for separating applications and profiles inside an eUICC.

In practical terms: if several parties are sharing one highly trusted piece of hardware, one badly behaved application should not be able to reach into somebody else’s territory.

Why isolation matters

Traditional eUICC security has relied heavily on controlling what software is allowed onto the platform. Applications are expected to pass verification and follow strict security requirements before they are loaded.

That remains important. But modern eUICC deployments are becoming less tidy.

Operators, device makers, service providers and IoT platforms may all have different development cycles, verification processes and operational priorities. The more stakeholders a secure element has to support, the harder it becomes to assume that every application will always behave exactly as expected.

SGP.27 adds another line of defence. Rather than depending entirely on application verification, the eUICC itself is expected to enforce stronger boundaries around what each application can reach.

The GSMA describes this through a new security objective, O.ISOLATION.

What O.ISOLATION changes

The principle is familiar from modern computing: give an application access only to what it needs, and stop it from crossing into another security domain unless an authorised interface deliberately allows it.

Under the enhanced model:

• Applications associated with one operator profile should not be able to access another operator’s profile.
• Applications should not be able to reach protected eUICC platform assets.
• Applications outside an operator profile should not be able to interfere with that profile’s content.
• Cross-boundary access should happen only through explicitly permitted interfaces.

That may sound like a technical refinement, but it addresses a practical risk. A compromised, vulnerable or badly implemented application becomes less capable of affecting the rest of the eUICC.

From prevention to containment

The most interesting part of SGP.27 is the shift in security thinking.

Verification remains the first line of defence. The new module does not make secure development, code review or application validation optional. Instead, it assumes that prevention alone is not enough.

If an unverified or compromised application attempts unauthorised code execution, bypasses access controls or tries to cross profile boundaries, the platform should have mechanisms capable of containing the damage.

That mirrors the wider move across software and cloud infrastructure toward sandboxing, least-privilege access and segmentation: trust less, isolate more, and limit the blast radius when something goes wrong.

There are parallels elsewhere in the secure-element world. Oracle’s Java Card architecture has long used an application firewall to isolate applets, while GlobalPlatform defines security domains, access controls and protection profiles for multi-application secure elements. Its Secure Element Protection Profile was updated in 2025 to align with Common Criteria 2022.

SGP.27 is therefore not inventing isolation. Its importance is in formalising stronger isolation specifically for increasingly complex eUICC deployments.

What manufacturers and operators gain

For eUICC manufacturers, the module creates a clearer route for demonstrating that their platforms can defend profile and platform assets even when applications from different parties coexist.

That may require stronger runtime controls and separation between functional realms, but it also gives manufacturers a better security framework for advanced eSIM and IoT use cases.

Operators gain confidence that their own profile is not relying entirely on every other stakeholder sharing the eUICC having equally strong processes.

They still remain responsible for applications inside their own profiles. SGP.27 does not make unsafe software safe. It simply makes it harder for one weak application to become everybody else’s problem.

For simple deployments with one tightly controlled profile and a limited application set, the added framework may offer less immediate operational value. Its strongest case is in multi-stakeholder environments where separation itself becomes part of the security requirement.

Certification becomes part of the product

The timing is notable. Europe’s EUCC cybersecurity certification scheme is a Common Criteria-based framework for ICT products, including chips, smart cards and secure elements. ENISA positions EUCC as a way for suppliers to demonstrate assurance through a commonly understood evaluation process.

That places SGP.27 inside a wider market trend: security claims increasingly need to be demonstrable, testable and certifiable rather than simply promised.

There is still work to do. Isolation standards are only as useful as their implementation and adoption. The next questions are how quickly eUICC manufacturers incorporate the module, how certification bodies interpret it in practice and whether operators begin asking for SGP.27-based assurance in procurement.

The real significance

SGP.27 will not change what the average traveller sees when installing an eSIM. That is precisely why it matters.

The eSIM market is moving toward more profiles, more embedded services and more stakeholders sharing the same secure hardware. GlobalPlatform, Java Card and Common Criteria already provide important building blocks for multi-application security; the GSMA is now tightening the eUICC-specific layer around them.

The competitive advantage will not come from claiming that an eUICC can host more applications. It will come from proving that those applications can coexist without compromising one another.

As eSIM becomes infrastructure rather than a feature, isolation stops being a technical extra. It becomes part of the trust model.