From SIM Card to eSIM: How Network Identity Stopped Being a Card

The card was a container for a file system

The document that describes what a SIM is, rather than what it looks like, is GSM 11.11 — the specification of the Subscriber Identity Module to Mobile Equipment (SIM–ME) interface, produced by ETSI's Technical Committee SMG. It is worth being precise about the provenance, because this is an easy thing to get visibly wrong: GSM 11.11 is an ETSI deliverable, not an ISO or ITU-T one. It normatively references the ISO 7816 series for the physical card it sits on, but the behaviour it specifies is committee output of the European telecommunications standards process.

It is also worth being precise about which GSM 11.11 anyone means. ETSI hosts a version series — v5.0.0 dated December 1995, v5.1.0 dated March 1996, v5.3.0 dated July 1996, and others besides. None of these is the founding Phase 1 document; the Phase 1 work predates them. The July 1996 PDF is the most convenient copy to read, not the origin of the idea, and describing it as "the original SIM specification" is a common and avoidable error.

What that document actually establishes is a filing system. Clause 3.1 defines three object types: a Master File at the root, Dedicated Files that act as directories beneath it, and Elementary Files that hold data. (The specification explicitly marks the older terms "root directory" and "data field" as obsolete — the tidying-up of vocabulary that happens once a design has settled.) Clause 10, "Contents of the Elementary Files (EF)", then enumerates what lives where. The card is not a key fob with a number printed inside it. It is a small, addressable, hierarchical store, and the handset navigates it by file identifier.

The most consequential entry in that table is the first one. EF_IMSI is what identifies a subscriber to the network. The number a person gives out — the one on a business card, the one that rings — is a different quantity entirely, held in a separate and optional elementary file that operators frequently leave unwritten because nothing depends on it. "The SIM stores your phone number" is the near-universal popular belief about these cards, and it is close to backwards. The SIM stores the credential the network uses to decide whether you exist; the number you recognise as yours is a routing convenience layered on top of that credential.

Underneath the IMSI sits the thing that makes the identity worth anything. Clause 7 of GSM 11.11 states that a subscriber authentication key Ki is used in the authentication procedure, that this key has a length of 128 bits, and that it is stored within the SIM. What the specification conspicuously does not do is provide a way to read it out. There is no SELECT-then-READ path to Ki. Instead clauses 8.16 and 9.2.16 define a command called RUN GSM ALGORITHM: the handset hands the card a challenge, the card computes internally, and the handset receives a response and a ciphering key. The secret is consumed inside the module and never crosses the interface to the phone.

The awkward question of who made the first one

The ancestry of the chip card itself is genuinely contested and should be presented that way. The earliest filing usually put forward is German patent application DE1945777, "Identifizierungsschalter", naming Jürgen Dethloff and Helmut Gröttrup as inventors, with a priority date of 13 September 1968, a filing date of 10 September 1969 and publication on 2 July 1970. Against it stand Roland Moreno's French filings of 1974 and Kunitaka Arimura's Japanese work of 1970. The patent record supports "earliest filed" for Dethloff and Gröttrup. It does not settle "who invented the smart card", and no honest account of this period pretends that it does.

The SIM-specific claim is a different kind of claim and needs a different kind of caution. Giesecke+Devrient's own 2021 press release states that the company delivered the first commercial SIM card in 1991 to a Finnish GSM operator, describing it as being about the size of a credit card with a plug-in section that could be broken out. That is a manufacturer's account of its own manufacturing milestone, published by an interested party three decades after the fact. It is credible as a supply claim and it is not an invention claim: the specification work behind the SIM was ETSI committee output, and GSM 11.11's own title page credits ETSI TC-SMG as its source. "The first commercial SIM cards were supplied by G+D" is defensible. "G+D invented the SIM" is not the same sentence.

1998: the secret was extractable, but not from a distance

The design decision to keep Ki inside the card was sound, and it was tested in public in April 1998. The Smartcard Developer Association, working with the ISAAC group at UC Berkeley, issued a press release marked "for release not to precede 1998 April 13" announcing that they had cloned a digital GSM phone. Their own description of the mechanism is careful: "GSM phones have a small smartcard inside them which holds the identity of the cellphone... The breach allows the extraction of the secret inside the SIM, after which the secret may be inserted into a different SIM."

