Security · 2026-04-20

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

By J. W. Bouckaert

An eSIM is a small, certified secure element rather than a SIM card with the plastic removed: the embedded UICC, or eUICC, can hold many operator profiles simultaneously and switch between them in software. That capability is what makes a modern phone able to carry a primary U.S. number, a UK roaming profile, a Japanese travel profile, and a corporate work line on a single device, with no swapping of physical cards. It is also what makes eSIM profile switching one of the most ambiguous signals in modern identity verification.

The same event class—"the IMSI behind this device just changed"—can mean a frequent-flyer activated their travel profile at the airport, or it can mean an attacker just downloaded a freshly provisioned profile they obtained through a compromised SM-DP+ account. The wire-level signal is identical. The audit trail at the eUICC is what tells the two apart, and most identity stacks deployed in 2026 do not look at it.

This article maps the legitimate and illegitimate uses of eSIM profile switching against the GSMA architecture that produces them, then proposes a quantitative measure—the Profile Stability Index—that turns eUICC event metadata into a usable trust signal without recording which profile is active. It is a Zero-PII signal by design, and it slots cleanly into the multi-layer trust composition described in our earlier piece on why SIM-swap detection alone is not enough.

The standards that define eSIM profile switching

There are three relevant GSMA specifications. They are public, and the architectural diagrams in each are the canonical reference for what an eUICC can and cannot do.

For identity purposes, SGP.22 and SGP.32 are the relevant ones. Both define a state machine inside the eUICC that produces a stream of well-typed events—Profile Download, Profile Install, Profile Enable, Profile Disable, Profile Delete, and Notification—and both define a server-side counterpart (the SM-DP+ for SGP.22, the SM-DP+ plus eIM for SGP.32) that signs those events. That signed event stream is the raw material for a meaningful identity signal.

The opportunity

The legitimate use cases for profile switching have grown substantially. GSMA Intelligence's Q1 2026 consumer eSIM tracker projects that consumer eSIM connections will reach roughly 1 billion worldwide by 2025 and continue scaling through 2030, driven by the iPhone 14's eSIM-only U.S. SKU, near-universal Android flagship support, and rapid uptake of travel-profile services from providers like Airalo, Holafly, and the major MNOs themselves. The behavior pattern that comes with that is multi-persona usage: a single eUICC carrying two or more active-or-disabled profiles, switched on demand.

For identity, that creates a signal-rich substrate the industry has not yet learned to read.

A few legitimate patterns worth naming:

• Travel profiles. A user enables a foreign profile on landing, disables their primary, and reverses the operation on return. The eUICC produces a clean, paired Enable/Disable sequence with predictable temporal spacing.
• Dual-line professional usage. A user maintains a personal profile and a corporate profile, switching by time-of-day or application context. The pattern is regular and tied to working hours.
• Operator migration. A user ports out from one MNO to another but keeps the old profile in disabled state for a transition period. The signal is a single Enable plus a long-running Disabled hold.
• Device-to-device transfer. A new phone receives the existing profile via the manufacturer's eSIM Quick Transfer or equivalent. This produces a Profile Download event paired with a Delete on the source device, both within minutes.

Each of these has a recognizable shape. None of them, in isolation, looks like an attack—but each of them, observed without context, can resemble one.

The attack surface

The dual nature of profile switching is what makes it a problem. The same standards that enable legitimate multi-persona identity also provide attackers with a procedurally clean way to substitute the cellular identity behind a device.

Independent security researchers have documented several practical concerns. The 2025 USENIX Security paper "eSIMplicity or eSIMplification?" by Motallebighomi et al. (Northeastern University) catalogs systemic risks across the consumer eSIM ecosystem, including weaknesses in profile-download flows, gaps in user-facing consent UI, and the absence of standardized cross-MNO event sharing. These are architectural gaps in how the ecosystem composes rather than implementation defects in any single carrier.

For an identity provider, the operationally important threat patterns are:

1. SM-DP+ account compromise. If an attacker gains control of a profile-provisioning account at any SM-DP+ in the user's history, they can issue an enable-able profile that the LPA will accept.
2. Activation-code (LPA-AC) interception. SGP.22 profile downloads are bootstrapped from an activation code (an LPA:1$... URI). Interception of that code at the issuing portal—for example, via account takeover at the carrier—allows a third party to install a profile on their own eUICC.
3. Social-engineering of the LPA UI. SGP.22's user-consent dialogs vary widely in clarity across OEMs. A user can be coached into approving a profile download that they do not understand.
4. Cross-jurisdiction profile shopping. Travel-eSIM marketplaces with weak KYC let an attacker acquire a clean foreign profile, install it on a target device they briefly control, and use the resulting signal pattern to mask a SIM-substitution event as a "travel" pattern.

In every one of these cases, a Number Verify or SIM Swap API queried at the moment of attack will return an answer that—depending on the carrier's reporting cadence—looks like a routine profile change rather than a hostile takeover.

The profile stability index

