Buying an eSIM can take less than a minute. Behind that short customer journey is a controlled process involving the seller, connectivity provider, subscription-management platform, device operating system, secure element and mobile network.
The process is called remote SIM provisioning, or RSP. It allows a compatible device to obtain and manage a mobile subscription without inserting a conventionally pre-provisioned plastic SIM card.
The simplest description is:
- a customer buys or receives a mobile plan;
- the provider allocates an eSIM profile;
- the customer or device receives activation information;
- the device's Local Profile Assistant contacts the appropriate provisioning server;
- the profile is securely downloaded and installed on the eUICC;
- the profile is enabled;
- the modem uses it to register with an available mobile network;
- the commercial plan begins according to the provider's activation rules.
These stages may happen almost simultaneously, but they are not the same event. A profile can be allocated but never downloaded. It can be downloaded but disabled. It can be enabled but unable to register with a network. It can register successfully while mobile data remains unavailable because of device settings, APN configuration, coverage or plan status.
Understanding those distinctions is essential for operators, travel companies, fintechs, retailers and other businesses launching a branded eSIM service.
Key takeaways
- An eSIM is not emailed to a phone as an ordinary file. A secure device process retrieves a protected operator profile from remote provisioning infrastructure.
- The QR code is normally a visual representation of activation information. It is not the profile and does not itself provide mobile coverage.
- The SM-DP+ prepares and delivers the profile. The Local Profile Assistant, or LPA, manages the device side of profile download and installation.
- The eUICC is the protected component in which the downloaded profile is installed and managed.
- Download, installation, enablement, network registration and plan activation are separate states.
- Internet access may be required before the profile can be downloaded, usually through Wi-Fi or another active mobile connection.
- Coverage depends on the subscription's network relationships and the device's radio support, not on successful profile installation alone.
- A white-label platform should expose clear lifecycle states, actionable errors and recovery paths instead of treating every unsuccessful connection as an “activation failure”.
- Transfer to another device is generally a managed replacement or transfer process, not the copying of a profile.
- Good provisioning design is as much about customer communication and support operations as it is about the underlying standard.
What does eSIM provisioning mean?
Provisioning is the process of preparing, delivering and installing the subscription information that allows a device to use a mobile service.
With a traditional SIM card, much of this preparation happens before the card reaches the customer. The subscription credentials are placed in a secure chip during production or personalisation, and the customer inserts that physical card into a device.
With eSIM, the secure subscription is delivered remotely to a compatible eUICC. The customer may initiate the process using a QR code, a carrier application, a system notification, a web link, manual activation details or an operating-system-supported transfer flow.
The user experience looks digital and simple, but the profile still contains protected mobile-network credentials. It must therefore be generated, transported and installed through a secure architecture rather than distributed as an ordinary downloadable file.
Provisioning is not one single activation event
The word “activation” is used loosely in commercial interfaces. It may refer to:
- assigning a profile to an order;
- issuing activation information;
- downloading the profile;
- installing it on the eUICC;
- enabling the installed line;
- completing the first network registration;
- starting the validity period of a data package;
- completing an identity or payment check.
These definitions produce very different commercial outcomes. A travel plan that starts when it is purchased behaves differently from one that starts at first network use. A profile that has been downloaded but not enabled creates a different support case from a profile that is enabled but outside coverage.
A provider agreement and customer interface should define each state precisely.
The main components in consumer eSIM provisioning
The GSMA consumer remote SIM provisioning architecture separates responsibilities across several components. The exact implementation may vary between operators, providers and devices, but the principal roles remain useful for understanding the process.
The eUICC
The eUICC is the protected component that can receive, store and manage operator profiles. In a smartphone it is commonly embedded in the device, although remotely provisionable technology can also exist in other physical forms.
The eUICC is not simply general phone storage. It provides a controlled environment for subscription credentials and profile lifecycle operations.
Each eUICC has an identifier called an EID. The EID identifies the eUICC itself. It should not be confused with the ICCID, which identifies a particular SIM profile or subscription instance.
The eSIM profile
The profile is the downloadable operator subscription placed on the eUICC. It contains the data and applications needed for the device to authenticate and use the relevant mobile service.
In practical commercial systems, a profile is commonly associated with identifiers such as:
- an ICCID identifying the profile or subscription;
- one or more subscriber identities used by the mobile network;
- authentication material;
- operator and service configuration;
- access rules and profile metadata.
The full protected contents are not exposed to the customer or ordinary applications.
The SM-DP+
The Subscription Manager Data Preparation Plus, normally shortened to SM-DP+, is the remote service responsible for preparing, protecting and delivering consumer eSIM profiles.
It does not behave like a public file server. During provisioning, it participates in an authenticated process that enables a suitable profile package to be delivered to the intended eUICC.
For a white-label business, the SM-DP+ may belong to an upstream operator, a specialist eSIM provider or another authorised party in the supply chain. The brand selling the plan does not necessarily operate its own SM-DP+.
The Local Profile Assistant
The Local Profile Assistant, or LPA, is the device-side component that manages interactions required to download and administer profiles.
It provides the bridge between the SM-DP+ and the eUICC. Depending on the operating system and device, it may also provide the user interface through which the customer adds, enables, disables or deletes an eSIM.
Android's official implementation guidance describes the LPA as the component that mediates between the SM-DP+ and the eUICC. Device and carrier applications can request permitted operations, but the protected eSIM lifecycle remains controlled by the operating system, LPA and eUICC.
The SM-DS
The Subscription Manager Discovery Service, or SM-DS, can help a device discover that a profile is available without requiring the customer to type provisioning details or scan a conventional QR code.
Not every customer journey visibly uses an SM-DS. Many retail and travel eSIM services continue to deliver a QR code or activation link. Nevertheless, discovery services are part of the wider architecture and can support more automatic experiences.
The mobile network and connectivity platform
Installing the profile does not itself create radio coverage. Once the profile is enabled, the device modem must find and register with a permitted mobile network.
The network side may include:
- the visited radio network;
- the home or sponsoring network associated with the subscription;
- authentication and subscriber databases;
- policy, charging and usage-control systems;
- roaming signalling and data transport;
- APN or data-network configuration;
- an internet breakout location.
This is why provisioning and live connectivity must be monitored separately.
The complete eSIM journey from purchase to connectivity
The exact sequence depends on the business model, but the following stages describe a typical consumer or travel eSIM flow.
Step 1: The customer selects a plan
The customer chooses a destination, region, data allowance, validity period or recurring mobile plan.
Before accepting payment, the storefront should make the core conditions clear:
- supported countries and networks;
- whether the plan provides data only or also voice and SMS;
- validity and start conditions;
- fair-use rules for unlimited products;
- tethering policy;
- device compatibility requirements;
- whether the profile can be reinstalled, transferred or reused;
- refund restrictions after profile download or consumption.
Provisioning problems often begin as product-description problems. If a customer buys a data-only travel product expecting a telephone number, or assumes that a locked device will accept a third-party eSIM, the technical process may work correctly while the customer still considers the purchase unsuccessful.
Step 2: The service validates the order
The commercial platform normally validates the transaction before issuing profile access.
Checks may include:
- payment authorisation;
- fraud screening;
- account status;
- country or sanctions restrictions;
- device or product eligibility;
- required identity verification;
- tax treatment;
- stock or profile availability.
The profile should not be irreversibly allocated too early if a payment might still fail. Equally, the customer should not be charged successfully and then left without a fulfilment path if profile stock is unavailable.
Well-designed order management coordinates payment and profile allocation so that both success and rollback states are known.
Step 3: A profile is allocated or prepared
The provider assigns a profile or profile order to the customer transaction. Depending on the upstream model, this may involve selecting from prepared inventory or requesting profile preparation through an API.
The business platform may receive:
- an order or provisioning reference;
- an ICCID;
- activation information;
- an SM-DP+ address;
- a matching identifier;
- a confirmation-code requirement;
- validity or download constraints;
- the initial provisioning status.
The brand should store only the data it genuinely requires and protect access to activation information. A QR code or activation string can be commercially sensitive even though it does not reveal the protected authentication material inside the profile.
Step 4: Activation information is delivered
The customer needs a supported way to tell the device which profile to retrieve. Common delivery methods include:
- QR code;
- activation link;
- manual SM-DP+ address and activation details;
- carrier application;
- operating-system notification;
- carrier activation during device setup;
- supported device-to-device transfer.
What is inside an eSIM QR code?
The QR code normally encodes activation information understood by the LPA. It commonly directs the device to an SM-DP+ and supplies the reference needed to identify the intended profile transaction.
The QR image is therefore not the eSIM profile. Scanning it initiates a secure retrieval process.
Whether an activation code can be used more than once depends on the provider, profile state and policy. Businesses should not promise unlimited rescanning or reinstallation unless the actual provisioning model supports it.
Why delivery design matters
A frequent practical mistake is displaying the only QR code on the same phone that must scan it. Modern operating systems may support opening or long-pressing an activation link or QR image, but support varies by device and software version.
A customer journey should therefore offer suitable alternatives, such as:
- installation from a supported link;
- manual activation details;
- access through a second device;
- clear platform-specific instructions;
- a persistent account page from which the customer can retrieve the information safely.
Activation information should not be exposed through guessable public URLs or forwarded without warning.
Step 5: The device checks compatibility and prerequisites
Before downloading a profile, the device and service need suitable conditions.
Typical prerequisites include:
- eSIM-capable hardware;
- an enabled eUICC and functioning LPA;
- an operating-system version that supports the required flow;
- sufficient eUICC storage or profile capacity;
- an unlocked device where required;
- internet access for the download;
- correct date and time;
- permission or user consent to add a plan.
Apple states that an iPhone normally needs Wi-Fi or hotspot connectivity for eSIM setup, although certain eSIM-only models in some markets can activate without it. Android implementations also rely on the device's eSIM framework and LPA, with details varying by manufacturer and carrier.
The customer may not know whether a failure belongs to the device, the profile or the network. Compatibility checking before purchase reduces avoidable support cases.
Step 6: The LPA contacts the SM-DP+
After the activation information is accepted, the LPA connects to the indicated or discovered SM-DP+.
The system establishes the trust needed to continue the secure provisioning procedure. The process is designed to protect the profile and confirm that it is being delivered through authorised components to an eligible eUICC.
At this stage, a failure may be caused by:
- no internet connection;
- an incorrect or incomplete activation code;
- DNS, firewall or captive-portal interference;
- an expired or cancelled order;
- a profile already consumed by another installation;
- incompatible provisioning components;
- certificate or server validation problems;
- a temporary SM-DP+ service incident.
The commercial interface should not collapse all these causes into “invalid QR code”.
Step 7: The profile is securely downloaded and installed
Once the required checks succeed, the profile package is securely delivered and loaded into the eUICC.
The user sees a progress screen such as “Activating”, “Downloading SIM” or “Adding cellular plan”. Internally, the device may be obtaining profile metadata, requesting approval, preparing the eUICC and loading a profile package bound to the provisioning transaction.
The customer should avoid closing the process, restarting the phone or losing connectivity during this stage unless the operating system specifically instructs them to do so.
Installation can take seconds or minutes. An application calling the Android eUICC APIs receives asynchronous results because profile operations are not necessarily immediate.
Downloaded does not always mean enabled
A device may install a profile and then ask whether it should be enabled. It may also ask the customer to choose:
- a label for the new line;
- the default line for mobile data;
- the default number for calls or messages;
- whether data switching is allowed;
- whether data roaming should be enabled.
For a travel eSIM, the customer may install the profile before departure but keep it disabled until needed.
Step 8: The profile is enabled on the device
An installed profile must be enabled before it can be used by the modem. Device capabilities determine how many profiles can be stored and how many can be active simultaneously.
Enabling one profile may require another profile to be disabled. Some devices support two active lines, while others allow many stored profiles but fewer active subscriptions.
This stage is local to the device, but the user experience affects the service. Instructions should explain which line to select for data and how to prevent unintended use of the primary SIM while travelling.
Step 9: The device searches for and registers with a network
The modem reads the enabled subscription and searches for a permitted mobile network. It then attempts to register using the identity and authentication functions provided by the profile.
The visited network, home connectivity environment and subscription systems cooperate to authenticate the service and apply relevant roaming, policy and charging rules.
Possible outcomes include:
- successful registration on the preferred network;
- registration on an alternative permitted network;
- temporary rejection;
- no available permitted network;
- device incompatibility with the available radio bands or technology;
- roaming restrictions;
- subscription suspension or incorrect network-side configuration.
A successfully installed eSIM that displays “No Service” has passed the provisioning stage but has not completed usable network registration.
Step 10: A mobile data session is established
Network registration is still not identical to internet access. The device must establish a data session using the correct service configuration.
Depending on the product and device, relevant factors include:
- the selected line for mobile data;
- data roaming settings;
- APN configuration;
- subscription policy and available balance;
- network technology and signal quality;
- DNS and IP configuration;
- policy or fraud controls;
- the location of the internet breakout.
A phone can show network bars while data remains unavailable. Support teams should therefore check registration and data-session status separately.
Step 11: The commercial plan becomes active
The service provider decides which event starts the commercial validity period. Common rules include:
- time of purchase;
- profile allocation;
- first download;
- first installation;
- first enablement;
- first successful network registration;
- first data session;
- a fixed calendar date.
No single rule is universally correct, but the chosen rule must be technically observable and clearly explained.
For travel products, activation at first use can be customer-friendly, but it requires reliable event data from the connectivity supply chain. If the platform cannot observe first attachment or first data usage promptly, the displayed status may lag behind the real network state.
Step 12: Usage and lifecycle events are managed
Provisioning is the beginning of the profile lifecycle, not the end.
The platform may subsequently manage or display:
- usage and remaining allowance;
- top-ups or plan renewal;
- throttling or fair-use state;
- suspension and reactivation;
- profile enablement or disablement;
- expiry;
- replacement or transfer;
- cancellation;
- deletion from the device.
These actions do not all happen in the same system. Deleting a profile from the phone is a local eUICC operation. Cancelling a package can be a commercial operation. Suspending network access is a subscription-control operation. A good platform coordinates them and explains which actions can be reversed.
QR code, carrier activation, application or transfer?
Different delivery methods can lead to the same fundamental objective: installing an authorised profile on an eligible device.
QR code installation
The customer scans or opens a QR code and confirms the plan in device settings.
Advantages:
- broadly understood;
- easy to distribute through email or an account;
- does not necessarily require a dedicated application;
- suitable for independent travel eSIM sales.
Limitations:
- awkward when viewed on the installation device;
- vulnerable to forwarding or accidental exposure;
- customers may confuse the code with the profile itself;
- reuse and replacement rules are provider-specific.
Carrier activation
The carrier or provider assigns a plan so that the operating system can offer it automatically during or after device setup.
Apple describes eSIM Carrier Activation as a flow in which a carrier digitally assigns an eSIM and the device presents it for installation.
Advantages:
- reduced manual input;
- strong integration with device onboarding;
- familiar experience for customers buying a phone and subscription together.
Limitations:
- requires support across the carrier, device and operating-system ecosystem;
- may not be available to every reseller or travel provider;
- implementation and eligibility vary.
Carrier or partner application
A permitted carrier application can initiate supported profile operations through operating-system APIs.
Advantages:
- branded onboarding and account integration;
- fewer transitions between storefront and settings;
- opportunity to combine purchase, installation guidance and support.
Limitations:
- platform permissions and carrier privileges are controlled;
- iOS and Android capabilities differ;
- app development does not replace the certified provisioning infrastructure;
- the system interface may still appear for consent and secure operations.
Device-to-device transfer
Supported devices and carriers may offer a transfer flow when a customer changes phone.
Transfer should not be described as simply copying the profile. The old subscription instance is normally deactivated, replaced or moved through an authorised process so that the same credentials are not left active on two devices without permission.
Apple supports Quick Transfer for participating carriers and devices. Availability depends on carrier support, operating-system version, device proximity, account state and other controls.
Installation, activation and connection states
A white-label platform needs an explicit state model. The following table provides a useful starting point, although actual supplier APIs may use different terms.
| State | What it means | What it does not prove |
|---|---|---|
| Ordered | Commercial order accepted | Profile available or payment settled |
| Allocated | Profile associated with the order | Activation information delivered |
| Issued | Customer given an activation method | Profile downloaded |
| Download initiated | Device started provisioning | Installation completed |
| Downloaded or installed | Profile loaded on an eUICC | Profile enabled or connected |
| Enabled | Device selected the profile for use | Network registration succeeded |
| Registered | Subscription authenticated on a network | Mobile data session working |
| First data session | Data connectivity established | Customer experience or speed is satisfactory |
| Plan active | Commercial validity has started | Allowance remains available |
| Exhausted or expired | Allowance or validity ended | Profile necessarily deleted |
| Deleted | Profile removed from the device | Automatic reinstallation permitted |
Not every supplier exposes every state in real time. The platform should distinguish reported facts from inferred states. For example, a portal should not display “installed” solely because the customer opened an email.
Common eSIM provisioning failures
Effective troubleshooting starts by identifying the stage that failed.
The device cannot scan or open the activation information
Possible causes:
- damaged or low-resolution QR image;
- code displayed on the same device without a supported open-from-image function;
- camera or system scanner not using the eSIM installation flow;
- incomplete manual details;
- unsupported device or operating system.
Recommended response:
- provide platform-specific instructions;
- offer manual details or a supported activation link;
- confirm eSIM capability using the exact device model;
- avoid sending repeated replacement profiles before diagnosing the original order.
The code is recognised but the profile will not download
Possible causes:
- no usable internet connection;
- activation code expired, cancelled or already consumed;
- device locked to another carrier;
- insufficient eUICC capacity;
- SM-DP+ or upstream incident;
- confirmation code required;
- profile not prepared or incorrectly allocated.
Recommended response:
- confirm internet access and remove captive-portal issues;
- record the exact operating-system error;
- check the provisioning status in the supplier platform;
- collect the EID and order reference when appropriate;
- escalate without asking the customer to delete a partially installed profile unnecessarily.
The profile is installed but shows no service
Possible causes:
- line not enabled;
- no permitted network in the current location;
- device lacks the relevant radio bands;
- roaming or subscription restrictions;
- network-selection problem;
- subscription not active on the network side.
Recommended response:
- verify that the eSIM line is enabled;
- check coverage and supported networks;
- try automatic and, where appropriate, manual network selection;
- toggle flight mode or restart the device;
- confirm the subscription state with the connectivity provider.
The device registers but mobile data does not work
Possible causes:
- wrong line selected for mobile data;
- data roaming disabled;
- incorrect APN;
- zero balance or expired package;
- policy or fraud block;
- temporary data-session or routing problem.
Recommended response:
- confirm the selected data line;
- follow the product's roaming and APN instructions;
- check balance, validity and policy state;
- collect network, country, timestamp and device information for escalation.
The customer deleted the profile
Deletion can be more serious than disablement. Some profiles can be reissued or reinstalled, while others require a replacement transaction.
The customer interface should warn users before deletion and avoid wording that suggests the profile can always be restored. Support teams need a clear policy for accidental deletion, device loss and handset replacement.
What should a white-label eSIM platform provide?
A partner does not need to expose technical acronyms to every customer. It does need enough operational visibility to manage the service responsibly.
Clear product rules
The catalogue should define:
- when validity begins;
- which networks and countries are included;
- whether the product is data only;
- installation and reinstallation rules;
- top-up and reuse capability;
- fair-use and throttling rules;
- refund conditions;
- supported device requirements.
Reliable order-to-profile orchestration
The platform should coordinate payment, fraud screening, profile allocation and customer delivery. It should handle duplicate requests and retries safely, so that a delayed response does not allocate several profiles or charge the customer twice.
Useful API states and webhooks
Partners integrating by API should ask which events are available and how they are defined.
Important questions include:
- Is profile allocation synchronous or asynchronous?
- Which identifier should be used for idempotency?
- Can the platform report download, installation, first attachment and first usage separately?
- Are webhooks signed and retried?
- How are out-of-order events handled?
- Can the partner query the authoritative current state after missing a webhook?
- How quickly is usage data updated?
- Which errors are safe to retry?
Secure activation-information delivery
QR codes and activation details should be protected from casual exposure. Appropriate controls can include authenticated account access, expiring presentation links, access logging and restrictions on what support agents can view.
Security must remain practical. A customer who loses an email should have a safe recovery path without forcing the business to expose activation data publicly.
Platform-specific customer instructions
iPhone and Android experiences are similar in purpose but not identical in wording or available methods. Instructions should be updated as operating systems change.
Good guidance explains:
- how to confirm device compatibility;
- how to install from a QR code, link or manual details;
- which line to select for data;
- whether data roaming is required;
- how to label the line;
- what not to delete;
- what information to collect before contacting support.
Operational escalation
First-line support needs more than a generic “contact the carrier” response. An escalation record should normally include:
- order and profile reference;
- ICCID where appropriate;
- device model and operating-system version;
- EID or IMEI when required for diagnosis;
- country and network;
- exact error message;
- timestamp and time zone;
- whether the profile is visible, enabled and selected for data;
- steps already attempted.
Personal identifiers and activation information should be handled according to the organisation's security and privacy controls.
A practical example: travel eSIM purchase before departure
Consider a customer in London buying a seven-day data eSIM for Spain.
- The customer selects the Spain package and confirms that the phone is eSIM-compatible and unlocked.
- Payment succeeds and the platform allocates a profile.
- The customer receives secure access to a QR code and installation instructions.
- While connected to home Wi-Fi, the customer installs the profile before travelling.
- The profile is stored on the phone but the customer leaves it disabled.
- After arriving in Madrid, the customer enables the travel line, selects it for mobile data and enables roaming if the product requires it.
- The device registers with one of the permitted Spanish networks.
- The first data session triggers the seven-day validity period, assuming that this is the product's defined activation rule.
- Usage events flow to the provider platform and then to the branded customer portal.
If the customer installs the profile successfully in London but sees no service, that may be entirely normal if the subscription is intended only for Spain. If the portal describes the profile as “failed” simply because it has not yet attached, it creates unnecessary concern.
Provisioning metrics worth monitoring
Businesses should measure more than completed sales.
Useful operational metrics include:
- time from payment to profile allocation;
- activation-information delivery success;
- percentage of issued profiles that begin download;
- download and installation success rate;
- median time to installation;
- percentage of profiles reaching first network registration;
- time from installation to first use;
- failure rate by device, operating system and supplier;
- replacement rate;
- accidental-deletion cases;
- support contacts per 1,000 profiles;
- refund rate before and after download;
- delayed or missing usage-event rate.
These measures reveal different problems. A low download-start rate may indicate poor instructions. A low installation-completion rate may indicate provisioning errors. A low first-use rate may result from customers buying well before travel rather than from failure.
Security and privacy considerations
Remote provisioning is designed to protect mobile credentials, but the surrounding commercial system still requires careful security.
Businesses should consider:
- access control for profile inventory and activation information;
- authentication for customer accounts;
- secure API credentials and webhook validation;
- encryption in transit and at rest where appropriate;
- separation of duties for support and administration;
- logs for allocation, delivery, replacement and cancellation;
- controls against automated profile purchasing and payment fraud;
- retention rules for EID, IMEI, ICCID and customer data;
- incident procedures for exposed activation information;
- supplier access and subcontractor responsibilities.
The QR code should not be presented as harmless simply because the protected profile is stored elsewhere. Unauthorised use can create commercial loss, customer disruption and support work.
Questions to ask an eSIM provisioning provider
Before launching, ask the provider:
- Which GSMA consumer provisioning architecture and versions are supported?
- Who operates the SM-DP+ and which responsibilities remain with upstream suppliers?
- Which delivery methods are available: QR, link, app, carrier activation, discovery or transfer?
- Which profile states are reported, and which are inferred?
- What event starts package validity?
- Can a profile be reinstalled or transferred after deletion or device replacement?
- How are duplicate API requests and timeouts handled?
- Which provisioning errors are returned through the API?
- Are webhooks signed, retried and queryable afterwards?
- How quickly are first-use and usage events reported?
- What is the escalation process for SM-DP+ or network incidents?
- Which device and operating-system combinations are tested?
- How are activation details protected and recovered?
- Who owns the customer, profile and operational data?
- How can active services be migrated if the commercial relationship ends?
How SIM24.biz fits into the provisioning journey
SIM24.biz enables businesses to build branded connectivity propositions while relying on specialist technology, connectivity and operational infrastructure.
In a white-label model, the partner can own the brand, product, pricing and customer relationship. The underlying provisioning journey can connect the partner's storefront or application with the systems required to allocate and deliver eSIM profiles and manage the subsequent service lifecycle.
The precise functions, delivery methods, lifecycle controls and supplier responsibilities depend on the selected implementation. They should be confirmed during solution design rather than assumed from the term “white-label”.
The objective is not to expose every technical component to the end customer. It is to make a complex process reliable, measurable and easy to support under the partner's brand.
Conclusion
eSIM provisioning converts a commercial order into an installed mobile subscription through a secure chain of systems.
The provider allocates or prepares a profile. Activation information allows the device's Local Profile Assistant to contact the appropriate SM-DP+. The profile is securely downloaded to the eUICC, installed and enabled. The modem then uses it to register with a permitted network and establish the required service.
Each stage has its own status and possible failure. Purchase is not download. Download is not enablement. Enablement is not network registration. Network registration is not necessarily a working data session. None of these automatically defines when commercial validity begins unless the product rules say so.
A successful eSIM business therefore needs more than a QR-code generator. It needs coordinated fulfilment, secure delivery, accurate lifecycle states, reliable APIs, clear instructions, measurable operations and support that can locate the real point of failure.
Frequently asked questions
Is an eSIM QR code the actual eSIM?
No. The QR code normally contains activation information used by the device to locate and request the intended profile through remote provisioning infrastructure. The protected profile is downloaded separately to the eUICC.
What is an SM-DP+?
The SM-DP+ is the subscription-management service that prepares, protects and delivers consumer eSIM profiles. The device's LPA communicates with it during profile download.
What is an LPA?
The Local Profile Assistant is the device-side component that supports profile download and management. It mediates between the provisioning service and the eUICC and may provide the user interface for adding and managing eSIMs.
Does a phone need internet access to install an eSIM?
Usually yes. The phone commonly uses Wi-Fi or another active mobile connection to contact the provisioning infrastructure and download the profile. Some devices and carrier-supported activation models may provide alternatives.
Is an installed eSIM automatically active?
Not always. A profile may be installed but disabled. Even when enabled, the device must still register with a permitted mobile network and establish the required service.
When does an eSIM data package start?
That depends on the provider's product rules. It may start at purchase, installation, first network registration, first data use or a specified date. The customer should be told which rule applies before buying.
Can the same QR code be scanned on two phones?
Normally the same subscription should not be expected to install and remain active on two unrelated devices. Code reuse depends on the provisioning state and provider policy. Customers should not share activation details.
Can an eSIM be transferred to a new phone?
Sometimes. Supported transfer methods depend on the device, operating system, carrier and provider. A transfer is an authorised lifecycle process, not simply copying the existing profile.
What is the difference between EID and ICCID?
The EID identifies the eUICC in the device. The ICCID identifies a particular SIM profile or subscription instance. One eUICC can store multiple profiles with different ICCIDs.
Why does an installed eSIM show “No Service”?
Possible reasons include a disabled line, lack of permitted coverage, device band limitations, network-selection issues, roaming restrictions or an inactive subscription. Successful installation confirms provisioning progress, not usable network coverage.
Should a customer delete an eSIM when troubleshooting?
Not unless the provider or device instructions specifically require it. Deletion may make reinstallation impossible without a replacement profile. Disabling and re-enabling the line is different from deleting it.
Build a provisioning journey customers can trust
SIM24.biz helps businesses combine branded customer experiences with the connectivity and operational infrastructure required to deliver eSIM services.
Talk to SIM24.biz about provisioning, platform integration and the right activation journey for your proposition.
Sources
- GSMA, “How it works - eSIM”: https://www.gsma.com/solutions-and-impact/technologies/esim/how-it-works/
- GSMA, “How GSMA IoT and consumer eSIM powers innovation”: https://www.gsma.com/solutions-and-impact/technologies/esim/about/
- GSMA, “SGP.21, eSIM Consumer Architecture Specification”: https://www.gsma.com/solutions-and-impact/technologies/esim/wp-content/uploads/2024/09/SGP.21-v2.6.pdf
- GSMA, “SGP.22, eSIM Consumer Technical Specification”: https://www.gsma.com/solutions-and-impact/technologies/esim/gsma_resources/sgp-22-v2-7/
- Android Open Source Project, “Implement eSIM”: https://source.android.com/docs/core/connect/esim-overview
- Apple Support, “Set up eSIM on iPhone”: https://support.apple.com/en-us/118669
- Apple Support, “If you can't set up an eSIM on your iPhone”: https://support.apple.com/en-us/102478
- Google Pixel Help, “Set up a new eSIM”: https://support.google.com/pixelphone/answer/16115470