Member states must offer at least one EUDI Wallet by December 2026, and from December 2027 regulated sectors will be required to accept it. For qualified trust service providers and signing platforms, this creates a new route to qualified signatures at population scale, since every citizen will carry a wallet that can activate a qualified signature. To use that route, however, the infrastructure behind the wallet has to pass certification, and that is where many current plans run into trouble.
In a recent Ubiqu webinar, independent digital identity and trust consultant Dick Dekkers and Ubiqu CEO and founder Boris Goranov looked at one central question: which wallet architectures will pass certification under eIDAS 2.0, and what does that mean for the choices organisations make today?
The market is converging on remote HSM-based wallets
Italy, France, Greece and Denmark already have live wallets, largely because they could build on mature national identity frameworks and high citizen adoption of qualified signatures. Larger member states such as the Netherlands are still building, since their existing solutions do not yet meet the eIDAS 2.0 level. Given the tight timeline, most governments are starting with one narrowly scoped wallet that covers identity and qualified electronic signatures, while certification of private sector wallets follows at a later stage.
On the question of where the keys live, the debate has largely settled. Smart cards are difficult to scale and are easily lost, and SIM cards or the secure storage in Apple and Google devices are currently not certified at the required level. As a result, the frameworks and implementations Dick sees point towards a remote HSM, which is device-independent and allows citizens to recover their keys without visiting a municipality for a new card.
The private sector is also moving. Dutch examples such as KPN’s healthcare wallet, ING’s wallet plans and a Rotterdam use case for social housing applications show that banks, telcos and public organisations are preparing to issue or accept wallet credentials. For QTSPs, the most relevant shift is that citizens will receive qualified signatures in their wallet free of charge, which Dick expects to move many processes that now rely on advanced signatures up to qualified signatures.
Slides from our webinar on QSCD, WSCA and WSCD under eIDAS 2.0
An existing QSCD does not automatically qualify as a WSCA/WSCD
A common assumption is that a certified remote QSCD with a signature activation module (SAM) already covers what a wallet needs. Boris Goranov explained why this is not the case. In today’s remote qualified signature setups, identification and signature activation are allowed at a substantial level of assurance, even though the signature itself is qualified. For the wallet, identification and activation have to meet the high level of assurance.
The consequence is that adding software in front of an existing SAM does not raise the solution to the required level. The wallet requirements extend the security scope to policy decisions such as key creation, user authentication, presentation and key lifecycle management, and all of these need to withstand an attacker with high attack potential, as defined in Common Criteria AVA_VAN.5. Boris therefore describes the WSCA as a rework of the security model rather than an implementation detail on top of a QSCD.
Five ways to implement a WSCA, and which one passes certification
Once it is clear that the WSCA needs its own high-assurance security model, the next question is where it should run. Boris outlined five options that organisations are currently exploring. (Previously discussed in this article.)
- A virtual machine in the cloud, which is common in sandboxes but cannot reach the required security level.
- A trusted execution environment from processor vendors with encrypted containers, which lacks side-channel protection in a shared environment.
- A dedicated general-purpose server in the organisation’s own data center, which removes the shared environment but still has to be maintained, updated and kept running at a level that does not meet the requirements.
- A dedicated, locked-down appliance, which would need its own Common Criteria certification and in practice means rebuilding what an HSM already is.
- The full WSCA running inside the HSM, together with the keys and all security-critical logic.
The fifth option is the one Boris considers the realistic path to certification. When the keys and the logic sit together inside the HSM, nothing outside can interfere with them, and the security evaluation can focus on the narrow interface the HSM exposes to the outside world. This also aligns with the regulation, which requires security-critical functions to be protected by the WSCD in hardware. Storing state outside the HSMs and running them as a load-balanced cluster keeps the solution scalable for national use.
Boris also described the two shortcuts he sees in the market: building software in front of an existing SAM, or running the WSCA outside the HSM and trying to lock it down. The risk of both is significant, since a successful attack on a government WSCA could lead to account takeover for an entire population.
What this means for QTSPs and signing platforms
For QTSPs, the good news is that existing qualified signature services keep running. The main addition is the ability to accept wallet-based activation, which turns the wallet into a high-assurance activation factor for remote qualified signatures. Since the wallet requires identification and activation at the high level of assurance, solving the wallet architecture also strengthens remote qualified signing, which today can still rely on substantial-level activation.
A second opportunity lies in qualified electronic attestations of attributes. QTSPs that want to issue attestations into wallets can build on their existing registration and certification authorities, which remain trusted. Signing platforms, in turn, can start experimenting now with accepting wallets as an activation method, so they are ready when wallets reach citizens at scale.
Ubiqu’s remote secure element is designed to support both sides of this picture. The same HSM cluster can serve as the cryptographic backend of a wallet ecosystem and as a remote QSCD whose signatures are activated by the wallet, using one technology stack for both.
Build or buy: weighing time, expertise and certification risk
Every organisation that needs a WSCA faces the same decision. Building one requires finding experts who can design it to the required level, maintaining it for the fifteen years or more that a wallet will need to run, and accepting the risk that a failed Common Criteria evaluation delays the project by a year or two. Boris noted that in current tenders, member states are less focused on what a solution costs than on how a vendor can guarantee that it will actually reach certification.
Ubiqu’s approach places the complete WSCA inside the HSM. Since no protection profile for the WSCA exists yet, Ubiqu defined a security target based on the threats and risks in the implementing act and had an evaluation lab perform a vulnerability assessment at the AVA_VAN.5 level. The remaining work is mapping the solution’s functions to the functional requirements of each national wallet certification scheme, while the remote QSCD follows its own certification track.
For QTSPs and signing platforms, the practical next step is to decide how wallet activation and attestation issuance fit into their roadmap, and to check whether the wallet infrastructure they plan to rely on follows an architecture that can pass certification. Organisations that want to discuss these choices can contact the Ubiqu team via ubiqu.com.
