The hidden supply chain behind consumer eSIMs.

In August 2024, a team from NYU Abu Dhabi, Nokia Bell Labs and Telefonica Research published a reverse-engineering study of Airalo's supply chain.

Depending on where you're travelling, your Airalo profile authenticates through one of those home networks, and your internet traffic eventually breaks out through one of their gateways, almost always in a country different from the one your phone is physically in.

In 2025, a separate team at Northeastern University published their findings at USENIX Security.

Among the other findings:

None of this is about any one brand being bad. It's about how opaque the consumer eSIM supply chain is from the buyer's side, and how little of that opacity is visible when you're tapping a purchase button in an airport lounge.

The research above is about where data goes. There's a second layer worth understanding. What actually gets loaded onto your device when you install an eSIM profile, and what someone upstream in the supply chain can do with it.

Identifier exposure

The USENIX paper again. Resellers on at least two platforms got access to subscriber IMSIs, device identifiers including IMEI, approximate location data, and the ability to send SMS to customers. An email address and a payment method was all that stood between an attacker and those capabilities.

An IMSI in the wrong hands isn't abstract. With paid access to the SS7 interconnect (there are grey-market services that sell it), an attacker can query your approximate location, redirect incoming SMS to intercept 2FA codes, or force the device off the network entirely. A 2017 case at O2-Telefónica in Germany used this exact technique to drain bank accounts. An IMEI sticks with the phone across SIM changes, and its first 8 digits (the TAC) identify make and model, which is enough to prepare exploits for that specific handset.

The more plausible day-to-day threat, though, isn't an exotic signalling attack. It's smishing that lands on the travel eSIM carrying the sender-ID of the user's home carrier. “Security alert from [your carrier]: unusual sign-in attempt, verify at…” The employee is already receiving legitimate roaming texts. A spoofed one slips in easily.

Applets loaded with the profile

eSIM profiles aren't just authentication credentials. They're containers that can carry Java Card applets running on the secure element inside the phone, and whoever issues the profile decides what gets included.

Applets can use the SIM Toolkit to send and receive SMS silently, read the IMEI and cell location, launch URLs in the browser, trigger USSD codes, or display system-level prompts that look like they came from the OS or the carrier. All of it sits below the application layer, without the permission prompts a normal app would trigger.

This has been exploited in the wild. Simjacker, disclosed by AdaptiveMobile Security in 2019, used a binary SMS to silently trigger an applet already sitting on the SIM, which then exfiltrated the victim's IMEI and cell location. It was used for targeted surveillance across more than 30 countries. WIBAttack, disclosed the same year, hit a different applet using the same class of attack. Both worked because the applets were there on the SIM without the user consenting to them, or knowing they were there.

The USENIX paper also validated, on a private LTE testbed, “profile deletion failures and profile lock-in”. These are profiles that don't fully remove when the user thinks they've deleted them. Any applet shipped with a profile can persist on the eUICC past that point.

What this adds up to

You're extending the trust boundary of your phone's secure element to a supply chain you can't see.

Wholesale infrastructure · mostly unseen

If the person installing the app is on holiday, the worst case is usually a latency hit and some advertising targeting based on a wrong geographic fix. Irritating, not serious.

When it's an employee using the same eSIM to log into your CRM, your email, Teams, Google Workspace or a VPN into an internal system, it's a different conversation. The traffic doesn't teleport to Salesforce. It takes a path:

The basic question here isn't a regulatory one. It's a question of who is actually processing your employees' data. Consumer eSIM privacy policies typically list “third-party processors” for IT services, advertising and analytics, without naming the wholesale operators actually carrying the packets. If you can't name them, you can't assess them.

None of this is fear-mongering. Most business travel is mundane and the actual data exposure on a given trip is probably comparable to browsing hotel wifi. But “comparable to hotel wifi” isn't a standard most IT teams would sign off on for CRM access. And the risks specific to consumer eSIMs (an unclear home network, an opaque jurisdictional path, contractual terms that barely acknowledge business use) aren't things most corporate IT policies currently ask about.

You don't need to ban consumer eSIMs to take this seriously. You need to be able to answer a few basic questions about the connectivity your business data is flowing through.

Most businesses running on expense-reimbursed consumer eSIMs can't answer any of these. It isn't a failure of diligence. The information isn't visible to the person buying the plan, and it certainly isn't visible to the finance team approving the expense.

eSIM Copilot is a managed eSIM platform. That changes the answers.

Your business has probably signed big enterprise agreements for Microsoft 365, Salesforce, CRM tooling and security software. The mobile layer is the odd one out. The connectivity your employees rely on to reach those platforms is the thing you have the least visibility into, and the thing most likely to be a consumer-grade product bought five minutes before take-off.