eSIM and eUICC Explained: SGP.22, SGP.32, SM-DP+ and iSIM

An eSIM is a SIM whose operator profile is downloaded over the network instead of arriving on a plastic card. The chip that holds those profiles is the eUICC, and GSMA specifications define how profiles reach it: SGP.22 for phones and other consumer devices, SGP.32 for IoT devices managed by a remote eIM. An iSIM is the same idea built into the device's main system on chip.

This post goes one level below our 5G security architecture explainer, which covers how the network authenticates a subscriber, and sits next to our cellular baseband firmware post, which covers the modem that talks to the SIM. Here we stay on the SIM itself: what is on the chip, how a profile is built, protected and delivered, how the IoT model differs from the consumer one, how the chips are certified, and what all of that does and does not do for SIM swap fraud.

Key takeaways

• A UICC is the smart card platform defined by ETSI TS 102 221; the SIM or USIM is an application running on it. An eUICC is a UICC that can hold several operator profiles and accept new ones remotely. "eSIM" usually means the eUICC plus the remote provisioning system around it.
• SGP.22 v3.1 says an eUICC "SHALL be based on Tamper Resistant Element" and may be discrete (a separate chip, removable or soldered) or integrated into a system on chip. The integrated form is what the market calls iSIM.
• In the consumer model, the operator orders a profile from an SM-DP+ server, the user scans an activation code (or the device finds the profile through an SM-DS discovery server), and the Local Profile Assistant (LPA) on the device carries an encrypted, device-bound profile package to the chip.
• Every RSP certificate chains to a GSMA eSIM CA root. The server authenticates first, the eUICC second, and the eUICC must not reveal private data or sign anything before it has authenticated the server. Profile packages are bound to one eUICC with an elliptic curve key agreement and session keys with perfect forward secrecy.
• SGP.31 and SGP.32 (v1.0 in 2022 and 2023, now v1.3 dated 22 May 2026) replace the older SGP.02 machine to machine model. A customer chosen eSIM IoT remote Manager (eIM) sends signed profile commands, and an IoT Profile Assistant (IPA) on the device or in the eUICC carries out downloads.
• eUICCs are certified under GSMA's eSA scheme against the SGP.25 Common Criteria protection profile (published by BSI as PP-0100); personalisation sites and SM-DP+ or SM-DS operators need GSMA SAS accreditation.
• eSIM does not prevent SIM swap. A swap is a carrier account takeover: the attacker convinces the carrier to issue a new profile or SIM. The defences are carrier side authentication, port-out protection and moving your important accounts off SMS codes.

Timeline: the eSIM specifications and the rules around them

Dates come from each document's cover or document history table, the GSMA certification applicability annex and the regulators' own pages.

What are a UICC, a SIM, an eSIM, an eUICC and an iSIM?

The words get mixed up because people use them for the chip, the software on the chip and the service at the same time. Separating them makes everything else easier.

UICC: the platform

The UICC (Universal Integrated Circuit Card) is the smart card platform. ETSI TS 102 221 specifies "the interface between the UICC and the terminal": the physical form factors, the electrical interface, the file system and the command set. Its form factors run from the credit card sized ID-1 card through the plug-in UICC, the mini-UICC and the smallest removable format, which the specification calls 4FF ("fourth form factor"). What most people call a SIM card is a UICC in one of those cut-outs.

SIM, USIM and ISIM: applications on the UICC

The applications that let a phone join a network are network access applications (NAAs). The 3G, 4G and 5G USIM application is specified by 3GPP in TS 31.102; the version uploaded to the 3GPP archive on 1 October 2026 is V20.0.0. A separate application, the ISIM (IP Multimedia Services Identity Module), holds the identities used for IMS services such as voice over LTE and is specified in TS 31.103, currently V19.1.0.

Note the capital letters. ISIM is an application for IMS. iSIM (lower case i) is the marketing name for an integrated eUICC. They are unrelated, and the overlap trips up procurement documents regularly.

eUICC and eSIM: remote provisioning

