As eSIM technology continues to evolve, interoperability and standardized testing remain essential to building trust across an increasingly complex ecosystem. This becomes particularly relevant with the introduction of the GSMA SGP.32 specification for IoT eSIM, which brings together components from different vendors and introduces new approaches to remote eSIM management.
In this interview, Marcus Dormanns, Director Product Management & Business Development at COMPRION, talks to Alex Sinclair, CTO of the GSMA, about the role of testing and certification in the eSIM ecosystem, the challenges of balancing interoperability with innovation, the maturity of SGP.32, and the potential impact of AI on specifications and testing.
Below is the transcribed version of the interview.
Marcus Dormanns (COMPRION):Hi everybody, I'm Marcus Dormanns. I'm with COMPRION and responsible for product management and business development. Today I'm with Alex Sinclair, and we want to talk a little bit about eSIM and eSIM testing.
Alex, many thanks for your willingness to contribute to this. Maybe you can introduce yourself and the GSMA quickly.
Alex Sinclair (GSMA): Well, first of all, it's my pleasure, Marcus, and it's great to see you again.
I'm Alex Sinclair, I'm the CTO of the GSMA. I've been in telecom, “sadly”, for over 40 years. The last two decades of that have been spent with the GSMA.
Many people know the GSMA for different reasons. We're a global industry association for all the mobile operators around the world, together with the major ecosystem players and, increasingly, players from other vertical sectors.
A lot of people know us for our shows like Mobile World Congress in Barcelona, but we also do a lot of work in the government and policy arena and, of course, technical standardization like eSIM.
Marcus: Great. And the good thing for today is that I don't think there are many people on the globe who know more about mobile telecommunications than you do. So it's really good to have you here.
The GSMA is an organization where the various companies from the ecosystem collaborate to define the eSIM technology, the architectures, the specifications, and also, of course, specifications and approaches for testing. From your perspective, why is a structured, standardized, and well-defined approach to testing relevant for eSIM?
Alex: To be honest, Marcus, this is kind of in our DNA as the GSMA. We're all about standardization, technology, and interoperability. So a standardized approach for something as complex as the eSIM ecosystem is pretty important.
We've got so many different components, players, and stakeholders. So, it's essential that the standards provide a foundation for ensuring interoperability, consistency, and trust across those different entities involved.
We all know this, right? Standardized testing enhances interoperability, quality, and compliance. It helps ensure that implementations behave consistently against the specification, reduces integration risks, and gives confidence to operators and device manufacturers that certified components can be deployed at scale and still provide a certain level of trust.
Without that testing, the ecosystem would face fragmentation, inconsistent behaviors, and, very importantly, higher operational costs.
Marcus: The different components of an eSIM architecture – if we think about the IoT architecture, for example – include the eSIM itself, the IPA, the eIM, and the SM-DP+. There are different requirements for testing and also for the governance of testing.
GlobalPlatform plays a role in this. Of course, there are also the GSMA, GCF, and PTCRB for some components. Why is this the case? Many people I talk to are a little confused because it can appear somewhat fragmented. Maybe you can explain why this happened and how it makes sense.
Alex: You could argue that it's based on legacy, but in reality, there are certain bodies that have a well-established pedigree for testing, compliance, and certification in certain areas.
You mentioned GlobalPlatform. That's a perfect example. As a general rule at the GSMA, we try not to reinvent the wheel. If something good already exists, then we tend to use it.
The other obvious point is that the components you've just mentioned are radically different. If we're looking at the eSIM itself, using something like Common Criteria and GlobalPlatform makes a lot of sense because it's a high-security element.
When we look at things like actual devices and the LPA, for example, that's much closer to traditional device and network access testing. So naturally, we reuse people at GCF and PTCRB.
And then, for some of the other components that are basically new, it's pretty much the GSMA specifications.
We try, as I said, not to reinvent the wheel, but to maximize the reuse of existing expertise and processes.
Marcus: That sounds like it makes a lot of sense. Do you see a risk that you will end up with different levels of assurance regarding compliance with the specifications and interoperability? The rules also differ to some extent depending on whether something is covered by GlobalPlatform, GCF, or the GSMA.
Alex: I would say that different levels of assurance are actually desired in this particular case. Again, if we look at some of the components, from the highest-security level of the eSIM down to some of the more traditional IT servers, I think you require a different level of assurance.
By reusing the people who are experts in those particular fields, we're aiming to maximize the overall level of compliance and trust in the whole ecosystem.
Marcus: When looking at certain components, for example in the IoT architecture, there are very different rules for certification.
Let's pick the eIM. Certification is voluntary, and the test methodologies are not as strictly defined as they are for other components covered by GCF or GlobalPlatform.
Isn't there a risk that, for example, this one component could lack a certain level of interoperability or compliance with the specification?
How do you see this? Because one of the big promises of SGP.32 is, of course, interoperability between different components from different suppliers – for example, also to get rid of vendor lock-in.
Alex: Again, this is a tricky one. But you've got to understand – and of course you do, because you're an expert in this field – that with something that's brand new, you've got to be careful how much process you layer on top.
It's going to change and mature as real-world developments and implementations take place. And in the field of IoT, the different use cases are so vast that you've got to be careful that you're not actually blocking innovation.
At the same time, you have to have that basic level of interoperability, as you say. So I would say it's a balance between having enough testing to make sure that it's truly interoperable and getting rid of that vendor lock-in, as you quite rightly said, while at the same time not constraining the system in its early days. It's got a long way to go yet, I think. We've been waiting for IoT for at least 20 years, and it's still going to take some time to fully mature.
We're learning a lot in the process. And that's the good thing about the GSMA: because we convene all the different stakeholders, we can learn from real-world deployments.
If we discover it's not firm enough, we can toughen it up. If we discover that we've missed something, we can modify it. But it's really a question of maturity, I think.
Marcus: And I think it's tricky to find the best way to make this trade-off between what is really necessary and essential for testing and what would be overkill and just flood or overload the ecosystem, right?
Alex: Well, imagine, for example, if you took something as strenuous as Common Criteria and applied it to every single hardware and software element. You'd be there until Christmas.
It's about finding the right approach that is fit for purpose. And it may change over time. I'm fully cognizant of that.
Marcus: Alex, let's assume we're in 2030. Technology changes, methodologies change, and the ecosystem is changing. What would you imagine is going to change for eSIM testing and eSIM certification if you look at the next three or four years, for example?
Alex: I'm afraid my crystal ball is a bit foggy at the moment. But given the pace of the evolution of the technology itself and the diversity among the IoT use cases, I think it's quite hard to predict exactly how the testing and certification regime will change.
But they are, of course, always going to remain a cornerstone of everything we do.
As I mentioned previously, we have to learn in the process because sometimes you develop something for one purpose and find that it gets used for a completely different purpose. So I think it all comes down to maturity again.
Obviously, you mentioned 2030. By 2030, I would hope that we'll see many different IoT use cases very well established. And then we can be very confident that we have the right approach.
But at the same time, we have to be flexible enough to recognize that there could be new requirements and new scenarios that we simply hadn't thought of.
The one thing I would say is that it's never going away. It's always going to be a cornerstone of interoperability and trust. And that's the most important thing.
Marcus: How long do you think it will take for the latest specification, SGP.32 for IoT scenarios, and the components coming to market to become mature – at least to some extent – with respect to interoperability?
Today, the technology is still pretty new. And we know that at the beginning, you always run into interoperability problems. That's just normal for new technology.
But what do you think? Does it take one, two, three, or four years until we have an ecosystem with mature technology?
Alex: Well, let's just pretend we're analysts. 2030 is a nice round number. And you mentioned three or four years. That feels about the right sort of ballpark for this sort of thing.
The one encouraging thing I would say is that there's pent-up demand for the use of this type of technology. And I think that demand has existed for many years, but there's growing confidence that it can actually be done.
Some of the use cases in different sectors have been fairly clear for some time. But believing that this is the right solution and looking at real-world examples in other sectors, for example, is probably going to be the forcing function.
So I would hope that within three to four years, it would be thriving in a very mature market. Who knows?
Marcus: What's your perspective on how AI will change the way we deal with testing and test specifications going forward? I know that the GSMA is working on making use of AI for these processes. How do you think this is going to change how we deal with it?
Alex: Again, that's quite a multifaceted question. I could start at one extreme end and talk about Mythos and Project Glasswing and all these new attacks that have been generated by various chains of tools and AI components.
On the other hand – and you've mentioned it – the work we're starting to do is basically applying AI where we can to try to highlight and test deficiencies, possible weaknesses in the specification, much earlier in the development cycle, so that we're not as prone to zero-day attacks as we might otherwise be.
It's obviously going to be a new war in AI for defense and AI for cyberattack.
But the more we can use it internally – and as you said, we've started to do that and we're testing some of our own specifications – I think those are the basic stepping stones to making sure we're using AI responsibly and trying to get a handle on what is a very, very rapidly evolving ecosystem.
Marcus: What's your mode of work within the GSMA and in these eSIM working groups? Because it's not just the GSMA. There are all the companies in the ecosystem – your members. How do you actually collaborate? What's the mode of work in your working groups so that, at the very end, we see specifications coming out of this?
Alex: That's a very good question, as you know, Marcus, because you've had many years of experience with this as well. Trying to standardize by consensus can be tricky until you gain the trust of the different parties.
In the early days, there was a lot of, I would say, lack of trust between the various players. But they've been working together for so long now that it's turned into a much more finely tuned and well-oiled machine.
There's now far more willingness to compromise or to hear other people's solutions. I would say it's working very well.
Some would argue it's a slow process. But on the other hand, it does mean you get the buy-in of a very broad section of the ecosystem. It may not always have been perfect, but I think it's pretty well tuned now.
Marcus: Good to hear that. There's a willingness for real compromises and for collaboration, because that's essential.
Alex: Absolutely.
Marcus: Alex, thanks a lot for this interview and for these really interesting insights. That's it for today. Thanks and goodbye.
Alex: Thanks, Marcus. I look forward to seeing you again – probably in Barcelona, but who knows.
Marcus: For sure.
