eSIM transfer carrier integration

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.

eSIM transfer architecture

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:

  1. EAP-AKA
  2. CheckEligibility
  3. AcquireTransferToken

The entitlement server returns a temporary token and an expTime value indicating the lifetime of the token.

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:

  1. manageSubscription (for example, transfer, token)
  2. AcquireConfigurations (apply to delayed eSIM transfer procedure only)

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.

D2D link setup flow sequence

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.

D2D link setup flow UI

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.

D2D link settings flow UI

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 by manageSubscription(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 skips ManageSubscription(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 from checkeligibility and manageSubscription 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.