An eUICC is a UICC built to hold several operator profiles and to accept new ones over the air. GSMA's consumer specification, SGP.22, requires that the eUICC "SHALL be based on Tamper Resistant Element" and that it "SHALL be either a Discrete eUICC or an Integrated eUICC." A discrete eUICC may be removable or soldered to the board. The word "eSIM" normally covers the eUICC and the whole Remote SIM Provisioning (RSP) system: servers, certificates and the device software that talks to them.

iSIM: an eUICC inside the system on chip

SGP.22 defines an Integrated eUICC as "an eUICC implemented on a Tamper Resistant Element (TRE) that is integrated into a System-on-Chip (SoC), optionally making use of remote volatile/non-volatile memory." ETSI's Smart Secure Platform family describes the same hardware class from the other direction: TS 103 666-1 V17.3.0 (June 2023) sets out general SSP characteristics, and its Part 2 defines the integrated SSP (iSSP), an "SSP integrated in the SoC." For integrated eUICCs, SGP.22 requires the device to report a treProductReference that identifies the certified secure element product the eUICC runs on.

What is on the chip

SGP.22 section 2.4 and SGP.32 section 2.4 describe the same internal layout:

• ECASD (eUICC Controlling Authority Security Domain). There is exactly one. The eUICC manufacturer (EUM) installs and personalises it at the factory. It holds the eUICC's private signing key, the eUICC certificate, the EUM certificate and the public keys of the eSIM CA roots used to check servers. SGP.22 requires that its personalisation be "done in a certified 'GSMA SAS-UP environment'."
• ISD-R (Issuer Security Domain Root). It creates new profile containers and manages their life cycle.
• ISD-P (Issuer Security Domain Profile). One per profile; GSMA says this makes it "impossible for any Profile to access the applications or data of any other Profile." Inside sits the operator's own security domain (MNO-SD), the network access applications, the file system and any applets the operator ships.
• Telecom Framework. An operating system service that provides the standard network authentication algorithms to the NAAs. SGP.22 requires support for both Milenage and TUAK.
• Profile Package Interpreter. It turns a standard profile package into the eUICC's internal format.
• LPA Services (or IPA Services in IoT). The interface the device side assistant uses to fetch the EID, list profiles and push packages in.

The Java Card platform and applets

Most SIMs and eUICCs run a Java Card virtual machine under the GlobalPlatform card management model. Oracle describes Java Card as a platform that lets "smart cards and other tamper-resistant chips to host multiple applications," and lists SIM cards and embedded SIMs as a use case. SGP.22 says an eUICC that supports Java Card shall support a defined set of Java Card packages at Java Card 3.0.5 Classic level or later.

The multi-application design is the point and also the exposure. Operators load applets (for example SIM toolkit menus or roaming steering logic) into their own profile. GSMA's July 2025 application note AN-2025-07, now listed as active for all consumer and IoT eSIM products, addresses "Preventing the misuse of an eUICC Profile and the installation of a malicious Java Card Application." In plain terms: a profile that can load arbitrary bytecode, together with a Java Card runtime that does not fully verify it, is a path from one profile into the chip. The fix sits with the EUM and the operator: verify bytecode, restrict who may load applets into a profile, and keep test profiles out of production devices.

Subscriber keys

Each operational profile carries the subscriber identity (IMSI), the profile's ICCID, the secret key K used by the authentication algorithm, the operator constant (OPc) and the parameters the Telecom Framework needs. These secrets never leave the chip in normal operation. The network checks them through the authentication and key agreement procedures covered in our 5G security architecture post.

How is a SIM made, at concept level?

The process differs by manufacturer, but the stages and the hand-overs are the same, and the security controls attach to the hand-overs.

With a removable SIM, a batch of subscriber keys exists outside the card at least once, in the transfer from manufacturer to operator. With an eUICC, the profile is generated at the SM-DP+ and only exists encrypted until it reaches the target chip, but the SM-DP+ becomes a high value system whose site and operations GSMA audits.

