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.02 M2M RSP > Resilience: Fall-Back Mechanism, Emergency Profiles, and Test Profiles
A gas meter in a basement. An eCall module in a crashed car. A weather station on a mountain. A water quality sensor in a reservoir. None of these devices will ever see a technician. And all of them need to stay connected for a decade or more, through operator changes, network outages, and hardware degradation.
SGP.02 knew this from the start. The spec bakes in three separate resilience mechanisms, each designed for a different kind of failure. One handles routine connectivity loss. One handles life-or-death emergency access. One handles the entirely mundane problem of testing a device without burning an operational subscription. Together they form the safety net that makes 15-year M2M deployments viable.
This article assumes you understand the Profile lifecycle (Article 6), the ISD-R’s role as Platform Manager, and the OTA communication paths over ES5. We’ll reference notification procedures and POL1/POL2 rules; Article 9 covers those in full.
Let’s start with the most common failure: the enabled Profile can’t connect anymore. Maybe the operator’s network went down. Maybe the subscription expired. Maybe a policy rule on the other side of the world flipped a switch the device didn’t expect.
Consumer devices solve this with a human. You notice the “No Service” icon, you open Settings, you tap a different eSIM. M2M devices don’t have you. They need the eUICC to figure it out on its own.
At any time, exactly one Profile on the eUICC carries the Fall-Back Attribute. It sits there disabled, waiting, usually a minimal, low-cost subscription from a different operator than the primary Profile. Network diversity is the whole point. If Operator A goes down, Operator B probably hasn’t.
Setting the Fall-Back Attribute works like any other management operation:
ES4.SetFallBackAttribute (§3.27)ES2.SetFallBackAttribute → ES3 → ES5 (§3.28)ES4.SetFallBackAttribute with PLMA authorisation (§3.29)When you set it on Profile B, it’s automatically unset from Profile A. There’s no “unset Fall-Back” function: it’s always a transfer, never a removal. Some Profile somewhere always carries the flag.
The Fall-Back Mechanism is autonomous. No server, no OTA command, no human approval:
The device is back online before the SM-SR even knows there was a problem. That’s the key design choice: switch first, notify second. Don’t wait for permission when connectivity is at stake.
A mechanism this aggressive needs guardrails:
LocalDisable is called. You don’t want automatic failover pulling a device out of an eCall session or a factory test.The European Union’s eCall regulation changed automotive electronics forever. Every new car sold in the EU must be able to place an emergency call to 112, even without an active commercial subscription. If the primary Profile is disabled, expired, or belongs to an operator with no coverage where the crash happened, the emergency call still has to go through. No exceptions.
Emergency Profiles (§3.25, §3.26) are SGP.02’s answer. They provide:
Like Fall-Back, exactly one Profile can hold the Emergency Profile Attribute. Setting it on Profile B unsets it on Profile A. The three-path management pattern applies:
ES4.SetEmergencyProfileAttribute → ES5 (§3.25)ES2.SetEmergencyProfileAttribute → ES3 → ES5ES4.SetEmergencyProfileAttribute with PLMA authorisation (§3.26)The spec distinguishes two cases:
Case 1: First Emergency Profile. No Emergency Profile exists yet. The Operator sets the attribute on the target Profile. Simple.
Case 2: Replacement. An Emergency Profile already exists, owned by Operator1. Operator2 wants to set the attribute on its own Profile. Operator1 has to grant Operator2 PLMA authorisation to unset the attribute from Operator1’s Profile. You can’t just overwrite someone else’s emergency capability.
Not every resilience problem is a crisis. Sometimes you just need to test a device on the factory floor without consuming a production subscription. Test Profiles (§3.22, §3.23) are built for manufacturing, lab validation, and field diagnostics.
A Test Profile carries a special flag and test NAA keys (defined in SGP.01’s EUICC23 requirements). It connects to test networks, not production networks. It’s not managed through the normal lifecycle path: no SM-SR, no ES4, no OTA. Instead, the Device talks directly to the eUICC over the ESx interface.
ESx is the direct Device-to-eUICC interface, and it’s the only Profile management path that bypasses the SM-SR entirely. The Device (the modem, MCU, or application processor that hosts the eUICC) can switch to Test and Emergency Profiles without touching the network.
The Device calls ESx.LocalEnableTestProfile. The eUICC checks:
Checks pass? The eUICC ignores POL1 of the currently enabled Profile, disables it, enables the Test Profile, fires a REFRESH, and the device attaches. The spec is explicit about what happens next: “Whether the Test Profile provides connectivity to a test network or not, the eUICC will not attempt to enable automatically the previously Enabled Profile.” Local enable has no automatic roll-back. You’re in test mode until you explicitly leave it.
Switching back is ESx.LocalDisableTestProfile (§3.23). The eUICC confirms the Test Profile is enabled, then disables it and re-enables whatever Profile was active before.
ESx.LocalEnableEmergencyProfile follows the same pattern: verify the Emergency Profile exists and isn’t already enabled, override POL1, switch. This is how a vehicle’s crash detection system activates eCall without waiting for an OTA command that might never arrive.
Reverting is ESx.LocalDisableEmergencyProfile (§3.31), back to the previously enabled Profile.
Both Fall-Back and Emergency attributes follow the same three-path management pattern as lifecycle operations:
| Operation | Operator (ES4) | Via SM-DP | M2M SP (ES4) |
|---|---|---|---|
| Set Emergency Attribute | §3.25 | §3.25 (via SM-DP) | §3.26 |
| Set Fall-Back Attribute | §3.27 | §3.28 | §3.29 |
| Local Enable Test | N/A (ESx) | N/A | N/A |
| Local Disable Test | N/A (ESx) | N/A | N/A |
| Local Enable Emergency | N/A (ESx) | N/A | N/A |
| Local Disable Emergency | N/A (ESx) | N/A | N/A |
For remote operations: requester calls the function, SM-SR relays to eUICC via ES5, eUICC executes, notifications propagate, EIS updates. For local operations: Device calls ESx directly, eUICC executes, no server involvement needed.
These three systems aren’t silos. They overlap in ways the spec carefully defines:
The design philosophy is consistent: the more local and immediate the need, the more the spec allows it to override remote policy. A crashed car needs eCall more than it needs to respect a “disable not allowed” flag.
These three mechanisms (Fall-Back, Emergency, and Test) are what make the “embedded” in eUICC mean something. They don’t assume network availability. They don’t assume a human is nearby. They don’t assume the original Operator is still in business. They’re designed for a world where the device is on its own, and they give it the tools to stay connected anyway.
Based on GSMA SGP.02 v4.2 (07 July 2020), Remote Provisioning Architecture for Embedded UICC Technical Specification, §3.16, §3.22–3.31
| ← Previous: SM-SR Change: Handover, ES7 Interface, and EIS Migration | Section Index | Next: Policy Rules & Notifications: POL1, POL2, and the Default Notification → |