The 4 main Wallet Secure Cryptographic Device/Application options compared 

Digital identity management is undergoing a significant transformation in the European Union with the adoption of eIDAS 2.0. This regulation introduces standardized digital identity wallets, aiming to provide citizens with secure, interoperable solutions for managing their digital identities across all EU member states.

The development of these digital wallets is guided by the Architectural Reference Framework (ARF), currently in version 1.4. This framework, developed by the eIDAS Expert Group (comprising representatives from EU member states’ digital identity authorities, technical staff from national cybersecurity agencies, and EU digital governance specialists) along with key industry participants like THALES Digital Identity & Security division, establishes the technical specifications and security requirements for implementing digital identity wallets.

A crucial aspect of the ARF is how it defines the security architecture for these wallets. At its core, each wallet solution consists of a Wallet Instance (WI) – the mobile app that users interact with – and its secure components: the Wallet Secure Cryptographic Device (WSCD) and the Wallet Secure Cryptographic Application (WSCA). The WSCD provides a secure hardware environment, while the WSCA manages the cryptographic operations within this environment. These components communicate through a Secure Cryptographic Interface (SCI), safely handling sensitive operations like digital signatures and identity verification.

This article will examine the four main approaches to implementing these secure components (WSCD/WSCA). It will analyze their strengths and limitations across key criteria, including scalability, inclusivity, user-friendliness, and recovery capabilities. Understanding these options is crucial for stakeholders implementing eIDAS 2.0-compliant digital identity solutions.

Displays the options for secure eWallets. Secure cryptographic device and application options. WSCD/WSCA.

Topic 16 of Annex 2 in ARF v1.4 specifies requirements for wallets to generate Qualified Electronic Signatures. Wallet providers must ensure that a Wallet Instance can generate a signature value either through local or remote signing applications.

WSCD and WSCA: Key components

The implementation of secure digital identity wallets under eIDAS 2.0 requires a robust security architecture. The Architectural Reference Framework defines several critical components that form the foundation of this secure infrastructure.

The ARF establishes two primary security components:

  • Wallet Secure Cryptographic Device (WSCD): The trusted hardware component that functions as the secure vault for digital identity credentials. The WSCD provides a protected environment and storage for cryptographic assets (e.g., private keys), ensuring tamper-proof and duplication-proof security for all cryptographic functions. This hardware-based security approach prevents unauthorized access and manipulation of sensitive cryptographic materials.
  • Wallet Secure Cryptographic Application (WSCA): The secure application executing on the WSCD that serves as the operational layer for cryptographic functions. The WSCA manages assets (such as keys) for a specific Wallet Instance, controlling access and operations related to the digital identity credentials stored in the WSCD.

The integration of these components relies on the Secure Cryptographic Interface (SCI), which facilitates communication between the Wallet Instance (WI), WSCA, and WSCD. The SCI provides a secure protocol for managing cryptographic assets and executing cryptographic operations, ensuring the integrity and confidentiality of all interactions between these components.

This architectural approach creates a comprehensive security framework that maintains the integrity of digital identity credentials while enabling authorized cryptographic operations.

The 4 types of WSCD/WSCAs for wallets

The Architectural Reference Framework identifies four distinct approaches to implementing the WSCD/WSCA security architecture. Each implementation type maintains the high security requirements mandated by eIDAS 2.0 while offering different deployment and integration options:

  1. Local External WSCD/WSCA: This implementation utilizes external hardware devices specifically designed for cryptographic operations. These devices, such as hardware security tokens, USB tokens, or smart ID cards, provide a physically separate secure environment. The separation from the main device offers additional security through hardware isolation, making it particularly suitable for high-security requirements.
  2. Local WSCD/WSCA – platform: OEM Native SE: This approach leverages the built-in hardware security modules (HSMs) provided by device manufacturers. Examples include Samsung’s Knox platform and Apple’s Secure Element, which are integrated directly into premium smartphone hardware. These implementations benefit from deep integration with the device’s security architecture while being managed by the Original Equipment Manufacturer (OEM).
  3. Local WSCD/WSCA (Mobile-integrated): This category encompasses secure elements integrated within the mobile device’s architecture through various technologies:
    • SIM solutions: Utilizing the hardware security capabilities of physical SIM cards
    • eSIM solutions: Implementing security through embedded SIMs, allowing wallet providers to deploy Java Card applets directly
    • eSE solutions: Leveraging embedded Secure Elements like Google’s StrongBox or Apple’s Secure Enclave, accessed through the mobile operating system’s security framework
  4. Remote WSCD/WSCA: This implementation moves the secure element to a cloud infrastructure, providing a Hardware Security Module as a Service (HSMaaS). The cryptographic operations and secure storage occur in remote, highly secured data centers while maintaining accessibility through secure network connections.

