Android My Number Card Set for Fall Overhaul, Moving Away from FeliCa Dependence to Expand Device Compatibility — BigGo Finance

From the perspective of years of reporting on Japan’s mobile payment infrastructure, analyzing the technical differences between Apple Pay and Google Pay reveals that the specification changes planned for the Android version of the My Number Card in fall 2026 represent a major departure from the long-standing “Osaifu-Keitai dependence.”

Apple Pay stores card information required for payments in an embedded Secure Element (eSE) built into the device itself. The SE is a small computer conforming to Java Card specifications, enabling contactless payments via an NFC controller. However, its capacity is limited to just a few megabytes, which initially imposed a restriction of up to eight cards that could be registered in Wallet.

This structure changed significantly with the release of iOS 17 in September 2023. As the Digital Markets Act (DMA) took effect in Europe and pressure mounted on Apple to open access to the SE, the company opened SE access methods to third parties that bypass Wallet, while simultaneously introducing a dynamic load/unload mechanism that effectively eliminated the card count limit.

Specifically, whereas previously all card applets resided permanently in the SE, the new approach offloads (unloads) them to a Secure Enclave-protected area based on usage frequency, and writes them back (loads) to the SE when needed. The Secure Enclave is a security subsystem independent of the main processor, embedded in the A-series SoC and introduced with the iPhone 5s’s Touch ID. It has functioned as a protected area for biometric data and iCloud Keychain.

This load/unload process occurs automatically. Frequently used cards are likely to remain in the SE, so active/inactive switching can handle most cases. When the SE is determined to be running low on capacity, cards with lower usage frequency are swapped to the Secure Enclave side in order. However, cards designated as Express Cards are fixed at the top priority and are excluded from this dynamic swapping. For Express Cards, where response speed is critical, applets always remain within the SE’s protected area.

Meanwhile, Google Pay on Android smartphones fundamentally implements NFC contactless payments using HCE (Host Card Emulation). HCE does not use an eSE; instead, the NFC controller communicates with an area within the host OS to achieve secure communication. However, unlike a hardware-protected SE, the host OS and main processor handle control, making information leakage risks from hacking a concern. This is where TEE (Trusted Execution Environment) and LUK (Limited Use Key) come into play.

TEE is a protected area that operates independently of the main host OS, built using mechanisms such as TrustZone. TrustZone prior to ARMv7 lacked memory protection and automatic register refresh functions, creating risks of data inference within the secure area during mode switching. However, from ARMv8 onward, a hypervisor is standard-equipped, allowing TEE to be protected in a more secure manner.

LUK is a one-time-use cryptographic key issued per device, characterized by configured expiration dates and usage limits. With HCE, devices must periodically go online to connect to a TSM (Trusted Service Manager) server and refresh information. This is a major difference from Apple Pay, which can essentially continue operating in an offline state.

Another implementation method for Google Pay is the eSE approach, represented by Japan’s unique “Osaifu-Keitai.” The reason lies with FeliCa. Because FeliCa SE cannot be implemented as HCE by specification, the eSE-embedded approach was adopted. A specification called HCE-F, which resembles a FeliCa version of HCE, also exists, but it merely emulates the communication interface and does not guarantee FeliCa SE operation on TEE. It is said to be difficult to meet speed requirements and pass verification.

As a result, Google Pay in Japan operates as a hybrid of HCE and eSE. Contactless payments for credit cards use HCE, while FeliCa-based payment methods such as Mobile Suica and iD/QUICPay use eSE. Consequently, devices without eSE—those not supporting Osaifu-Keitai—cannot use the latter services, which also affects whether the My Number Card can be installed.

It should be noted that the dynamic load/unload mechanism used on iPhone has not been adopted on Android. When using transit IC cards like Suica or PASMO with Osaifu-Keitai, they occupy a significant portion of the FeliCa SE’s secure area, making memory management through dynamic swapping difficult—this is believed to be the reason.

Currently, the My Number Card on Android only carries two types of electronic certificates: the “signature electronic certificate” and the “user verification electronic certificate.” Card face information such as address and name cannot be retrieved. Therefore, while Android smartphones can be used for identity verification and electronic signatures, they cannot populate form fields using the card face information printed on the My Number Card, nor can the other party verify the correctness of entered information.

With the Android version of the My Number Card releasing this fall, the approach will change to match iPhone’s method, enabling not only card face information verification but also identity confirmation through verifiable credentials (VC) following the IHV (Issuer, Holder, Verifier) model, as part of a Digital Identity Wallet (DIW).

Currently, the My Number Card on Android is limited to “Osaifu-Keitai compatible devices.” This is because the electronic certificates are installed in the GP-SE, effectively presupposing the use of the FeliCa SE (i.e., GP-SE) built into Osaifu-Keitai-equipped Android devices sold domestically in Japan.

There appears to have been internal debate within Japan’s Digital Agency, but the decision to use FeliCa SE for electronic certificate storage was apparently made with compatibility as the priority. According to sources familiar with the matter, Type-B, which the My Number Card uses, has significant read compatibility issues. Due to specification reasons, inter-device communication determination is strict and design is difficult, with challenges such as communication interruptions caused by external factors like noise. Therefore, rather than supporting a wide range of NFC-equipped devices, it was determined that Osaifu-Keitai compatible devices that have strictly cleared RF performance and interoperability testing would present fewer problems.

However, the upcoming Android version of the My Number Card will revise this policy and adopt an approach that does not use eSE. Specifically, it will use a mechanism called “StrongBox,” storing My Number Card information in a protected area and enabling digital authentication through Google Wallet’s standard framework, similar to iPhone.

StrongBox is a security subsystem that operates independently of the main processor, comparable to Apple’s Secure Enclave. While the TEE used in HCE relies on the main processor’s TrustZone, StrongBox enables higher security, and there are cases where TEE is built using this mechanism.

The secure area provided by StrongBox stores payment information and digital certificates, as well as information used for biometric authentication such as unlock credentials. However, because Android does not have the vertical integration of a single vendor like Apple, implementation methods—including whether to actually incorporate StrongBox-like mechanisms—are left to the discretion of device manufacturers.

For example, Google employs a dedicated security chip called “Titan” in Pixel devices, while Qualcomm’s Snapdragon SoCs contain a processing block called “SPU (Secure Processing Unit)” that is independent of the main CPU—the hardware itself differs. Therefore, StrongBox is specified as a HAL (Hardware Abstraction Layer) that abstracts the hardware component, providing implementation flexibility in this regard.

Most smartphones currently shipped in Japan are believed to support StrongBox, but caution is needed for imported devices and mid-range/low-end models where this may not be the case.

Since the My Number Card on Android adopts a whitelist approach where compatible devices are reflected in Japan’s Digital Agency database after manufacturer verification results, even if the next-generation Android My Number Card no longer requires Osaifu-Keitai support and shifts to a StrongBox base with expanded compatible devices, inclusion in the official compatibility list is not necessarily guaranteed.

Additionally, some may speculate that with StrongBox-like dedicated hardware replacing the TEE mechanism, FeliCa SE-less devices might soon be supported via StrongBox. However, that would be difficult. Osaifu-Keitai support fundamentally requires embedding FeliCa middleware and passing FeliCa certification, and these challenges cannot be resolved through StrongBox alone.

This specification change marks a turning point in Japan’s digital identity infrastructure, transitioning from hardware dependence to software-based flexible implementation. Just as Apple Pay leveraged the Secure Enclave to increase card management flexibility, the Android side is now utilizing StrongBox to break free from the physical constraints of FeliCa SE while maintaining security standards—a clear shift in direction.