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.
Here’s a hard truth about connected devices: if you can’t switch providers, you don’t own the device: the provider owns you.
This is called vendor lock-in, and it’s the single biggest threat to any large-scale IoT deployment. SGP.02 has an answer. It’s called SM-SR Change : a 32-step, four-party protocol that transfers an entire robot from one Commander to another, over the air. No truck rolls. No chip swaps. And the robot itself holds the final vote.
Plenty of reasons. None of them should require a hardware replacement:
SM-SR Change makes all of these a radio operation, not a physical one.
Four parties, each with a specific role:
The Fleet Owner asks Beta: “Can you handle robot #8721?” Beta checks its own capacity, chip compatibility, and credentials. If the answer’s yes, we proceed.
Alpha ships the robot’s EIS (information database) to Beta. This includes the robot’s identity certificate, all profile metadata, current states, and rulebooks. Beta verifies the certificate chain, making sure the robot traces back to a legitimate Chip Builder and CI.
At this point, Beta knows everything Alpha knows about the robot. But Beta still can’t command the robot. For that, Beta needs the robot’s permission.
This is the cryptographic heart of the whole procedure. Beta must prove its identity directly to the robot, not through Alpha. Alpha relays the messages, yes, but the authentication happens between Beta and the robot:
Alpha can’t fake Beta’s signature. Alpha can’t block a valid Beta from passing. The robot decides.
Using the same ECKA-EG key agreement from profile download, Beta and the robot generate a brand-new key set: the KS2 keys : for all future communication. The critical moment: when Beta verifies the key receipt, Beta is now the Commander. Even if everything else falls apart from this point forward, the transfer is cryptographically complete.
This is the design choice that makes SM-SR Change work even with an uncooperative Alpha:
SK.ECASD.ECKA) is the single source of truthIf Alpha refuses to relay messages, the protocol stalls, but it can’t be subverted. A cooperative Alpha is required for the relay, but a cooperative Alpha can’t fake or block a legitimate handover.
| Goes to Beta | Stays with Alpha |
|---|---|
| Robot identity and certificate chain | Old SCP80/SCP81 keys (replaced by KS2) |
| All profiles, states, and configurations | Billing records and audit logs |
| POL2 rulebooks | Administrative history |
| Connectivity parameters | Internal Alpha-only metadata |
| Fall-Back and Emergency attributes | : |
The robot itself doesn’t change. It just has a new phone number for Command.
SM-SR Change is the feature that makes SGP.02 different from proprietary alternatives. The robot was designed from the factory to accept a new Commander, it just needs to verify that the new Commander’s credentials trace back to the same Passport Office (the CI). It’s vendor independence baked into silicon.
If you’re deploying thousands of devices with a 10–15 year lifespan, this matters. A lot.
Kid-friendly version of GSMA SGP.02 v4.2 §3.8–3.9, §5.6, SM-SR Change