Security · 2026-04-20

eSIM Profile Switching as an Identity Signal, and as an Attack Surface

By J. W. Bouckaert

An eSIM is an embedded, certified secure element, the eUICC, that can hold several operator profiles and switch between them in software. That is what lets one phone carry a home number, a travel profile and a work line without a physical card change. It is also what makes eSIM profile switching an ambiguous signal for identity verification.

A change in the subscription behind a device can mean a traveler enabled a travel profile at the airport. It can also mean an attacker installed a profile obtained through a compromised carrier account or an intercepted activation code. Carrier-side APIs see the result of the change. The record of how it happened sits on the eUICC and with the server that provisioned the profile, and most identity stacks never see it.

This article describes the GSMA architecture behind profile switching, the legitimate patterns it produces, the attack paths researchers have documented, and how a risk score built from switching metadata could work without recording which profile is active. PasskeyBridge does not ingest eUICC event data today. The scoring section is a design discussion.

The standards that define eSIM profile switching

Three GSMA specifications cover remote SIM provisioning. They are published on the GSMA eSIM specifications page.

For identity purposes SGP.22 and SGP.32 matter most. Both define profile operations on the eUICC (download and install, enable, disable, delete) and notifications the eUICC sends back to the provisioning server after those operations. That notification stream is the raw material for any device-side switching signal.

Legitimate switching patterns

Common legitimate patterns each have a recognizable shape:

• Travel profiles. The user enables a foreign profile on arrival, disables the home profile, and reverses both on return. Enable and disable events come in pairs.
• Dual-line use. A personal and a work profile, switched by time of day or by app. The pattern repeats on a schedule.
• Operator migration. The user moves to a new operator and keeps the old profile disabled for a while. One enable, then a long disabled period.
• Device transfer. A new phone receives the existing profile through the manufacturer's transfer flow. A download on the new device and a delete on the old one, close together.

None of these is an attack, but each can look like one if the only input is "the subscription behind this device changed".

The attack surface

The same mechanisms give an attacker a procedurally clean way to substitute the cellular identity behind a number. The USENIX Security 2025 paper "eSIMplicity or eSIMplification? Privacy and Security Risks in the eSIM Ecosystem" by Motallebighomi, Veara, Bitsikas and Ranganathan (Northeastern University) examines privacy and security risks across the consumer eSIM ecosystem.

For an identity provider the practical threat paths are:

1. Carrier account takeover. An attacker who controls the victim's carrier account can request a new eSIM for the number and install it on their own device.
2. Activation code interception. SGP.22 downloads start from an activation code (an LPA:1$... string, often shown as a QR code). Anyone who obtains the code before the legitimate user can install the profile.
3. Coached consent. Consent screens for profile downloads differ across device makers, and a user can be talked into approving a download.
4. Travel eSIM cover. A foreign travel profile bought with weak identity checks can make a substitution look like a trip.

Whether a SIM Swap or Number Verify API flags any of these depends on the carrier and on how quickly its back office records the change.

Scoring switching behavior without tracking profiles

A binary "profile changed" alert treats a frequent traveler and an attacker the same way. A continuous score over recent switching behavior can separate them better. A design that keeps to a zero-PII architecture would work like this:

• Inputs are event metadata only. Event class (enable, disable, download, delete), a coarse timestamp and a country derived from the visible network. No IMSI, ICCID, MSISDN or provisioning server name in cleartext.
• Identifiers are keyed digests. Any value needed to link events, such as a device-scoped event identifier or the provisioning server's address, is reduced to a keyed HMAC-SHA-256 digest under a key the identity provider holds, so the raw value is never stored.
• The score uses a few behavioral features. Switch frequency over a window, time since the last switch, how many distinct provisioning servers appear, whether countries are plausible given recent history, and whether switches happen at unusual hours for that device.
• The score adjusts trust and never decides alone. A low score asks for a fresh passkey assertion. It does not block a user who also presents a strong passkey assertion.

Any thresholds for such a score have to be set from real data. We have no deployment data for it and publish no cohort figures.

Possible data sources

Two sources are possible. An app can read some profile state through the device's eSIM APIs where the operating system allows it, which varies by platform. A carrier can expose switching events through network APIs such as those in GSMA Open Gateway and CAMARA. Neither is part of PasskeyBridge's signal set today.

Limits

• A metadata score cannot say which profile is active, and it should not try.
• Travel will lower the score. The response should be a step-up rather than a lockout.
• It does not replace SIM swap detection. A SIM swap API sees the carrier's back-office change; device-side metadata sees the profile operation on the handset.

Fit with other signals

Switching metadata is most useful next to carrier signal fusion, verifiable credential cross-referencing and passkey-bound assertions, and alongside the broader case in SIM-Swap Detection on Its Own.

Summary

eSIM profile switching is a normal feature that also gives attackers a clean way to move a number. A binary alert on switching produces noise. A score over switching metadata, built from keyed digests and coarse event data, could separate common legitimate patterns from substitution without recording which profile is active. That design is described here as a proposal.

Read the PasskeyBridge solutions overview for the signals the platform uses today.

Start free · Test the API