How does consumer remote SIM provisioning work?

SGP.21 is the architecture document and SGP.22 the technical specification for consumer devices. The active versions for certification, according to GSMA's applicability annex V3.2.2 (July 2025), are SGP.21 and SGP.22 v3.0 and v3.1.

The roles

• Operator. Owns the subscription and orders profiles.
• SM-DP+ (Subscription Manager Data Preparation plus). Android's documentation calls it a "remote service that prepares, stores, and delivers profile packages to devices." It holds the operator's profile, protects it, binds it to a specific eUICC, and receives notifications after installation.
• SM-DS (Subscription Manager Discovery Server). A directory that tells a device "a profile is waiting for you at this SM-DP+." Root SM-DSs are well known; alternative SM-DSs can cascade to them over ES15.
• LPA (Local Profile Assistant). Device software with three parts in SGP.22 terms: the LPD (download), LDS (discovery) and LUI (user interface). On Android, the LPA is a system app that device makers build by extending EuiccService, and the user facing management screens are its optional LUI.
• eUICC. The chip, with the ECASD, ISD-R and ISD-Ps described above.
• eSIM Certificate Issuer. The root CA whose public key sits in every ECASD.

The interfaces you will see in the specifications

ES10b "plays no role in the decryption of Profile Packages." The LPA moves ciphertext; it cannot read the profile.

Three ways a device finds its profile

SGP.22 describes three entry points. An activation code, usually a QR code, tells the LPA which SM-DP+ to contact and which order to ask for. A default SM-DP+ address may be configured on the eUICC or device. And the SM-DS route lets the device ask the Root SM-DS whether any SM-DP+ has registered an event for its EID. On Android, carrier apps can also drive downloads through EuiccManager methods such as downloadSubscription().

Inside an activation code

SGP.22 section 4.1 defines the format: a format number (always "1"), the SM-DP+ address, and the matching ID, separated by dollar signs, with optional fields for the SM-DP+ OID, a confirmation code flag, an indicator of which eSIM CA root to use, and (since v3.0) a delete notification used during device change. In a QR code it is prefixed with LPA:. The specification's own example:

LPA:1$SMDP.EXAMPLE.COM$04386-AGYFT-A74Y8-3F815
LPA:1$SMDP.EXAMPLE.COM$04386-AGYFT-A74Y8-3F815$$1

The second form sets the "Confirmation Code Required" flag, which means the user also has to type a separate code the operator delivered by another channel. The matching ID ties the download to an order the operator placed; the SM-DP+ "SHALL only process requests containing a MatchingID known to the SM-DP+." That is why an unused activation code is a bearer token: whoever scans it first, on any compatible device, can collect the profile unless the operator has pre-bound it to an EID or required a confirmation code.

The EID

The EID is the eUICC's permanent identifier. SGP.22 section 4.3.1 says it "SHALL be 32 digits long": an EUM identification number, an EUM specific serial, and two final check digits. The check digits use the same remainder on division by 97 method that bank account IBANs use: set the last two digits to zero, compute the 32 digit number modulo 97, and subtract the result from 98. A valid EID gives remainder 1 when divided by 97, so most typos fail the check.

Mutual authentication: who proves what, in which order

SGP.22 section 2.6.2 lays out the rules every RSP connection follows:

1. The server (for example the SM-DP+) is authenticated first, with a certificate chain "ending at an eSIM CA RootCA Certificate."
2. The client is authenticated second. When the client is the eUICC, its own certificate chain is verified the same way. The LPA is not authenticated as a client.
3. "The eUICC, as a Client, SHALL NOT reveal any private data to an unauthenticated Server" and "SHALL NOT generate any signed material before having authenticated the Server."
4. The parties then negotiate a cipher suite, protect all traffic for origin, integrity and confidentiality, and "Session keys SHALL be generated using Perfect Forward Secrecy."
5. The server checks that the authenticated client is authorised for the requested function.

All certificates chain to an eSIM CA root, except TLS certificates, which "MAY instead chain to a Public CA." Revocation is handled by the issuers through CRLs and OCSP.