The distinction between these implementations lies in their approach to securing cryptographic operations and storing sensitive data. While the WSCD component provides the secure environment in each case, the WSCA manages the cryptographic operations and access control, regardless of the physical or virtual location of the secure element. This architectural flexibility allows wallet providers to select the implementation that best matches their security requirements, deployment constraints, and user experience goals.

Evaluating WSCD/WSCA Implementation Options

Before analyzing each implementation option, let’s establish the key evaluation criteria for digital identity wallet solutions:

  • Persistent identification (high level): Ability to maintain high-level identification without frequent hardware verification
  • Scalability: Ease of deployment and implementation across large populations
  • Inclusivity: Accessibility across different socioeconomic groups and device types
  • Rapid recovery: Efficiency of credential recovery after loss or compromise
  • User-friendliness: Ease of use and integration with daily activities
  • Remote unattended: Capability for remote updates and maintenance
A table comparing the technological options for Wallet Secure Cryptographic Device/Application options.

Local External WSCD/WSCA

External hardware solutions like tokens and smart cards provide robust security through physical isolation of cryptographic operations. These devices offer strong protection against tampering and unauthorized access, making them particularly suitable for high-security use cases and organizations with strict security requirements.

However, the reliance on physical hardware introduces significant operational challenges. The need to distribute and manage physical devices complicates large-scale deployments, while device loss requires complex recovery procedures. Additionally, the requirement for physical presence during maintenance operations limits the ability to perform remote updates and security patches.

  • Strong points: High security, physical isolation, tamper resistance
  • Limitations: Complex recovery, limited remote maintenance, reduced user convenience

Local WSCD/WSCA – Platform OEM Native SE

Platform-native secure elements leverage sophisticated hardware security modules built into premium smartphones. This integration provides seamless user experience through deep integration with device security features, offering strong protection while maintaining convenience for users already owning compatible devices.

The primary limitation of this approach lies in its dependency on premium hardware. The requirement for specific device capabilities creates an accessibility barrier, as not all users have access to or can afford premium smartphones. This hardware dependency also impacts scalability, as deployment is inherently limited to users with compatible devices.

  • Strong points: Seamless integration, strong security, excellent user experience
  • Limitations: Limited device compatibility, reduced inclusivity, scalability constraints

Local WSCD/WSCA: SIM/eSIM/eSE

Mobile-integrated secure elements combine the benefits of hardware security with broader accessibility through various implementation options. The flexibility of deployment methods, particularly through eSIM solutions, enables rapid distribution and updates while maintaining robust security through dedicated hardware components.

These solutions leverage existing mobile infrastructure but often require coordination with telecommunications providers, which can introduce deployment complexities. While more accessible than OEM Native solutions, the dependency on specific mobile operators or device capabilities can still impact inclusivity.

  • Strong points: Flexible deployment, good security, efficient distribution
  • Limitations: Telco dependency, varied device support, moderate recovery complexity

Remote WSCD/WSCA

Remote secure elements represent the most flexible approach, offering cloud-based security infrastructure that combines accessibility with sophisticated security measures. This implementation enables broad device compatibility while maintaining high security standards through professional data center infrastructure.

The cloud-based nature of this solution simplifies deployment, maintenance, and recovery procedures. Once initial high-level identification is established, users maintain persistent access without requiring premium hardware or frequent reverification. This approach particularly excels in scenarios requiring rapid scaling and inclusive access across diverse user populations.

  • Strong points: High scalability, broad inclusivity, simple recovery, excellent maintainability
  • Limitations: Network dependency, initial verification requirements

Through this analysis, the Remote WSCD/WSCA implementation emerges as a particularly promising solution for widespread digital identity deployment under eIDAS 2.0, offering an optimal balance of security, accessibility, and operational efficiency.

Why Ubiqu bets on the Remote Secure Element

By placing the secure element in Google’s data centers or client-specific data centers, this solution establishes a unique and robust connection between mobile devices and the remote hardware security modules (HSMs), effectively transforming how digital identity security is managed on mobile devices. Unlike traditional local secure elements that face challenges with device dependencies and recovery procedures, the Remote Secure Element technology addresses key limitations of other WSCD/WSCA implementations.

“We saw that each traditional approach had significant drawbacks,” explains Guus Stigter, COO and co-founder of Ubiqu. “External tokens aren’t user-friendly, OEM solutions limit you to premium phones, and SIM-based solutions often tie you to specific telecoms. Our Remote Secure Element solves all of these challenges – when you lose your phone, you haven’t lost your whole digital life because your encryption keys remain securely stored in the data center. This means recovery is simple, the solution is scalable, and it works on any device while maintaining the highest security standards.”

Related Blog