What Is a Removable eUICC?

Short answer: an eUICC is a UICC that can have operator profiles downloaded, enabled, disabled and deleted remotely. GSMA SGP.06 defines it as "a removable or non-removable UICC," and SGP.21 v3.x carries an explicit field called "eUICC Form Factor Type" whose permitted values are removable or non-removable. The "e" originates from "embedded" but does not mean the chip is soldered down. A removable eUICC in a 4FF card body is a form factor the architecture names, not a workaround it tolerates.

Disclosure: published by Switch eSIM, which sells removable eUICC cards. That gives us an obvious interest in the conclusion above, so this article quotes the normative text directly and version-pins every quote so you can check it. It also states plainly what being spec-permitted does not guarantee — see "What compliance does and doesn't cover."

The normative citations

This is the part worth bookmarking. Definitions changed between spec versions, so the version matters as much as the quote.

Document	Version	Term	Text
SGP.06	v1.1 (2023)	eUICC	"A removable or non-removable UICC which enables the remote and/or local management of Profiles in a secure way. NOTE: The term originates from 'embedded UICC'."
SGP.21	v3.0 / v3.1	eUICC Form Factor Type	"Defines the eUICC Type which is either removable or non-removable."
SGP.21	v2.3–v2.5	Discrete eUICC	"An eUICC implemented on discrete standalone hardware, including its own dedicated volatile and non-volatile memory. A Discrete eUICC can be removable or non-removable."
SGP.21	v2.5	eUICC	"A UICC which enables the local management of Profiles in a secure way."
SGP.21	v3.1	eUICC	"A UICC which enables the remote and/or local management of Profiles in a secure way."
SGP.21	v2.x / v3.x	Form Factor	"Physical manifestation of the UICC."
SGP.21	v2.x	BAS3	Security "SHALL at all times and under all circumstances be at least equivalent to the current removable UICC and its provisioning processes."
SGP.21	v2.x	PRO1	"Profiles are the property of and SHALL be under the control of the issuing Operator."
SGP.21	v2.x	PRO2	"A Profile does not exist outside of an eUICC. I.e. a Profile is always located on a particular eUICC."
SGP.21	v2.x	PRO6	"It SHALL be possible to delete Profiles only when in a disabled state."
SGP.21	v2.x/v3.x	(scope note)	"Unless stated otherwise, the word eUICC in this specification refers to a Certified eUICC."

Four things fall out of that table.

"Form Factor" is defined as physical manifestation, and eUICC is defined without reference to it. The two concepts are deliberately orthogonal in the architecture. This is the whole argument in two definitions.

The definition broadened, not narrowed. SGP.21 v2.5 said "local management"; v3.1 says "remote and/or local." The spec moved toward describing a management capability, further away from describing a package.

Removable UICC is the security baseline, not the adversary. BAS3 benchmarks eUICC security against the removable UICC. The plug-in card is the yardstick.

PRO1 and PRO2 explain a lot of consumer confusion. Your profile is the operator's property and cannot exist off the eUICC. There is no such thing as backing one up and restoring it elsewhere. PRO6 also confirms something we covered previously: disable is a mandatory precondition for delete, which is why those two operations are architecturally distinct rather than two intensities of the same thing.

UICC vs eUICC vs eSIM vs MFF2 vs iSIM

These five terms are routinely used as synonyms. They describe different layers.

Term	What layer	Defined where
UICC	The smart card platform — hardware plus OS, hosting applications like USIM/ISIM	ETSI TS 102 221
eUICC	A UICC with remote/local profile management. A capability.	GSMA SGP.21 / SGP.06
MFF2	A soldered surface-mount SIM package, 6.00 × 5.00 mm. A shape.	ETSI TS 102 671
eSIM	Industry shorthand, usually meaning "MFF2 containing an eUICC." Not a precise term.	No single normative definition
iSIM	eUICC function moved inside an SoC's integrated Tamper-Resistant Element	GSMA integrated-eUICC path (SGP.08 / SGP.18)