How the profile is protected on the way

SGP.22 section 2.5 describes four forms of the profile package:

Protection uses the BPP Security Protocol (BSP), which SGP.22 notes "was initially derived from GlobalPlatform's SCP11a." The SM-DP+ and the eUICC each generate one-time elliptic curve key pairs and run an anonymous Diffie-Hellman key agreement per BSI TR-03111. Session encryption and MAC keys are derived from the shared secret with the X9.63 key derivation function and SHA-256, using the EID as part of the input. The BSP "itself does not provide authentication"; that comes from the signatures exchanged in the mutual authentication step.

An operator can have profiles prepared in bulk, protected with random per-profile keys, and stored at the SM-DP+. At download time, those random keys are delivered under the session keys of a specific eUICC, which binds the package to that chip. Either way, the session keys "SHALL be deleted on the eUICC latest at the end of the process."

Profile states, policy rules and multiple enabled profiles

Once installed, a profile is enabled or disabled, and the user or operator can delete it. Profile policy rules (PPRs) let an operator forbid disabling or deleting a profile, and the eUICC advertises which rules it refuses so the SM-DP+ can check eligibility before delivery. SGP.22 v3 adds optional Multiple Enabled Profiles (MEP), "where several Profiles can be in Enabled state," so a device with more than one baseband can use two networks at once. Android added platform support for MEP in Android 13, after adding the standard eUICC APIs in Android 9 and multiple eSIMs in Android 10, according to the Android eSIM implementation guide.

How do the M2M and IoT architectures differ?

SGP.02: the M2M model (2013 to now)

SGP.02 was built for devices with no user at all: meters, vehicles, industrial modules. Its v4.3 (25 January 2023) is the current text. The control sits with an operator side server called the SM-SR (Subscription Manager Secure Routing), which handles every over the air connection to the eUICC: "the OTA communication is exclusively handled by the SM-SR," which may use SMS, CAT_TP or HTTPS. Changing operator means migrating eUICCs between SM-SRs, which needs both operators to cooperate; that burden is a large part of why the IoT architecture exists.

SGP.31 and SGP.32: the eSIM IoT model (2022 to now)

SGP.31 (architecture and requirements) targets IoT devices that are "Network Constrained and/or User Interface (UI) Constrained" and builds on the consumer SGP.21 architecture. SGP.32 is the technical specification. Both reached v1.3 on 22 May 2026. SGP.32 states that it reuses the security features of SGP.22 unless specified otherwise, so the SM-DP+, SM-DS, certificates and bound profile packages are the same as for consumer devices.

The new pieces are:

• eIM (eSIM IoT remote Manager). A server chosen by the device owner or service provider that sends signed commands to the eUICC: enable, disable or delete a profile, list profiles, or change the eIM configuration. These signed bundles are eUICC Packages, carried as Profile State Management Operations (PSMOs) or eIM Configuration Operations (eCOs).
• IPA (IoT Profile Assistant). The IoT equivalent of the LPA. It sits either in the device (IPAd) or inside the eUICC itself (IPAe, optional and EUM specific). SGP.32 says plainly that "LPA ... refers to IPA."
• ESipa and ESep. ESipa is the interface between the eIM and the IPA, used to trigger downloads and carry eUICC Packages. ESep is the logical end to end link from the eIM to the eUICC; the eUICC verifies eIM signatures using the "eIM Configuration Data" stored on the chip for each associated eIM.
• Constrained transports. TLS 1.2 is the minimum for TLS and DTLS 1.2 the minimum for DTLS, with CoAP and MQTT among the referenced transports.
• Fallback and rollback. A fallback profile is enabled if the active one loses connectivity, and a rollback mechanism re-enables the previous profile if the eIM cannot reach the device on a newly enabled one.
• Emergency profile. From v1.2, a profile used only for emergency calls in voice capable devices.

Where IoT risk concentrates

