Definition
eSIM (embedded SIM) is a SIM chip soldered onto the device motherboard, eliminating the need for physical card swapping. eSIM supports OTA remote download, activation, and switching of eSIM Profiles, and when combined with Multi-IMSI enables flexible switching across multiple operators and regions. It is an important technological direction for miniaturization of IoT devices, remote operation and maintenance, and cross-border deployment.
Technical Principle
eSIM follows the GSMA SGP.21/SGP.22 specifications, storing Profiles via the SM-DP+ (Subscription Manager) server. Devices initiate download requests through the LPA (Local Profile Assistant). The Profile contains operator credentials, APN, network policies, etc. After downloading, it is installed onto the eSIM chip. A single device can store multiple Profiles, and switching is achieved via activation/deactivation without needing to physically swap cards.
Advantages in the Internet of Things
The value of eSIM for the Internet of Things includes: Remote provision — devices do not need pre-installed specific operator cards at the factory and can OTA download local Profiles upon reaching the target country; Flexible switching — combined with Multi-IMSI and Carrier Fallback, operators can be switched based on signal, tariff, and policy; Miniaturization — cardless design suitable for wearable, automotive, industrial, and other compact scenarios; Tamper resistance — soldered onto the motherboard, reducing the risk of physical theft or replacement.
Management in ICMP
SimtoLink ICMP supports the full lifecycle management of eSIMs: Profile generation and delivery, activation,Suspension, Decommissioning; and Multi-Operator, Roaming Policy Linkage;Cross-Border Card Management Cross-border card management;Card Diagnostics Diagnosis. The platform achieves RESTful API, SDK Unified management of eSIM and physical cards through interfacing with SM-DP+.
How the embedded chip differs from a removable card as a carrier
An embedded subscriber identity module is a secure chip soldered to the board. Credentials sit in a profile on the chip, not on a plastic card that can be pulled out. Changing operator means changing the profile, not the hardware. The chip has its own identifier, the profile has its own SIM identifier, and the subscription currently enabled also has a subscriber identity. The three identifiers point at different layers. The chip is the carrier, the profile is the operator material loaded onto it, and the subscriber identity is what the network uses at registration.
A removable card binds those three layers onto one card that can be taken away. Changing the card changes the carrier and the subscription together. An embedded design leaves the carrier in the device, so the factory can ship only a bootstrap profile and download a local operator’s profile once the device reaches the target country. The download flow for a consumer device and for a constrained IoT module is not the same. Copying the phone’s QR-code provisioning flow onto a module with no screen and no way to confirm interactively stops the download while it waits for a confirmation.
What the device must be able to do before a profile is written remotely
Before the write, the device must power on, the module must be able to drive this chip, and at least one usable data path must reach the subscription-management service. That path can be cellular connectivity from the bootstrap profile, or another network on site. It cannot assume the target profile already works. The local assistant has to support the download flow the platform uses. The address, the matching identifier, and the chip identifier must belong together. Remaining space on the chip must fit one new profile. If it is full, delete disabled profiles by the rules. Do not delete the profile that still carries the bootstrap role.
A remote write is not the same as being on the network. After the profile is installed it still has to be enabled, and after enablement the network-side subscription must allow attach. Together with profile management, the platform should show download, enablement, and network registration as three results. SIM management that does not connect to the management service cannot actually deliver a profile onto the chip. Bulk writes should also limit concurrency, so the same chip does not receive overlapping download jobs. When an operator rollback is required, keep the previous profile disabled but not yet deleted, rather than wiping it the moment the write succeeds.
Mixing up on-network state and profile state
A profile shown as enabled only means the chip selected it. The network may still refuse it, because the subscription is not provisioned, roaming is not allowed, or the access point does not match. The reverse also happens: the network still has a registration, the profile on the chip has been deleted, the device cannot attach, and the invoice may continue until the subscription is terminated. Folding the two states into one “normal” or “abnormal” makes the field replace the device, while the problem is in one of the two layers, the profile or the subscription.
Another mix-up is managing the chip with inventory logic built for removable cards. A chip cannot be pulled from a failed device and inserted into the next one, unless the whole device moves with it. Assigning the chip identifier to a new hardware record sends the download request to the chip still soldered in the old device. After the bootstrap profile is disabled, the device has no way back when the target profile fails. A management-service address from the test environment written into a production module sends the production chip identifier to the test system. The investigation order should be chip identifier, profile state, the enabled subscriber identity, then the network reject reason. Do not run the decommissioning flow to cancel the subscription before the profile is enabled. The only remaining download channel disappears with it.
Bootstrap configuration and service configuration have different lifecycles. Bootstrap only connects the device to the management service. The service profile carries the operator subscription the customer bought. A factory check can use the bootstrap profile for one short connection, but that usage should not be posted to the customer’s plan, and the bootstrap profile should not be disabled when the check ends. If a service-profile change fails in the field, the device still has to be able to return to bootstrap and download again. An inventory system that records only one “SIM number” merges the bootstrap identifier and the service-profile identifier onto one row, and later termination and billing look up the wrong object. Keep both identifiers, and mark which one is enabled now.