Definition
eSIM Profile is an operator configuration package stored on the eSIM chip, containing authentication credentials such as IMSI, Ki, OPC, as well as APN, network policies, roaming settings, etc. A single device can store multiple profiles and switch between them by activating or deactivating them. When used together with Multi-IMSI, it allows flexible operator switching based on region or cost, without the need to physically change the SIM card.
Profile Structure
eSIM Profile follows the GSMA SGP.22 specification and typically includes: Authentication Data—IMSI, Ki, OPC, etc., used for network attachment and authentication; Policy Data—PLMN Selection priority, Roaming Policy; Metadata—operator name, profile type (production/test), validity period. Profiles are generated and signed by SM-DP+ and securely downloaded to devices via OTA.
Multiple Profile Management
The device can store multiple profiles (usually 2–8), but only one can be active at a time. Customers can remotely switch profiles on the ICMP platform based on device deployment location, Geo-Based Pricing tariffs, Carrier Fallback strategies, etc. Combined with Multi-IMSI, different profiles can correspond to different countries/operators, enabling flexible "one card for global use" deployment.
Implementation in ICMP
SimtoLink ICMP supports full lifecycle management of eSIM profiles: profile creation, download, activation, switching, deletion; integration with Multi-Operator and Roaming Partner; supports Cross-Border Card Management. The platform interfaces with multiple operators through SM-DP+ or aggregation layers, providing customers with unified profile management capabilities.
How authentication material and policy material divide the work inside a profile
A profile is a set of operator material installed in an embedded chip. It is not simply a second plastic card in logical form. Authentication material includes the subscriber identity and the key material the network uses to authenticate. The core network uses those to recognize this subscription on this device. Policy material includes the access point, the preferred networks, and roaming restrictions. It decides which networks are available after attach, and which egress is used. Both kinds of material have to be present before a profile can go from download to network entry.
The package is generated and signed by the subscription-management service, and the device downloads it with a local assistant. The signature confirms the package was not swapped in transit, and that it was issued for this chip. The chip matches the download request with its own identifier. A package prepared for another device cannot be installed. A package can also carry a type and an expiry. A test package should not remain on a production device past the agreed window. “Downloaded” on the platform only means the file is on the chip. It does not mean this package has been selected as the one currently enabled.
Device conditions that allow a remote profile switch
A remote switch needs all of the following at once. The chip has room for another package, or it is allowed to delete before installing. The device can reach the subscription-management service, which usually depends on a bootstrap package or the current package still being usable. The target package’s signature, matching identifier, and target chip identifier agree. The switch policy allows the target operator to be enabled in that place. If there is no usable network on site, there is no path to enable a new package remotely, unless the device can still make one short connection with the bootstrap package.
Only one service package should be enabled at a time. The right order is to enable the target package, confirm that attach succeeds, and then disable the previous package. When this is used together with multi-IMSI, distinguish an identity switch inside the same package from replacement of the whole package. The two roll back differently. If the target country’s rate depends on geo-based pricing, know which price band the new package will fall into before the switch, so a search for signal does not land on a high-price network the contract does not cover. If the access point hard-coded in the module does not match the new package, enablement can succeed and there is still no data plane.
Enabling more than one profile, or a failed signature check
The chip refuses to enable two service packages at once. If the platform sends two enable commands in a row and does not check the current state, the later one fails or overwrites the earlier one, while the page shows both in use. The device then attaches with whichever one is actually selected, and detail records and diagnostics will not agree. If the signature check fails, the package should not be marked usable. Common causes are delivery to the wrong chip, reuse of a package, or a wrong subscription-management address, so the device connects to another environment’s server.
Forcing enablement after expiry makes the network reject authentication, and the symptom looks like a damaged SIM. After a bootstrap package is deleted as if it were an ordinary package, the device has no channel left to download any new package. A test package and a production package that share one matching code install a test subscription onto a device that is shipping. Power loss during a switch can leave the chip with no package enabled, and recovery then needs a local or bootstrap channel. Platform state should follow the chip’s receipt, not the fact that a command was sent. On failure, keep the matching code, the chip identifier, and the signature error. Do not immediately generate a pile of new packages and fill the chip.
Chip capacity should be managed by the number of installed packages and the type of each one, not only by the one the platform shows as enabled. A disabled package still takes space. During a bulk operator change, if every device downloads the new package before deleting the old one, a device that is short of space stops halfway: the old package is disabled and the new one is not fully installed. The order should confirm remaining space first. If there is not enough, delete disabled packages that are clearly no longer needed, and always leave the bootstrap package. A matching identifier is void after one use. Reusing it binds a later device’s download request to a code the previous device already used, and the signature check fails immediately. Stop reallocating a voided code at once, and record the chip identifier it was bound to, so a repeated issue can be told apart from the device retrying on its own.