SGP.31 includes an informative threat annex, and it is a good checklist for anyone running a fleet. Among the listed risks: a compromised device or IPA performing illegitimate profile operations or associating an illegitimate eIM (DEV1 to DEV4); a compromised eIM performing "illegitimate PSMO on a number of eUICCs" (CeIM1); a malicious eIM acting as an intermediary (MeIM1 to MeIM3); EID leakage that "may be used to track the location of the IoT Device" (PRI1); and coordinated disabling or switching of profiles that cuts devices off the network (IND3, IND4, INP4). The specification also says device security beyond the eSIM functions is "out of scope," so the device maker owns firmware integrity.

The practical lesson: treat the eIM's signing keys like code signing keys, and the IPA in your firmware like any other privileged component.

How is the eUICC certified and protected?

Three separate assurance tracks apply, and each covers a different object.

The chip: eSA and the SGP.25 protection profile

GSMA's eUICC Security Assurance (eSA) scheme, described in SGP.06 (principles, v2.3 dated 27 May 2025) and SGP.07 (methodology), is "based on the Common Criteria approach to security assurance" but, in GSMA's February 2021 guide, "defines a more dynamic set of procedures." GSMA owns the scheme and operates it under ISO/IEC 17065 with appointed certification bodies and licensed laboratories.

SGP.06 sets the protection profile by product type: consumer and IoT eUICCs evaluate against PP-0100 (SGP.25), M2M eUICCs against PP-0089 (SGP.05), and the underlying chip against the security IC profiles PP-0084 or PP-0117, with the eUICC certificate composed on top. GSMA's applicability annex lists SGP.25 v1.0 as active until 31 December 2027 under one option, with v2.0 (December 2023) and v2.1 (February 2025) active for consumer and IoT eUICCs. Integrated eUICCs have their own evaluation documents, SGP.08 and SGP.18. The eUICC reports which protection profile version it was certified against in its ppVersion field; SGP.22 reserves V255.255.255 for field test eUICCs.

The sites: GSMA SAS

The Security Accreditation Scheme audits places and operations rather than products. SAS-UP (FS.04) covers UICC production and eUICC personalisation sites. SAS-SM (FS.08) covers organisations operating subscription management roles such as SM-DP+ and SM-DS. The eUICC exposes its manufacturer's SAS accreditation number in the sasAcreditationNumber field (that spelling is the specification's).

Functional compliance: SGP.24 and SGP.23

SGP.24 defines functional compliance testing, and SGP.22 requires that after any eUICC OS update, "the eUICC SHALL remain compliant according to the RSP Certification process as specified in SGP.24."

How do SIM swap and eSIM transfer work from a security view?

Our phishing, vishing, smishing and SIM swap explainer and the CSRB Lapsus$ review summary cover the attack patterns. The point here is narrower: where eSIM fits.

A SIM swap is an account takeover at the carrier

The FCC defines SIM swapping as a bad actor convincing "a victim's wireless carrier to transfer the victim's service from the victim's cell phone to a cell phone in the bad actor's possession." Port-out fraud is the variant where the attacker opens an account at another carrier and moves the number there. Neither attack touches the cryptography of the SIM. The carrier, believing the request is legitimate, issues a new profile (or a new plastic SIM) for the victim's number, and the network moves service to it.

eSIM changes the logistics, not the weakness. A carrier that can generate an activation code in a store or in an app can generate one for an attacker who has fooled its verification. That is why "I have an eSIM, so I cannot be SIM swapped" is wrong.

What eSIM transfer adds

SGP.21 and SGP.22 v3 define Device Change: moving a profile from an old device to a new one, with a delete notification for the old copy carried in the activation code. Expect carriers to require a login, a one time code to the existing device, or a store visit.

The FCC rules

On 15 November 2023 the FCC adopted a Report and Order (FCC 23-95, WC Docket 21-341) that revised its customer proprietary network information (CPNI) and number portability rules. The FCC's announcement says the rules "require wireless providers to adopt secure methods of authenticating a customer before redirecting a customer's phone number to a new device or provider" and to "immediately notify customers whenever a SIM change or port-out request is made."

