This page describes a secure, trusted, and seamless way to transfer eSIM profiles and physical SIM data from one Android device (referred as the source device on this page) to another eSIM-capable Android device (referred to as the target device).
Architecture
The diagram in Figure 1 illustrates the key components and high-level flow for the GSMA TS.43 ODSA subscription transfer with a temporary token.
Figure 1. eSIM Transfer architecture.
The following table provides detailed descriptions of the steps in Figure 1:
Step | Description |
---|---|
1 | The eSIM Transfer client on the target device initiates a transfer starting from device pairing. |
2 | After the two devices are paired, the transfer client on the target device requests a transferable profile list from the target device. |
3 | The eSIM Transfer client on the source device performs the following TS.43 procedures:
The entitlement server returns a temporary token and an
|
4 | The user selects a profile to transfer and the LPA requests an activation code. |
5 | The transfer client on the target device performs the following TS.43 procedures:
The entitlement server returns the activation code. |
6 | The eSIM Transfer client on the target device returns the activation code to the LPA. |
7 | A secure channel is established between the SM-DP+ and the LPA through the ES9+ interface, and the profile is downloaded from the SM-DP+ server. The profile download is based on the activation code. |
8 | The LPA downloads the eSIM profile to the eUICC. |
eSIM Transfer clients are apps provided by device manufacturers that allow for the transfer of eSIM profiles and physical SIM data from one device to another, or to convert physical SIMs to eSIM on the same device. eSIM Transfer clients are compatible on source devices running Android 10 and higher and target devices running Android 14 or higher.
GSMA TS.43 subscription transfer with temporary token and EAP-AKA
The supported GSMA TS.43 ODSA primary-based eSIM Transfer method follows the call flows as described in Section 8.9 of GSMA TS.43. For carriers, implementing this eSIM Transfer method requires additional server-side integration, which is described in the TS.43-related requirements subsection under the Technical Requirements section.
We recommend the TS.43 temp-token with EAP-AKA approach (CR1052 method).
eSIM Transfer flows
eSIM Transfer flows are included in the setup flow or in Settings.
eSIM Transfer flows in the setup flow
The setup user flow is the first UI that users interact with when starting their Android phone for the first time or after a device factory reset. The setup flow guides them through the process of setting up their Android phone and includes items such as data transfer, Wi-Fi connection, and backup. Connecting to a mobile network either with a physical SIM or eSIM is part of the setup flow. The eSIM Transfer solution requires that both the target and source devices establish a device to device (D2D) connection.
Figure 2. Setup flow sequence for target devices using D2D link setup.
The setup flow helps set up the device by transferring accounts and importing data from another Android device.
The setup flow includes the eSIM Transfer flow step if the following conditions are met:
- The user paired their target device with their source device in step 2 of the setup flow.
- The carrier confirmed that the physical SIM or eSIM in the source device is eligible for eSIM Transfer in step 2.
- No eSIM profile was assigned to the target device through the SM-DS or Default SM-DP+ method in step 5.
- The paired source device was secured with a screen lock, and the user's source device screen lock was successfully verified in step 6.
The target device maintains an eSIM notification in the notification drawer for as long as required to fully complete the eSIM Transfer transaction with the carrier infrastructure, including the eSIM profile download and installation step. Depending on the carrier implementation, this operation can be almost instant or it can be delayed until after the device setup is finished.
Figure 3. Example UI screens for target devices using D2D link setup by the setup flow.
The following table provides detailed descriptions of the steps in Figure 3:
Step | Description |
---|---|
1 | When a user initiates the transfer flow on the target device, a QR code is displayed, and the source device displays a pop-up for the transfer request. |
2 | The device displays a security challenge for user authentication. |
3 | The target device checks for eligible profiles that can be transferred on the source device. |
4 | The device displays a list of transferable and non-transferable profiles. |
5 | The user provides final confirmation of the transfer. |
6 | The transfer is in progress. |
Users can also initiate the eSIM Transfer flow through the Settings screen. Figure 4 describes an example UX flow using the D2D transfer from Settings.
Figure 4. Example UI screens for target devices using D2D link setup by the setting flow.
The following table provides detailed descriptions of the steps for the target and source devices in Figure 4:
Step | Description (target device) | Step | Description (source device) |
---|---|---|---|
1 | The user selects the SIMs menu in Settings. | ||
2 | The user selects the Transfer a SIM from another device button. | ||
3 | The device displays a QR Code for D2D pairing. | 1 | The device displays a pop-up for the transfer. |
4 | The target device checks for eligible profiles that can be transferred on the source device. | 2 | The device displays a screen to scan the QR Code of the target device for D2D pairing. |
5 | The device displays a list of transferable and non-transferable profiles. | 3 | The device shows that the QR Code is scanned for D2D pairing. |
6 | The device prompts user to confirm the transfer on the source device. | 4 | The device displays a security challenge for user authentication. |
7 | The device shows that the transfer is in progress. | 5 | The device shows that the transfer is in progress. |
8 | The device shows that the transfer is completed. |
Security
To ensure that eSIM data is transferred securely, the following are required:
- Device proximity (which is characterized by successful D2D pairing between the source and target device). The communication channel between the source device and the target device is end-to-end encrypted with a rotating key and an incrementing frame number to prevent replay attacks and man-in-the-middle attacks.
- The source device must be protected with a screen lock (for example, a PIN lock).
- The source device screen lock verification must be used to authorize and proceed with the eSIM Transfer flow.
For example, a secure way to transfer SIMs across devices is if the source device is in physical proximity with the SIM, so users can unlock the source device.
TS.43 temporary carrier token storage
For the eSIM Transfer client in both the source and target devices, the TS.43 temporary carrier token is stored under the block store, an encrypted (keystore encryption) credential storage solution. After the transfer completes, the source device token is cleared from the block store. No API is exposed to access the TS.43 temporary carrier token from other first-party and third-party apps.
Carrier onboarding process
The following sections describe the requirements for carriers to support eSIM transfer on their devices.
Choose an entitlement server implementation
All major entitlement server (ES) providers support eSIM Transfer. Contact an ES provider for details on the process for supporting eSIM Transfer on your devices.
Carrier requirements for TS.43 ES integration
To support the GSMA TS.43 ODSA primary-based eSIM Transfer flow, the mobile carrier MUST support an ES following the GSMA TS.43 specification.
TS.43-related requirements
- [Mandatory] The ES MUST implement the TS.43 procedure as described in the GSMA TS.43 specification.
- [Mandatory] The ES and carrier backend MUST support EAP-AKA as the authentication method.
- [Strongly recommended] The ES SHOULD separate the subscription
transfer and subscription activation operations. This prevents carriers
from deactivating the pSIM or eSIM in the source device if there's a
profile download failure in the target device, so users don't have
deactivated SIMs on both devices. Refer to the following list for more
details:
ManageSubscription(3:TRANSFER)
SHOULD be followed byManageSubscription(4: UPDATE SUBSCRIPTION)
to ensure the successful profile download before the ES triggers the transfer in the carrier network.ManageSubscription(4: UPDATE SUBSCRIPTION)
SHOULD deactivate the pSIM/eSIM in the source device and activate the newly downloaded eSIM profile on the target device.- If the carrier backend can't support separate activations (that is,
the backend can't release the eSIM without activating it), the
backend SHOULD return the service status as
1(activated)
. Then the eSIM Transfer client skipsManageSubscription(4: UPDATE SUBSCRIPTION)
.
- [Strongly recommended] The carrier ES SHOULD return the MSISDN
associated with the subscription in
AcquireTemporaryToken
. - [Strongly recommended] For the TS.43 subscription transfer, the
carrier backend system SHOULD be able to process a SIM swap request
(triggered by an authorized
ManageSubscription(3:TRANSFER SUBSCRIPTION)
function) in under 5 seconds for the majority of all transactions. - [Mandatory] If the carrier backend system requires more than a few seconds to respond to the SIM swap request, the carrier and ES MUST support delayed download by polling defined in TS.43 section 7.3.2.
- [Mandatory] Carrier to return
GeneralErrorText
fromCheckEligibility
andManageSubscription
response defined in TS43 section 6.5.1. - [Mandatory] Eligibility check (refer to section 6.5.2 CheckEligibility
Operation in GSMA Service Entitlement Configuration) MUST support the
following:
- Failure due to account issues (for example, suspended account, unpaid dues, or eSIM Transfer restrictions)
- Failure due to device liability (for example, enterprise, prepaid, or MVNO)
- Failure due to device block list (for example, fraud alert or stolen)
- [Strongly recommended] Given that personally identifiable information
(PII) is exchanged between the device and the ES, we strongly recommend that
the ES implement best practices, such as:
- Using only TLS 1.2 or 1.3.
- Disabling RC4 and SSL3.
- Disabling TLS compression as it's vulnerable to CRIME attacks.
- Selecting safe cipher suites, preferably those providing perfect-forward secrecy, for example, TLS_AES_256_GCM_SHA384 as defined in TLS 1.3.
Final delivery
To enable the eSIM Transfer method for your network, work with the device manufacturers on implementation.