What is needed is not another binary alert. The industry has those, and they fail because legitimate switching produces the same alert as a malicious switch. What is needed is a continuous score that captures the shape of an eUICC's recent behavior and degrades gracefully when that shape becomes unusual.

We call ours the Profile Stability Index (PSI). It is a 0.0–1.0 score, computed over a 30-day sliding window of eUICC event metadata, that quantifies switching risk without storing which profile is active.

Inputs

The PSI consumes only the metadata of events emitted by the LPA (SGP.22) or the IPA/eIM (SGP.32). It never consumes the IMSI, the ICCID, the MSISDN, the SM-DP+ entity name in cleartext, or any other identifier that would constitute PII under GDPR Article 4(1). Each event is reduced to a tuple of HMAC-SHA-256 hashes computed at the device:

This composition is the same Zero-PII pattern we use across all carrier-signal ingestion paths and is documented in our Zero-PII architecture overview.

Score components

PSI is the geometric mean of five sub-scores, each clamped to [0.0, 1.0]. The geometric mean is deliberate: a single very weak component pulls the composite down sharply, which is the desired behavior for a risk signal.

PSI = (s_cad^0.25 · s_rec^0.20 · s_pro^0.20 · s_geo^0.20 · s_die^0.15)

The output is a single floating-point number that sits alongside the carrier-signal trust score in our combined trust coefficient (CTC) calculation.

Behavioral bands

In production, we map the continuous PSI to four interpretive bands. The action surface—what to do when PSI drops—is configured per tenant.

Distribution across real-world cohorts

The chart below summarizes the distribution of 30-day PSI values across four representative cohorts in our pre-production evaluation. The cohorts are stratified by self-reported usage pattern, with no device-side identifier involved.

The separation between the legitimate "frequent traveler" cohort (which sees the most aggressive switching) and the synthetic adversarial cohort is what makes the index useful. Binary alerts collapse those two populations into the same bucket; PSI keeps them comfortably distinct.

PSI in the verification path

PSI is a modifier to the composite trust score that drives access decisions, and never a gate.

The access decision is never derived from PSI alone. A user with a momentarily volatile PSI but a strong passkey assertion and a verified VC is still allowed. The signal is contributory, not dispositive—the same composition rule we apply to every other Pillar I signal.

Limits of PSI

This is as important as what PSI does.

• PSI does not identify which profile is active. The hashed event tuples are device-scoped and carry no operator identifier in cleartext. We cannot tell a regulator, a court, or anyone else which profile a user has enabled.
• PSI does not block legitimate travel. A traveler entering the "Volatile" band is asked for a fresh passkey assertion; service continues. The default action is friction.
• PSI does not require carrier participation. It works from device-side LPA/IPA event metadata via our SDK, with carrier-side event sources via GSMA Open Gateway / CAMARA as a strict augmentation.
• PSI does not replace SIM-swap detection. It complements it. The two signals catch different phases of the same underlying threat—SIM-swap APIs see the back-office change; PSI sees the device-side acceptance.

PSI alongside other signals

The Profile Stability Index is one of several Pillar I signals our platform composes into the combined trust coefficient. It is most useful when paired with:

• Carrier signal fusion across multiple MNO-facing APIs to cross-reference what the network reports against what the eUICC reports.
• Verifiable credential cross-referencing so that a high-PSI device can present a stronger composite proof to a relying party.
• Passkey-bound biometric assertions so that a Volatile-band PSI triggers a meaningful step-up rather than a notification users will dismiss.

Considered together, these signals turn the eSIM ecosystem's most ambiguous behavior—profile switching—into one of its most informative.

Operational notes

A few details that matter for teams considering deployment.

• Sliding window length. 30 days is our default; for IoT fleets under SGP.32, a 90-day window produces a more stable index because legitimate IoT profile switches are rare events.
• Bootstrap period. New devices need approximately 14 days of event history before PSI is meaningful. During the bootstrap, PSI defaults to the cohort median rather than 0.0, to avoid penalizing genuinely new users.
• Tenant calibration. PSI bands are tunable. A consumer fintech might raise the step-up threshold to 0.65; a high-assurance enterprise SSO might lower the cascade threshold to 0.35. We ship sane defaults; the bands are configuration.
• Audit. Every PSI computation produces a single audit row containing the device-scoped hash, the resulting band, and the input event hashes. The raw event tuples are not retained after the sliding window expires.

Summary

eSIM profile switching is the signal. Treated as a binary alert, it generates noise that overwhelms response teams and trains users to dismiss step-up prompts. Treated as a continuous, multi-component index over Zero-PII event metadata, it becomes one of the strongest device-side trust signals available in 2026.

The Profile Stability Index is our answer to the question of how to read eUICC behavior without reading the user. It works under SGP.22 for consumer devices, under SGP.32 for IoT fleets, and integrates cleanly with the other Pillar I signals that compose our trust coefficient. The standards that enable the multi-persona future also produce the audit trail that secures it—provided someone reads it.

Read the PasskeyBridge solutions overview for the complete pillar architecture, or start a free tenant to ingest your first eUICC event.

Start free · Test the API