The codified text matters for timing. 47 CFR 64.2010(h), as shown in the eCFR in September 2026, defines a SIM as "a physical or virtual card," so eSIMs are covered. It requires authentication that does not "rely on readily available biographical information, account information, recent payment information, or call detail information," an authentication review at least annually, and employee training on fraudulent SIM change attempts. 47 CFR 52.37 has matching text for port-outs. Both sections also state that compliance "will not be required until this paragraph is removed or contains a compliance date," and the eCFR shows the notification paragraphs as pending amendments. Check the FCC's docket for the current compliance date before you cite these rules as in force.

What still protects you

The controls that work are on the account, not the chip: a carrier account PIN or passcode, port-out protection or a number lock where offered, alerts on SIM change, and moving important accounts off SMS one time codes to passkeys or authenticator apps. A SIM PIN protects a different thing: it stops someone with your physical SIM or phone from using the profile in another device without the PIN. It does nothing against a carrier issuing a new profile.

Comparison: removable SIM, consumer eSIM, M2M eSIM, IoT eSIM and iSIM

Step by step: protect a phone and an IoT fleet

These steps are defensive and read only on the device side. Nothing here clones, extracts or alters a profile.

1. Find the EID

On phones, the EID usually appears on the About screen in Settings, and many phones also display it in response to the *#06# dialler code alongside the IMEI. Menus vary by maker and OS version. Record it with the device serial in your asset inventory. On Android, carrier and enterprise apps can read it through EuiccManager once they hold the right privileges.

Treat the EID as an identifier that should not be posted publicly. SGP.31 lists EID exposure as a privacy risk because it can be used to track a device.

2. Set a SIM PIN

On phones, use the SIM lock setting under the mobile network or SIM settings. Have your carrier's PUK code ready before you start: too many wrong PIN entries lock the profile, and only the PUK unlocks it.

On a cellular modem in an IoT gateway or a lab, the standard 3GPP AT commands (TS 27.007) do the same thing. Use your own test device and your own PIN values.

AT+CPIN?                     # query PIN status: READY, SIM PIN or SIM PUK
AT+CLCK="SC",2               # query whether the SIM PIN lock is enabled (0 = off, 1 = on)
AT+CLCK="SC",1,"1234"        # enable the PIN lock using the current PIN
AT+CPWD="SC","1234","8402"   # change the PIN from the default to a new one

First confirm how a fleet device boots with a locked SIM. An unattended device that cannot enter the PIN will drop off the network after the next reboot. For unattended IoT devices, teams often leave the SIM PIN off and rely on network side controls agreed with the operator, such as a private APN.

3. Lock the account with your carrier

1. Set or change the account PIN or passcode. Do not reuse a number that appears in your public records.
2. Turn on port-out protection or a number lock if your carrier offers it, and write down how to turn it off when you genuinely move.
3. Enable alerts for SIM change, eSIM transfer and port-out requests.
4. Ask which identity checks the carrier uses for eSIM transfer and for new activation codes.
5. Move the accounts that matter (email, banking, cloud, code hosting) off SMS codes and onto passkeys or an authenticator app.

4. Handle activation codes like credentials

Deliver activation codes over a channel that is authenticated to the recipient, prefer codes that require a confirmation code or are pre-bound to an EID, scan them once, and delete the image afterwards. Ask your operator to cancel unused orders.

5. For IoT fleets: inventory eUICCs, firmware and profiles

A fleet that cannot answer "which eUICC OS, which IPA build and which profile is on device 4,812?" cannot respond to an advisory. Keep at least the following per device, pulled from the device's own reporting and from your eIM:

