Comprehensive technical knowledge base covering 12 GSMA eSIM specifications. 84+ articles on Remote SIM Provisioning — SGP.02, SGP.22, SGP.32, SGP.41, SGP.29, SGP.23, SGP.25, SGP.26 and more.
🏠 eUICC.tech > SGP.32 IoT eSIM > Advanced IoT Security & Lifecycle: Mutual Auth, OS Update, Emergency Profiles, and ECASD
💡 Why this matters: Profile download is one thing: but what happens when an IoT device needs its eSIM operating system patched? What profile should run when a vehicle crashes and needs to dial emergency services? What cryptographic dance ensures an SM-DP+ and an eUICC actually trust each other? This article covers the security-critical lifecycle mechanisms beyond basic provisioning: the full mutual authentication handshake, eUICC OS updates, Emergency Profile preemption, the Fallback Mechanism, and the root of trust that anchors it all: ECASD.
Key takeaways:
- Common Mutual Authentication is a 17-step cryptographic handshake verifying both the SM-DP+/SM-DS and the eUICC using their respective certificate chains
- eUICC OS Update is EUM/manufacturer-specific but MUST be secure, re-certified, and transparent to installed profiles
- Emergency Profiles preempt everything: even the Fallback Profile and Memory Reset are blocked while eCall is active
- The Fallback Mechanism provides autonomous connectivity recovery: the IPA or eIM triggers a switch to a fallback profile
- ECASD is the tamper-resistant vault holding the eUICC’s private key, certificates, and CI root public keys: the anchor for all RSP trust
Before any profile can be downloaded: before any bytes of a Bound Profile Package are sent: the eUICC and the RSP Server (SM-DP+ or SM-DS) must mutually authenticate. This is the Common Mutual Authentication procedure, defined in SGP.22 section 3.1.2 and invoked identically by SGP.32.
It’s a 17-step cryptographic exchange that proves to each party that the other holds a valid certificate chaining to a trusted eSIM CA Root. Here’s the walkthrough:
| Entity | Holds | Purpose |
|---|---|---|
| eUICC | CERT.EUICC.ECDSA + SK.EUICC.ECDSA (in ECASD), CERT.EUM.ECDSA, PK.CI.ECDSA (CI Root public key) |
Proves eUICC identity to server |
| SM-DP+ | CERT.DPauth.ECDSA + SK.DPauth.ECDSA, CERT.DP.TLS, CI Root |
Proves server identity to eUICC |
| SM-DS | CERT.DSauth.ECDSA + SK.DSauth.ECDSA, CERT.DS.TLS |
Proves server identity to eUICC |
The spec uses the notation SM-XX (either SM-DP+ or SM-DS) and CERT.XXauth.ECDSA : the procedure is identical whether you’re talking to a profile server or a discovery server.
IPA → eUICC: GetEUICCInfo → euiccInfo1
IPA → eUICC: GetEUICCChallenge → euiccChallenge
IPA → SM-DP+: HTTPS (server-auth TLS, CERT.DP.TLS)
IPA → SM-DP+: InitiateAuthentication(euiccChallenge, euiccInfo1, Address)
[SM-DP+ generates TransactionID, serverChallenge,
builds serverSigned1, computes serverSignature1]
IPA ← SM-DP+: TransactionID, serverSigned1, serverSignature1, CERT.DPauth.ECDSA
IPA → eUICC: AuthenticateServer(serverSigned1, serverSignature1, CERT.DPauth, ctxParams1)
[eUICC verifies CERT.DPauth chain via PK.CI.ECDSA in ECASD,
verifies serverSignature1, verifies euiccChallenge matches]
IPA ← eUICC: euiccSigned1, euiccSignature1, CERT.EUICC.ECDSA, CERT.EUM.ECDSA
IPA → SM-DP+: AuthenticateClient(euiccSigned1, euiccSignature1, eUICC cert chain)
[SM-DP+ verifies eUICC cert chain, verifies euiccSignature1,
verifies serverChallenge matches]
IPA ← SM-DP+: [Profile Metadata | RPM Package | Event Records]
Challenge-response prevents replay. The eUICC generates a random euiccChallenge; the server generates serverChallenge. Each signs the other’s challenge into serverSigned1/euiccSigned1. A replayed challenge would be instantly detected as a stale nonce.
Certificate chain to CI Root. Both sides walk the peer’s cert chain to the CI Root: the eUICC uses PK.CI.ECDSA from ECASD; the server uses its own CI Root copy.
Address/OID cross-check. The IPA verifies the SM-DP+ address in the response matches its request. For SM-DP+, the OID in CERT.DPauth.ECDSA is checked against any OID from the Activation Code: impersonation prevention.
After mutual authentication, the SM-DP+ encrypts the profile to a one-time public key (bppEuiccOtpk) generated by the eUICC for this session. This binds the Bound Profile Package to this specific eUICC and session: intercepting it is useless without the corresponding private key inside ECASD.
eUICC Operating System updates are a reality in long-lived IoT deployments. An OS bug discovered five years into a 15-year smart meter deployment can’t be fixed by swapping SIM cards.
SGP.22 and SGP.32 both state that eUICC OS Update:
An OS update may affect euiccInfo1 and euiccInfo2 : supported CI public key identifiers, capabilities, version numbers: requiring re-certification under GSMA SGP.24.
There is no standardised eligibility check or flow. The EUM/manufacturer defines how updates are authenticated, delivered, and applied. Profiles must survive intact; the post-update eUICC must remain RSP-compliant; the update mechanism must not create backdoors. In practice, OS updates travel through the device’s firmware update channel, payload signed by the EUM and verified by the eUICC before application. For fleet managers: there is no ES10b.UpdateOS : OS updates are a separate EUM-proprietary channel, making vendor selection critical.
An Emergency Profile (defined in SGP.31) is a profile with ecallIndication set to TRUE in its Profile Metadata. It’s designed for scenarios where the device must place an emergency call (eCall for vehicles, emergency beacon for maritime/aviation) : and normal connectivity rules don’t apply.
The IPA calls ES10b.EnableEmergencyProfile to force the eUICC to enable the Emergency Profile. The function is atomic: terminate any proactive session, close all logical channels, reset PIN, disable the current profile, enable the Emergency Profile, and clear Rollback authorisation: in one indivisible operation. Error codes: ecallNotAvailable(8), profileNotInDisabledState(2), catBusy(5).
Key behaviours:
ExecuteFallbackMechanism (ecallActive(104)), and eUICCMemoryReset (ecallActive)ES10b.DisableEmergencyProfile returns to normal operation: disable Emergency Profile, enable the previously-active profile (automatically remembered by the eUICC), clear Rollback authorisation. Notifications MAY be generated (unlike enable-side).
IoT devices in the field can lose connectivity for many reasons: the current operator has a regional outage, the device moved out of coverage, or the profile was misconfigured. The Fallback Mechanism provides a standardised way to switch to a recovery profile.
fallbackAttribute via PSMO (SetFallbackAttribute)Preconditions:
- An Enabled Profile exists AND fallbackAttribute is set on a Profile
- Emergency Profile NOT enabled (returns ecallActive if so)
- Fallback Profile is in Disabled state
Atomic execution (no refreshFlag):
Terminate proactive session → close channels → reset PIN
→ disable current profile → enable Fallback Profile
→ clear Rollback authorisation → return 'ok'
Atomic execution (refreshFlag set):
Mark current "to be disabled" + Fallback "to be enabled"
→ return 'ok' → send REFRESH → on Terminal Response success: commit
→ on failure: profiles unchanged
Error codes: profileNotInDisabledState(2), catBusy(5),
fallbackNotAvailable(6), ecallActive(104)
Preconditions:
- Currently enabled profile IS the Fallback Profile
- Previously enabled profile identification was recorded
- Previously enabled profile is still installed
Execution:
Disable Fallback Profile → enable previously-enabled profile
→ clear Rollback authorisation
The eUICC records the previously-enabled profile identity at fallback time: no IPA-side bookkeeping needed for the return.
In IoT SGP.32, the fallback can be triggered two ways:
ES10b.ExecuteFallbackMechanismESep in a signed eUICC Package, can include an ExecuteFallbackMechanism command: the server-side equivalentHow the IoT Device “detects permanent loss of connectivity” is implementation-specific and out of scope of the specification.
The Fallback Mechanism operates below the Emergency Profile in priority:
Priority hierarchy (highest to lowest):
1. Emergency Profile (preempts everything)
2. Fallback Mechanism (preempts normal PSMO)
3. Normal PSMO (Enable/Disable/Delete)
While the Emergency Profile is active, neither fallback nor normal profile operations are permitted.
The eUICC Controlling Authority Security Domain (ECASD) is the tamper-resistant security vault at every eUICC’s core. Mutual authentication, profile binding, notification signing, and eIM package verification all trace their trust back to ECASD.
| Stored Item | Purpose |
|---|---|
SK.EUICC.ECDSA |
eUICC private key: never leaves ECASD; signs euiccSigned1, notifications, eUICC Package Results |
CERT.EUICC.ECDSA |
eUICC public certificate: shared during mutual auth |
CERT.EUM.ECDSA |
EUM certificate: proves trusted manufacturing origin |
PK.CI.ECDSA |
eSIM CA Root public key(s) : verifies RSP Server cert chains |
| EUM keyset (optional) | Key/certificate rotation without complete replacement |
The ECASD provides two services: eUICC signature creation (sign data with SK.EUICC.ECDSA : used for mutual auth, notifications, eUICC Package Results) and off-card certificate verification (verify RSP Server certificate chains against PK.CI.ECDSA).
The ECASD is personalised in a certified GSMA SAS-UP environment during manufacturing. After personalisation, it is in PERSONALIZED lifecycle state and cannot be modified except through EUM-proprietary key renewal mechanisms.
In SGP.32 IoT, ECASD’s role is unchanged from SGP.22: but the frequency and criticality of its operations increase: every eUICC Package result is eUICC-signed, every notification is eUICC-signed, and mutual authentication can involve SM-DP+, SM-DS, and eIM (via Indirect Download relay). The ECASD is the single component that, if compromised, breaks all RSP security for that eUICC.
Layer 1: ECASD (root of trust: keys, certs, CI roots)
↓
Layer 2: Common Mutual Authentication (proves both identities)
↓
Layer 3: BPP Binding (profile encrypted to session-specific key)
↓
Layer 4: Profile Lifecycle (Operational / Provisioning / Test)
↓
Layer 5: Policy Enforcement (PPE checking PPR1/PPR2)
↓
Layer 6: Emergency Preemption (Emergency Profile blocks all ops)
↓
Layer 7: Fallback Recovery (autonomous connectivity restoration)
A secure IoT eSIM deployment activates all seven layers. ECASD anchors the trust; mutual authentication establishes the session; BPP binding protects the profile in transit; policy enforcement prevents lock-in abuse; and emergency/fallback mechanisms ensure the device can always connect when it needs to: whether for a vehicle crash or a network outage.
ReturnFromFallback restoring the previous stateBased on GSMA SGP.22 v3.1, Sections 2.4.2, 2.4.13, 3.1.2; GSMA SGP.32 v1.3, Sections 2.4.2, 2.4.13, 3.2.2, 5.9.20-23
| ← Previous: Profile Lifecycle & Policy: Types, PPE, and Enforcement in IoT eSIM | Section Index |