The detail that settles the argument: MFF2 is specified in ETSI TS 102 671, titled "Machine to Machine UICC; Physical and logical characteristics." It defines two packages, MFF1 (suited to socketing) and MFF2 (with a central heatsink area), and specifies that an MFF "shall conform to the electrical specifications of the UICC-Terminal interface as defined in TS 102 221."

It is a packaging and electrical document. It says nothing about remote provisioning. An MFF2 package does not make something an eUICC, and a removable card body does not stop something from being one. Soldered-but-single-profile MFF2 SIMs exist; they are eSIMs by shape and not eUICCs by capability. The two properties genuinely vary independently.

Note also that MFF1 is "well adapted for socketing" — the M2M spec anticipated a removable soldered-format SIM from the outset.

Form factor table

Name	Also called	Dimensions (mm)	Spec
1FF	ID-1, full-size	85.6 × 53.98	TS 102 221 §4.1 (ID-1 UICC)
2FF	Mini-SIM, plug-in	25 × 15	TS 102 221
3FF	Micro-SIM, Mini-UICC	15 × 12	TS 102 221 §4.0.3
4FF	Nano-SIM	12.3 × 8.8	TS 102 221 §4.0.4
MFF1	—	see spec; 0.50–0.65 thick	TS 102 671 §6.2.1
MFF2	"the eSIM chip"	6.00 × 5.00 (±0.15)	TS 102 671 §6.2

Any of these can, in principle, host an eUICC. Removable eUICC cards are typically supplied in a 4FF body, often with 2FF/3FF adapter frames. Only the MFF1/MFF2 figures and the TS 102 221 section headings were verified in this session — the 2FF/3FF/4FF dimensions are the widely published values and I did not open the clause text to confirm them.

How remote SIM provisioning actually works

The consumer architecture (SGP.21 for architecture, SGP.22 for the technical spec) has a small cast.

SM-DP+ — Subscription Manager Data Preparation+. Prepares the profile, binds it to one specific EID, and delivers a Bound Profile Package. Binding is why a downloaded profile can't be diverted to a different eUICC: cryptographically it is addressed to yours.

SM-DS — Subscription Manager Discovery Server. Solves "how does the device know a profile is waiting without a QR code?" An operator or SM-DP+ registers an Event Record; the device's LPA queries the discovery server and is pointed at the SM-DP+ to collect. Thales describes the GSMA's root discovery service as letting operators register the SM-DP+ address and event ID against the customer's EID, so the user supplies only their EID and no QR scan is needed. Dell's Windows documentation shows the consumer-visible version of this — "Search for available profiles," with a configurable discovery server address, and a notably unhelpful generic error when nothing is found.

LPA — Local Profile Assistant. The component that talks to the servers and to the eUICC, comprising the LPD (download), LDS (discovery) and LUI (user interface). It can live in the device (LPAd) or on the eUICC (LPAe).

Activation code — defined in SGP.22 §4.1. It is a delimited string, not a number. The LPA: URI scheme is defined for the same purpose, and Microsoft documents lpa:[activation code] as launching the OS activation flow from a camera, browser or email link. The field structure, per Osmocom's pySim ActivationCode implementation of §4.1, is: SM-DP+ hostname, token, optional OID, optional confirmation-code-required flag.

Two useful consequences. First, a QR code contains no certificate and no profile — only an address and a token, which is why a QR code is small and why it is usually single-use. Second, the interface names in the table below are the vocabulary to search with when debugging, because vendor error messages rarely name them.

Interface	Between
ES2+	Operator ↔ SM-DP+
ES6	Operator ↔ eUICC
ES8+	SM-DP+ ↔ eUICC
ES9+	SM-DP+ ↔ LPD
ESeu	End User ↔ LUI

Why a removable eUICC is standards-compliant

Assembling the citations: the eUICC is defined by management capability (SGP.06, SGP.21); "Form Factor" is separately defined as physical manifestation; a Discrete eUICC "can be removable or non-removable"; and SGP.21 v3.x carries a dedicated eUICC Form Factor Type field precisely so an implementation can declare which it is.