{
  "device_serial": "GW-004812",
  "eid": "<redacted, store in restricted field>",
  "euicc_os_version": "from euiccInfo2 or vendor tool",
  "pp_version": "SGP.25 version reported by the eUICC",
  "ipa": { "location": "IPAd", "firmware_build": "gateway-fw 3.14.2" },
  "eim": { "id": "eim-prod-eu", "config_installed": "2026-03-02" },
  "profiles": [
    { "iccid": "8944...", "state": "enabled", "operator": "operator A", "fallback": false },
    { "iccid": "8931...", "state": "disabled", "operator": "operator B", "fallback": true }
  ],
  "last_reported": "2026-10-26T06:00:00Z"
}

Then:

1. Reconcile the inventory against the eIM's records weekly. A profile the eIM did not order is an incident.
2. Restrict who can sign PSMOs and eCOs on the eIM, require two people for bulk profile changes, and log every package the eIM signs.
3. Set a fallback profile on a different operator for critical devices, and test rollback in a lab before a production switch.
4. Track eUICC OS updates from your EUM and record the post update compliance status, since SGP.22 requires an updated eUICC to remain SGP.24 compliant.

Common mistakes

• Sharing activation QR codes. A code posted in a ticket or group chat is a bearer token anyone can scan first. Use confirmation codes or EID binding, and cancel unused orders.
• No SIM PIN on phones. A stolen phone or SIM can be used in another device to receive calls and one time codes until the profile is suspended.
• Assuming eSIM prevents SIM swap. The attack targets the carrier's identity checks, and eSIM activation codes can be issued just as easily as plastic cards.
• Treating certification as a promise about your deployment. eSA certifies a chip product, SAS certifies sites, and neither covers your device firmware, your IPA build or your eIM.
• Shipping IoT devices without a profile management plan. No fallback profile, no eIM contract, no record of which operator's bootstrap profile is installed: when that operator agreement ends, the fleet is stranded.
• Leaving test profiles or field test eUICCs in production. The ppVersion value V255.255.255 marks a field test eUICC; check for it before shipping.

FAQ

What is the difference between an eSIM and an eUICC?

The eUICC is the chip, a tamper resistant smart card platform that can hold several operator profiles and accept new ones over the air. "eSIM" usually means the eUICC together with the GSMA remote SIM provisioning system that delivers profiles to it, including the SM-DP+, SM-DS and the device's profile assistant.

What is SGP.22?

SGP.22 is the GSMA RSP Technical Specification for consumer devices such as phones, tablets and watches. It defines the interfaces, the activation code format, the EID, the certificate chain and the profile protection protocol. The current version is v3.1, dated 1 December 2023, and v3.0 is also active for certification.

What is SGP.32 and how is it different from SGP.22?

SGP.32 is the GSMA eSIM IoT Technical Specification for devices with limited networks or no user interface. It reuses SGP.22's servers and security, but replaces the user driven LPA with an IoT Profile Assistant and adds the eIM, a remote manager that sends signed profile commands. Version 1.3 is dated 22 May 2026.

What does an SM-DP+ do?

The SM-DP+ prepares, stores and delivers operator profiles. It takes an order from the operator, encrypts the profile, binds it to one specific eUICC with a key agreement, delivers it through the device's profile assistant, and receives a signed notification once the profile is installed.

Is an iSIM more secure than an eSIM?

Not automatically. An iSIM is an eUICC built into a certified secure area of the main system on chip rather than a separate chip. It still has to meet the eUICC security requirements and is evaluated under GSMA's integrated eUICC documents. The security depends on the specific product's certification and on how the device maker protects the SoC.

Does eSIM stop SIM swapping?

No. SIM swapping tricks the carrier into moving your number to a SIM or eSIM the attacker controls. eSIM changes how the new profile is delivered, not who the carrier believes. Use a carrier account PIN, port-out protection and alerts, and move important accounts off SMS codes.

Can someone steal my eSIM profile remotely?

The standards make that hard. Profiles are encrypted and bound to one eUICC, and the eUICC authenticates the server before revealing data or signing anything. The realistic risks are around the process: an unused activation code that someone else scans, or a carrier that issues a new profile to an attacker.

What are the FCC SIM swap rules?