Read that carefully and the boundaries of the result are visible in the wording. It was a break of the authentication algorithm, not of the card's refusal to hand over its key. The companion technical page the same group published, headed "GSM Cloning", puts a price on the break: "Mounting this attack requires physical access to the target SIM, an off-the-shelf smartcard reader, and a computer to direct the operation. The attack requires one to query the smartcard about 150,000 times; our smartcard reader can issue 6.25 queries per second, so the whole attack takes 8 hours." The 1998 press cycle compressed that into "GSM phones can be cloned", which was misleading in exactly the way that matters: the demonstrated attack took eight hours with the card in the attacker's hand, and nothing was extracted over the air. The same page now carries a note its authors added after publication, conceding that the original announcement understated the risk of over-the-air attacks — a qualification worth carrying with the quotation rather than dropping.

The architecture, in other words, behaved as designed: the interface held, and the weakness lay in an algorithm the interface specification had deliberately declined to standardise. The attacker still had to hold the object in their hand — which, in 1998, was what possessing an identity meant.

From SIM to UICC: the module became an application

The vocabulary shifted before the delivery mechanism did, and anyone writing about post-2000 behaviour needs to follow it. ETSI TS 102 221 specifies a UICC–terminal interface: a generic smart-card platform with physical and logical characteristics of its own, no longer a SIM-specific document. On top of that platform, 3GPP TS 31.102 — published by ETSI as TS 131 102 — specifies the characteristics of the USIM application. The distinction is not pedantry. After this point the card is a UICC, and the SIM or USIM is an application running on it. Statements about modern behaviour that cite GSM 11.11 are citing a document that had already been superseded as the platform specification.

This matters for what comes next, because a platform that can host one telecom application can host several, and can in principle have applications added to it after issue. That capability did not originate with mobile networks. GlobalPlatform's Card Specification defines the security-domain model — an issuer security domain and subordinate domains — expressly to support dynamic post-issuance card management, the addition and modification of applications on a card already in the field. The building block that remote SIM provisioning would eventually need already existed in the general smart-card world.

Remote provisioning arrived three times, not once

The single most common error in writing about eSIM is to date it to 2016 and treat it as one system. The specifications' own document-history annexes say otherwise. There are three architectures, published nearly a decade apart, addressing three different classes of device, and they do not work the same way.

1. 19 December 2013

   GSMA SGP.02 v1.0, the remote provisioning architecture for embedded UICCs in machine-to-machine deployments. Profiles are pushed to the device under operator control; there is no user in the loop and no user-facing component on the device.

2. 13 January 2016

   GSMA SGP.22 v1.0, the consumer remote SIM provisioning specification. The device pulls a profile from a delivery server through a local profile assistant that runs on the device itself, with an optional discovery server to tell the device that a profile is waiting.

3. 26 May 2023

   GSMA SGP.32 v1.0, the eSIM IoT specification. It addresses devices that have neither a user interface for the consumer flow nor the network assumptions of the M2M flow, introducing an IoT remote manager (eIM) and a profile assistant (IPA) in device-resident and eUICC-resident variants.

The practical consequence is that a sentence like "the SM-SR downloads the profile to your iPhone" is simply wrong. The secure-routing server belongs to the M2M architecture, which predates the consumer one by more than two years and was never intended for a handset with a screen. Consumer devices use the pull model: the local profile assistant, running as part of the device, contacts a delivery server and requests the profile, and the eUICC installs it.

What is actually inside a downloaded profile

Here is the point where the popular story and the specification part company. The popular story is that eSIM replaced the SIM file system with something modern. SGP.22 v3.1's §2.4 description of the eUICC architecture says the opposite. The eUICC hosts a set of security domains — a root domain that manages profile installation, a per-profile domain that each installed profile occupies, and a controlling domain that holds the eUICC's own credentials — together with a profile package interpreter, a telecom framework, and a rules enforcer. And each installed Profile contains, in the specification's own decomposition, its own File System, its own network access applications, and its own applets.

In other words, EF_IMSI is still in there. The Master File, the Dedicated Files, the Elementary Files, the file identifiers — the whole GSM 11.11 inheritance rides inside the downloaded profile, because that is what a telecom identity has to look like for a network to recognise it. Nothing about the radio side changed. What changed is that the file system arrives over an authenticated channel instead of arriving in an envelope, and that several of them can sit on one chip at once, each in its own security domain, only one normally enabled.

Embedded does not mean soldered

"eSIM" is a marketing word, and it has quietly welded together two properties that are independent of each other. The standards term is Embedded UICC: ETSI TS 103 383 is titled "Embedded UICC; Requirements Specification", and what makes a UICC embedded in that sense is that it can be provisioned remotely. Physical mounting is a separate axis entirely. ETSI TS 102 671 specifies solder-down machine-to-machine UICC form factors, and a chip permanently mounted to a board under that specification is not thereby an eSIM. Conversely, eUICCs are manufactured and sold in ordinary removable 4FF card bodies — hardware that is remotely provisionable and physically removable at the same time.