An architecture that needed a field to record "removable or non-removable" is an architecture that expected both to exist.

There is also a practical proof: these cards download profiles from commercial SM-DP+ servers. Under SGP.22, an eUICC must present a certificate chaining to a GSMA Certificate Issuer for mutual authentication to succeed. A card that could not do this would fail at authentication, before any profile transfer. Osmocom's eUICC manual maintains a public list of known eUICC cards and their CI key IDs and expiry dates — including SGP.26 test CI keys — which is the practical register of what's out there.

What compliance does and doesn't cover

Here is the caveat that most vendor pages on this topic omit, including, historically, ours.

"The spec permits removable eUICCs" is a statement about the standard. It is not a certification claim about any particular product. SGP.21 explicitly notes that "the word eUICC in this specification refers to a Certified eUICC," certified under the GSMA compliance programme (SGP.24), with security evaluation under the eUICC Security Assurance scheme in SGP.06 against protection profiles such as PP-0089 and PP-0100. Whether a given consumer card holds current SGP.24 certification and eSA evaluation is a per-product, per-version question — one I was not able to verify for any removable card, ours included, before publication.

If you're buying, that is the question to ask a vendor: not "is it GSMA-compliant," which is nearly meaningless, but "is this eUICC SGP.24-certified, and under which protection profile was it evaluated?"

And the genuinely awkward part, which is not about the form factor at all: on most phones a removable eUICC cannot use the device's built-in LPA. The card is driven by a companion app acting as the LPA, or by SIM Toolkit menus. That app path — its access rules, its permissions, its continued existence — is where the real practical compromises of removable eUICCs live. The card body is spec-clean. The provisioning path around it is where you should direct your scepticism.

Glossary

Bound Profile Package — a profile encrypted and bound to one specific EID by the SM-DP+.
ECASD — the eUICC's root security domain holding its credentials and CI public keys.
EID — eUICC Identifier; the permanent identity of the chip, not of any subscription. Often retrievable via *#06#.
EUM — eUICC Manufacturer; issues eUICCs and holds an EUM certificate chaining to a GSMA CI.
GSMA CI — Certificate Issuer; the trust root for RSP.
ICCID — identifies a profile on an eUICC, per ITU numbering. Not the card ID.
ISD-P — Issuer Security Domain–Profile; the isolated container one profile lives in.
ISD-R — Issuer Security Domain–Root; the on-card function that creates, enables, disables and deletes ISD-Ps.
LPAd / LPAe — LPA in the device / on the eUICC.
LPD / LDS / LUI — the LPA's download, discovery and user-interface functions.
Profile — operator data and applications (USIM, often ISIM, files, keys, optional applets) inside an ISD-P.
PPR — Profile Policy Rule; operator-set restrictions, e.g. barring deletion.
RSP — Remote SIM Provisioning: downloading, installing, enabling, disabling and deleting profiles.
TRE — Tamper-Resistant Element; the hardware security boundary. Integrated TREs underpin iSIM.

Glossary entries are drawn from SGP.21 and SGP.22 terminology. The SGP.21 items in the citations table were quoted from source in this session; the security-domain definitions (ISD-R, ISD-P, ECASD) are standard SGP.22 vocabulary that I did not re-open the clause text to confirm.

Limitations

Every quote in the citations table came from GSMA PDFs retrieved in this session, but definitions differ across SGP.21 versions and I have pinned versions for that reason — check the version you care about rather than assuming. Certification status of any specific removable card, including Switch's, is unverified. 2FF/3FF/4FF dimensions are unconfirmed against clause text. The activation-code field structure is taken from pySim's implementation of SGP.22 §4.1 rather than from the clause itself. I did not verify whether SGP.21 v3.x retains the exact BAS3 and PRO1/PRO2/PRO6 wording quoted from v2.x, so treat those as v2.x citations. No product was tested.

Learn more:

Back to blog

Item added to your cart