In November 2023 the FCC adopted rules requiring wireless carriers to use secure authentication before a SIM change or port-out, not based on easily found personal data, and to notify customers of such requests. The codified rules say compliance is not required until a compliance date is set, so check the FCC docket for current status.

Where Safeguard fits

Safeguard does not inspect SIM cards, eUICCs or carrier accounts, and it cannot detect a SIM swap. The fit is in the software around the chip. An IoT gateway's firmware image bundles the IPA, the modem manager, the TLS, DTLS, CoAP and MQTT libraries the IPA uses to reach the eIM and SM-DP+, and a Linux userland, almost all of it open source. An eIM or provisioning backend is usually a set of container images. Safeguard can generate and analyse SBOMs for those repositories, firmware build trees and images, match the components against vulnerability databases, show which projects carry a given library version, and gate builds with policies. That gives a fleet team a fast answer to "which of our gateway builds ship the vulnerable TLS library" when an advisory lands. It does not cover the eUICC OS itself, which only the EUM can update.

The remediation section below applies to those components. Firmware images and provisioning backends pull open source libraries on every rebuild, so a fix that is not pinned and shipped is a fix your devices do not have.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos show dependency, image and remediation workflows, not SIM provisioning or carrier accounts. You can download Safeguard and follow the CLI docs to try them on your own projects.

This demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. Pointed at a gateway firmware build tree or the container images of an eIM backend, the same scan lists the packages and versions inside and their known vulnerabilities.

Click through it at your own pace, or open it full screen.

This demo is a real CLI session: ask it to fix the lodash CVE in a repository and watch it read the finding and the advisory, ask before any command that changes something, move lodash to 4.17.21, run npm install and npm test with your approval, and push nothing. The same flow applies when you bump a vulnerable library in the provisioning service or device management dashboard that sits in front of your eIM.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. You can then ask which of your projects ship a particular CoAP, MQTT or TLS library version and get the answer from your own scan data.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• GSMA SGP.22 v3.1, RSP Technical Specification (1 December 2023, PDF)
• GSMA SGP.21 v3.1, RSP Architecture (1 December 2023, PDF)
• GSMA SGP.31 v1.3, eSIM IoT Architecture and Requirements (22 May 2026, PDF)
• GSMA SGP.31 v1.0, eSIM IoT Architecture and Requirements (April 2022, PDF)
• GSMA SGP.32 v1.3, eSIM IoT Technical Specification (22 May 2026, PDF)
• GSMA SGP.32 v1.2, eSIM IoT Technical Specification (27 June 2024, PDF)
• GSMA SGP.02 v4.3, Remote Provisioning Architecture for Embedded UICC Technical Specification (25 January 2023)
• GSMA eSIM Certification Applicability, Annex C V3.2.2 (July 2025, PDF)
• GSMA SGP.06 v2.3, eUICC Security Assurance Principles (27 May 2025)
• GSMA eUICC Security Assurance (eSA) Scheme Step-by-Step Guide (February 2021, PDF)
• Android Open Source Project: Implement eSIM
• ETSI TS 102 221 V18.4.0 (2026-05), Smart Cards; UICC-Terminal interface; Physical and logical characteristics
• ETSI TS 103 666-1 V17.3.0 (2023-06), Smart Secure Platform (SSP); Part 1: General characteristics
• ETSI: Cybersecurity, privacy and users (smart card and secure element work)
• 3GPP TS 31.102 archive, USIM application (V20.0.0)
• 3GPP TS 31.103 archive, ISIM application (V19.1.0)
• 3GPP TS 27.007 archive, AT command set for user equipment
• Oracle: Java Card technology
• FCC: FCC Adopts Rules to Protect Consumers' Cell Phone Accounts (15 November 2023)
• FCC news release text, FCC 23-95
• eCFR: 47 CFR 64.2010, Safeguards on the disclosure of CPNI
• eCFR: 47 CFR 52.37, Number portability requirements for wireless providers

Last reviewed: 26 October 2026. GSMA, ETSI and 3GPP revise these specifications regularly and the FCC compliance dates may change; check the documents above for the versions that apply to your devices.