So the two axes are: can this thing receive a profile over the network, and is it stuck to the board? "eSIM" answers the first question. It says nothing reliable about the second. A third term, iSIM, describes integrating the secure element into the system-on-chip itself and is a further, distinct step; it is not a synonym for eSIM, and folding the three words together is how a reader ends up believing that remote provisioning and permanent mounting are the same development.

Who gained the authority

The framing that usually accompanies eSIM is emancipation: the user, freed from the carrier's plastic, now controls their own identity and can switch operators at will. The specification is a more interesting document than that. SGP.22 v3.1's §2.9 profile policy management defines Profile Policy Rules that can be attached to a profile, and the first two of them are stated in the specification in terms that leave nothing to interpretation: PPR1, "Disabling of this Profile is not allowed", and PPR2, "Deletion of this Profile is not allowed". Whether such rules may be set is governed by a Rules Authorisation Table on the eUICC, and enforcement is performed by a profile rules enforcer inside the chip. The capability to lock a subscriber to a profile is not an oversight in the design; it is a specified feature with an enforcement component.

The second shift is quieter. In the consumer architecture, the local profile assistant is a device component — it sits outside the eUICC, on the handset, in the ordinary configuration. That means the software that discovers profiles, presents them, downloads them, enables them and deletes them is supplied by whoever supplies the operating system. A step that used to be performed by a fingernail and a paperclip is now performed by vendor software, through a vendor interface, on vendor terms. The handset maker did not previously sit between an operator and a subscriber's identity in any meaningful way. It does now.

The third shift is structural. Remote provisioning is a public-key system, and someone has to be the certificate issuer. The GSMA-governed certificate authority for this ecosystem determines which entities may operate a compliant delivery server at all. Running a profile-delivery service is therefore not a matter of standing up software against a published protocol; it is a matter of admission. Whatever else that is, it is not decentralisation.

The honest summary, then, is redistribution rather than liberation. Before, the operator controlled the identity by controlling a physical object, and the user's power was the crude but real power of removing it. After, the operator can attach policy to the profile, the device vendor controls the software that performs every profile operation, and a certificate authority controls who may issue profiles in the first place. Users did gain something concrete — the ability to hold several profiles, and to acquire one without visiting a shop — but they gained it inside a structure with more gatekeepers in it than the one it replaced, not fewer.

What a profile buys, and what it does not

This archive is about documents and the machines that produce them, so it is worth being exact about what a provisioned cellular identity delivers to someone whose office is a phone. It delivers a routed path to the internet through an operator's core network. It does not deliver a link. The device shares no segment with anything; it has an address reachable through a carrier network, which is a categorically different relationship from the one a laptop has with a printer two metres away.

That distinction is why printer discovery, as the archive documents it in depth, stops at the edge of the local network. The announce-and-browse mechanisms that make a printer appear in a list — multicast DNS with DNS-based service discovery, and WS-Discovery alongside it — depend on multicast within a single link, and a phone on a cellular bearer shares no link with an office printer. No amount of connectivity fixes this, because it is not a bandwidth or reachability problem but a topology one, and it long predates eSIM. What does work across a routed path is the hosted-queue model: a service holds the job, and the printer or an on-premises connector makes an outbound connection and pulls it down. The mobile worker's print path and the mobile worker's network identity are answers to two different questions.

The consumer download flow described above is also the mechanism behind a now-ordinary travel experience. SGP.22 v3.1 §4.1 defines an activation code — the string a local profile assistant consumes to know which delivery server to contact — and in practice that string is handed to a user as a QR code. That is the entire reason a profile can be bought as an email rather than collected as an object: services such as Esimky sell a data profile and deliver an activation code, and what happens next on the traveller's handset is the SGP.22 pull described in this article, running unchanged. It is also the reason the caveats above are not academic. A profile acquired that way still arrives subject to whatever policy rules its issuer attached, still installs through software the handset vendor wrote, and still originates from a server someone had to be admitted to operate.

Which brings the arc back to where it started. For thirty years the unit of network identity was an object you could hold, lose, snap out of a credit-card-sized carrier, and hand to someone else. It is now a file system that arrives over a channel. The contents did not change; EF_IMSI is still at 6F 07 inside the profile that lands on the chip. What changed is that identity became something granted rather than something possessed — and that is a larger shift than the disappearance of a piece of plastic, even if it is the plastic that everyone noticed.