Remote WSCA is the consensus, but most implementations might not meet the legal requirements of eIDAS 2.0
The European Digital Identity Wallet, the EUDI Wallet, will give every EU citizen a single digital identity they can use to access government services, open bank accounts, and authenticate across borders. At the heart of that wallet is a cryptographic infrastructure that needs to be built, and the industry has spent years debating how to do it.
The central question was where to store and manage the cryptographic keys that make the wallet trustworthy: on a smartcard, on the device itself via an embedded secure element or eSIM, or remotely via a Hardware Security Module (HSM) in the cloud. That debate is now settled – consensus has formed around the remote HSM approach, and I believe that is the right outcome. I wrote about those four options in detail earlier.
This agreement on the remote WSCD still leaves a more important question unanswered: where exactly does the Wallet Secure Cryptographic Application (WSCA) run within that remote architecture, and will that architecture hold up under eIDAS 2.0?
Right now, the industry is converging on implementation approaches that I believe will not only leave digital identity wallets exposed to serious security risks, but will also fail to meet the legal requirements of eIDAS 2.0. In my view, several of the approaches currently gaining traction will not survive a formal security evaluation under eIDAS 2.0.
Before we go further: what is a WSCD and what is a WSCA?
A Wallet Secure Cryptographic Device (WSCD) is the hardware environment where cryptographic keys are generated and stored. Think of it as the vault. It exists to ensure that private keys never leave a physically protected boundary, and that any computation involving those keys happens inside that boundary. A Hardware Security Module, or HSM, is the most widely used form of WSCD in the remote context.
A Wallet Secure Cryptographic Application (WSCA) is the software that runs inside or alongside that vault. It is the application logic that governs how keys are created, used, and managed. The WSCA is what actually performs the cryptographic operations that make a digital identity wallet work.
The distinction matters because you can have a perfectly good WSCD and still make a poor decision about where your WSCA runs. That decision is the one this article is about.
What makes a WSCA compliant under eIDAS 2.0
Before diving into the five implementation approaches, it helps to understand what the regulation actually requires of a compliant WSCA, since that is the standard every architecture will eventually be measured against.
The certification of a wallet solution under Commission Implementing Regulation (EU) 2024/2981 covers several components: the wallet instance, the end user device, the WSCD, the WSCA, and the services and processes used to operate the solution. Each component has its own evaluation requirements. This article focuses on the WSCA, because the architectural choices made for the WSCA are the ones most likely to determine whether a wallet solution can be certified at all, and they are the choices that are currently being made without a full understanding of what the evaluation will require.
In Annex IV, Commission Implementing Regulation (EU) 2024/2981 sets out the evaluation requirements for the WSCA. Common Criteria defines two relevant scales: an Evaluation Assurance Level (EAL) running from 1 to 7, and a vulnerability assessment level (AVA_VAN) running from 1 to 5. A WSCA must be evaluated at EAL 4+ and must include a vulnerability assessment at AVA_VAN.5, the level used to test resistance against attackers with high attack potential. These are not interchangeable: experience with EAL 2 or EAL 3 certification, common in enterprise IT security, bears little resemblance to what an EAL 4+ AVA_VAN.5 evaluation demands.
At AVA_VAN.5, evaluators actively attempt to exploit the system. For each potential vulnerability, they assess how difficult it is to discover, what expertise is required, what access is needed, and what equipment an attack demands. If they can demonstrate that an attack is possible, the evaluation fails.
What this means in practice is that a compliant WSCA is not one that has been designed with security in mind. It is one that has been tested by an accredited laboratory and found to hold up. The architectural choices described in the following sections determine whether that test is even passable, before a single evaluator looks at the system.
“There is no standalone compliance certificate for the WSCA in isolation. Compliance for the WSCA means passing a mandatory vulnerability assessment at AVA_VAN.5 as part of the certification of the overall wallet solution.”
– Boris Goranov, CEO van Ubiqu
The remote WSCA implementation decision: five approaches compared
There are at least five distinct approaches being pursued across the industry today, each placing the WSCA at a different distance from the HSM security boundary. At one end, you have the WSCA running inside the HSM itself, with no exposed interface between the application logic and the cryptographic keys. At the other end, you have the WSCA running in a plain virtual machine in the cloud, with the HSM accessed remotely over a network interface.
In between, there are implementations that run the WSCA on a dedicated appliance placed in front of the HSM, on a general-purpose server outside the HSM, or inside a virtual machine equipped with a Trusted Execution Environment. Each step away from the HSM boundary introduces new attack surfaces and removes security guarantees that the step before it still had.
Option 1: WSCA in a virtual machine
The WSCA runs inside a standard virtual machine on shared cloud infrastructure – the same kind of environment used to host websites or business applications. It is the easiest and fastest option to deploy. The security exposure is significant. The WSCA runs on shared physical hardware with no hardware security boundary, making it vulnerable to side-channel attacks such as Rowhammer, where an attacker on the same physical machine can extract cryptographic secrets by exploiting physical properties of the hardware rather than breaking any software layer.
Running a WSCA in a virtual machine means there is no hardware boundary to verify the integrity of what happens during a cryptographic operation. A digital identity wallet performs cryptographic operations on behalf of citizens: generating keys, creating signatures and authenticating identity. Any interference with those operations, whether by an external attacker or a malicious administrator, has to be detectable. In an environment that cannot guarantee its own integrity, logging is the only way to reconstruct what happened during an operation and verify that nothing was tampered with.
The less the execution environment can be trusted, the more granular that logging has to be: every individual step of every cryptographic operation has to be recorded, rather than just the start and end result. Each log entry must itself be signed by the HSM to ensure the log cannot be altered after the fact, which means the HSM is doing two jobs for every operation: executing the cryptographic function and signing the audit trail around it. This multiplies HSM transaction volume far beyond what a more trusted execution environment requires, and the problem compounds at the scale of national wallet infrastructure.
In summary, this option offers no side-channel resistance, no malicious administrator resistance, and no path to catastrophic breach resistance. It is not viable for any implementation that intends to meet eIDAS 2.0 requirements.
Option 2: WSCA in a virtual machine with Trusted Execution Environment (TEE)
The WSCA runs inside a virtual machine, but within an isolated memory area called a Trusted Execution Environment – a processor-level protection that is supposed to prevent other processes, including the operating system, from accessing what happens inside it. This is a genuine attempt to address the weaknesses of the plain VM approach, and it does allow for more efficient logging than option 1.
The critical limitation is that TEE does not provide side-channel resistance. AMD and Intel have publicly stated that their TEE implementations do not protect against side-channel attacks. Rowhammer and related attacks remain viable against TEE-protected environments, meaning the most relevant class of attacks for cryptographic key protection is not addressed. An attacker with the right level of access to the surrounding infrastructure can still compromise the system without ever breaking through the TEE directly.
“The further the WSCA runs from the HSM boundary, the harder it becomes to guarantee that the cryptographic operations protecting citizens’ identities cannot be compromised. This is not infrastructure where cutting corners on security makes sense.”
– Boris Goranov, CEO van Ubiqu
Option 3: WSCA on a general-purpose server
The WSCA runs on a dedicated physical server in a data centre, communicating with the HSM over a local network connection. Unlike the VM-based options, this removes shared-hardware risks and gives the organisation direct control over its infrastructure. The server can be physically secured, hardened, and monitored.
The WSCA still sits outside the HSM boundary, which means side-channel resistance is absent for the same fundamental reason as in the VM options: cryptographic operations are happening in hardware not designed to provide it. Logging overhead remains high, and malicious administrator resistance is not achievable – the server requires administrators to operate, and no procedural control is a cryptographic guarantee.
The wall built around the server also creates operational complexity. Adding capacity is not as simple as spinning up an additional server: every new server requires the same level of physical hardening and security controls as the original, which makes the infrastructure significantly harder to operate and maintain at scale.
Option 4: WSCA on a dedicated appliance in front of the HSM
The WSCA runs on a purpose-built hardware appliance positioned between the wallet application and the HSM. Unlike a general-purpose server, the appliance is specifically designed and hardened for this role, and some organisations have invested significantly in this approach. It reflects a genuine understanding that commodity infrastructure is not well suited to cryptographic operations.
To compensate for the WSCA sitting outside the HSM boundary, a wall has to be built around the appliance: controlling physical access, restricting administrator privileges, and hardening every surrounding layer. That wall creates the same scalability problem as option 3. Adding capacity is not a matter of deploying an additional appliance, because every new appliance requires the same level of hardening and security controls as the original.
Every remote WSCA implementation has to be internet-accessible for the wallet to reach it, which means the attack surface includes the wallet itself. Since device keys can be accessed outside of the wallet instance, a malicious actor can perform a direct attack on the WSCA simply by downloading a wallet on a device they control. Proponents argue that the wallet is certified and therefore safe. That may be true today, but if the wallet is ever exploited through a software vulnerability, a supply chain attack, or a zero-day, it becomes a direct entry point to the WSCA. From there, the WSCA itself can potentially be breached, and an attacker can impersonate any citizen whose key is managed by that instance, generating valid cryptographic signatures that are indistinguishable from legitimate ones.
The only way to genuinely prevent this is to run all security-sensitive operations inside the HSM security boundary, including authenticating the wallet instance itself within that boundary. That means the attack vector from the wallet never reaches the cryptographic core, regardless of what happens to the wallet application above it.
Option 5: WSCA inside the HSM security boundary – our solution at Ubiqu
The WSCA runs inside the HSM itself, within the hardware security boundary that the HSM was built and certified to protect. The application logic and the cryptographic keys it operates on exist in the same physically protected environment. Since the WSCA lives inside the WSCD, there is no connection between the two that can be targeted: no interface to intercept, no man-in-the-middle attack possible between the WSCA and the WSCD.
Side-channel resistance is an inherent property of this architecture, not something that needs to be designed around. Logging is efficient: since the execution environment is fully trusted, a simple start and stop entry is sufficient rather than granular per-step logging. Even a fully compromised administrator cannot reach cryptographic operations happening inside the HSM boundary. The result is the highest possible security assurance with the smallest possible attack surface.
This is the hardest option to build, and it took us years. HSMs were not designed to run full applications – they were built to store keys and perform discrete cryptographic operations. Developing application logic inside that environment requires working within severe tooling constraints. The early scalability challenge was specific: HSMs were never intended to store and manage keys at the volume that national wallet infrastructure requires, and solving that was a significant engineering effort. Organisations that want to build this themselves are not facing an impossible task, but they should plan for a minimum of four years before they have something production-ready. We have already done that work.
How to evaluate which remote WSCA architecture will hold up as the compliant standard under eIDAS 2.0
Earlier in this article I outlined what Annex IV of Commission Implementing Regulation (EU) 2024/2981 requires of a compliant WSCA: a vulnerability assessment at AVA_VAN.5, conducted by an accredited laboratory, as part of the certification of the overall wallet solution. That requirement is what makes the architectural choice so consequential.
Passing an AVA_VAN.5 assessment requires demonstrating, in a structured way, that no exploitable vulnerability exists against a high-potential attacker. That is only achievable if the scope of what is being assessed is small and tightly controlled. The moment a WSCA runs outside the HSM boundary, every component capable of affecting it becomes part of what must be assessed: the server hardware, the operating system, the hypervisor, the network stack, the APIs between components, the key management interfaces, the administrator access controls, the logging infrastructure, the update and patch mechanisms, and any cloud or virtualisation layer the environment runs on. The scope expands well beyond what a lab can practically clear. Moving from a lower attack potential to a higher one does not make the assessment a few times harder. The difficulty increases exponentially.
To my knowledge, Ubiqu’s is the only remote WSCA implementation that has already completed a vulnerability assessment at AVA_VAN.5, conducted by an accredited Common Criteria laboratory. The architectural weaknesses of the other four options, the absence of side-channel resistance, the reliance on physical access controls, the inbound attack vector from the wallet interface, are exactly the properties that expand the assessment scope beyond what a lab can practically clear.
Why a Signature Activation Module (SAM) is not a WSCA
Several vendors selling components for qualified electronic signatures offer a Signature Activation Module, or SAM, and present it as a sufficient basis for a WSCA. A SAM activates a signing key stored inside the HSM using two-factor authentication.
A WSCA is not the same thing. A WSCA has to cover the full set of security-critical operations a wallet performs, not just the activation of one key for one signing action. A vendor selling a SAM and telling the customer to build the rest themselves is, in effect, handing over an architecture identical to running a WSCA on a server or appliance outside the HSM. The SAM covers one operation inside the HSM. Everything else, all of the application logic that actually makes the wallet function, still has to run outside it.
This produces a specific and dangerous assumption: that because the signing key is activated inside the HSM, the wallet’s cryptographic operations are sufficiently protected. They are not. The signing key being safe does not make the surrounding application logic safe, and that logic is exactly where the architectural weaknesses described above (no side-channel resistance, no malicious administrator resistance, an attack surface reachable from the wallet app itself) still apply in full.
Why I believe many of these implementations will not be compliant
Remote WSCA is the right direction, but which remote WSCA architecture will actually hold up under eIDAS 2.0 is still an open question. The approaches currently gaining traction are being chosen because they are faster to build and easier to deploy. Speed and familiarity are not the criteria an accredited laboratory applies when evaluating your system, and organisations that have committed to an architecture that cannot pass that evaluation will face a significant rearchitecting effort before they can legally deploy at scale.
There is a tendency to treat security architecture choices as a budget decision before the value has been properly articulated. Without that articulation, any solution looks too expensive by comparison. Building a WSCA yourself carries its own hidden cost: it takes years, requires cryptographic expertise that is both scarce and expensive, and demands sustained team capacity that most organisations have not accounted for in their initial estimates. Buying an architecture that has not been tested against the relevant security requirements carries a different kind of hidden cost, one that only becomes visible when a formal vulnerability assessment shows the architecture needs to be rearchitected before it can be legally deployed at scale.
There is a perception that a compliant architecture costs more. That perception does not hold up. Ubiqu’s solution is not more expensive than the non-compliant architectures currently being offered in the market. What does cost significantly more is building a WSCA yourself: it takes years, requires cryptographic expertise that is both scarce and expensive, and demands sustained team capacity that most organisations have not accounted for in their initial estimates. At that point, the affordable option has become the expensive one.
I have been working on this problem for years and I am genuinely interested in where the industry lands. If you are evaluating WSCA architectures, working on eIDAS 2.0 compliance, or trying to understand what the requirements mean in practice, I am happy to talk.
How Ubiqu can help
If you are evaluating WSCA architectures, working on eIDAS 2.0 compliance, or trying to understand what the certification requirements mean for your implementation, I am happy to discuss it directly. I have spent years building and certifying a WSCA from the ground up, and I know where the gaps between current implementations and formal evaluation requirements tend to appear.
