How an eSIM actually works.

Nothing is downloaded that you would call a SIM

The common mental model is that an eSIM is a virtual SIM card — a plastic chip converted into a file and sent over the internet. It is a reasonable guess and it is wrong in a way that matters.

There is a physical chip. It is called an eUICC, it is soldered to the phone's logic board, and it cannot be removed. It was there when you bought the device and it will still be there when you sell it. Nothing about it is virtual.

What you download is a profile: the subscription data that used to be etched onto a plastic card at a factory, now delivered over the air into a chip that stays put. The card became permanent so the subscription could become portable. That inversion is the whole idea.

The SIM stopped travelling so the subscription could.

The inversion at the centre of eSIM

What was actually on the plastic

A traditional SIM was never just an identifier. It was a secure element — a tiny tamper-resistant computer with its own processor, storage and operating system, running applets. The plastic was packaging.

Four things lived on it, and all four now live inside a downloaded profile:

• ICCID
  The serial number of the subscription itself. This is what identifies a specific eSIM you have sold — the number your inventory system tracks.
• IMSI
  Your identity on the mobile network, stamped with a country code and an operator code. This is the field that makes a subscription national.
• K — the secret key
  A shared secret known only to the chip and the operator's authentication centre. It never leaves the secure element. Not once, not ever. Everything else about mobile security rests on this.
• Operator files
  Network selection rules, preferred roaming partners, APN settings, branding. The quiet layer that decides how the device behaves.

A profile is these four things, packaged and encrypted for delivery. That is all it is — and it is worth remembering that a profile is a genuine cryptographic asset, not a config file.

eUICC, and the number that identifies it

The eUICC — embedded universal integrated circuit card — is the secure element that receives profiles. Its defining capability is not that it is small or soldered. It is that it can hold several profiles at once and switch between them, which a plastic SIM never could.

Every eUICC carries a permanent 32-digit identifier called the EID. Unlike the ICCID, which belongs to a subscription, the EID belongs to the hardware and never changes. It is how a provisioning server knows which specific chip in the world it is talking to — and, as we will see, it is the reason profiles cannot be copied around.

Three components do all the work

Remote provisioning involves surprisingly few moving parts. Learn these three and the rest of the system becomes readable.

• SM-DP+
  Subscription Manager — Data Preparation. The operator-side server that generates profiles, holds them in inventory, and delivers them. When a network makes a batch of eSIMs available for sale, this is where they physically sit, waiting. It is the supply side.
• LPA
  Local Profile Assistant. Software running on the phone. It reads QR codes, talks to the SM-DP+, requests the download, and gives you the interface where profiles are listed and switched. On most phones this is built into the operating system.
• SM-DS
  Discovery Server. A lookup service the device can poll to ask whether any profile is waiting for its EID. It exists so provisioning can happen without a QR code at all — the mechanism behind eSIMs that appear on a device with no scanning.

There is a fourth participant that never appears in a diagram: the GSMA root of trust. Every eUICC and every SM-DP+ ships with certificates signed by a common authority. Neither side will talk to the other without proving its certificate chain. This is what stops anyone from standing up a server and pushing profiles onto phones.

What happens in the eight seconds after you scan

That QR code is not the eSIM. It is a short text string — an activation code — containing an address and a one-time token. Roughly this shape:

# the entire contents of a typical eSIM QR code
LPA:1$rsp.operator-example.com$K2-8FQ3-9XZM-7T
      └─ SM-DP+ address ─┘  └─ matching ID ─┘

Two fields: where to go, and which pending profile to claim. Everything else is negotiated live.

1. The LPA parses the codeIt extracts the server address and the matching ID. Nothing has been downloaded yet.
2. Both sides prove who they areThe device and the SM-DP+ exchange certificates and verify them against the shared GSMA root. A server that cannot prove its chain gets no further; neither does a chip.
3. The chip identifies itselfThe eUICC sends its EID and a signed statement of its capabilities — how much space it has, which profile types it supports.
4. The server binds the profileThe pending profile is cryptographically bound to that specific EID. From this moment the profile is useless on any other chip on earth.
5. Encrypted deliveryThe profile is transmitted in segments over a secure channel. The phone's operating system relays the bytes but cannot read them — decryption happens inside the secure element.
6. InstallationThe eUICC decrypts and installs the profile into its own storage. The secret key is written into a region nothing outside the chip can read.
7. Enable, then attachYou select the profile. The chip presents the new IMSI to the radio, and the phone registers on the network exactly as a plastic SIM would.

Why the key never moves

Once installed, connecting to a network works exactly as it always has, and the elegance of it is worth appreciating. The network never asks for your secret key, and the chip never sends it.

Instead the network sends a random challenge. The chip performs a calculation using the key and returns the result. The operator's authentication centre, which holds the same key, performs the identical calculation. If the answers match, you are authenticated. In modern networks the proof runs both ways — the network also proves itself to the chip, which is what prevents a fake tower from harvesting subscribers.

The consequence is that the key can never be extracted by intercepting traffic, because it is never in the traffic. This is why an installed profile is genuinely secure, and equally why it cannot simply be exported and moved to another phone.

Why transferring an eSIM is so unpleasant

Everyone who has changed phones has met this. A plastic SIM moves between devices in four seconds. An eSIM requires deleting, re-issuing, sometimes contacting support.

That friction is not bad engineering. It is the binding from step four, working as designed. The profile was cryptographically married to one EID; a different phone has a different EID and the profile is meaningless to it. Transfer therefore is not a copy operation — it is a re-issue, which has to be authorised by whoever issued it.

That last row is the one most people miss, and it is the one that matters commercially. eSIM did not abolish inventory. It moved it. Profiles must still be generated in advance, stored, tracked, allocated, and eventually expired — the stock room simply became a server.

And the part that is still missing

Strip away the acronyms and eSIM did exactly one commercially significant thing: it made a mobile subscription deliverable over the internet. A network in one country can now put a working subscription into a device in another country, in seconds, with no shop, no shipping and no border crossing for the object.

Which raises the obvious question — if a subscription can be delivered anywhere instantly, why is buying travel data still fragmented, opaque and expensive?

Because delivery is not distribution. The technical channel exists; the commercial one largely does not. A network holding profile inventory has no standard way to make it available to a travel agency in Kerala, a booking platform in Singapore or a retail counter in Dubai — no shared method for pricing, allocating, provisioning and settling at scale, in real time, across parties who have never signed a bilateral contract with each other.

The chip problem was solved a decade ago. The layer above it is the one still being built.