One of the most consequential architectural decisions in the EU digital identity ecosystem has quietly been made for you. After years of debate about which WSCD implementation could realistically meet eIDAS 2.0’s Level of Assurance High while being accessible to the broadest possible user base, the remote cloud option has emerged as the winner.
Germany’s national EUDI wallet, for instance, has confirmed it will launch with a remote WSCD using a cloud HSM, explicitly acknowledging that most smartphones simply lack the local key storage and authentication capabilities required to reach LoA High at scale. Local secure elements remain the long-term ambition, but realistic timelines for widespread hardware availability push that ambition at least five years out.
So the architecture question is largely settled. The cryptographic heavy lifting happens in the cloud, through a Hardware Security Module as a Service. What that means in practice is that every organisation now building a wallet is building on top of a remote secure element, and the question shifts from “which WSCD architecture?” to something more fundamental: are you going to build that remote secure element yourself, or are you going to buy it from someone who already has?
What building a Remote Secure Element actually involves
Ubiqu spent years developing its Remote Secure Element, and that timeline reflects the genuine complexity of building a cryptographic trust anchor that can withstand certification scrutiny at the highest assurance level. The WSCA must be evaluated against assurance level high, the WSCD must meet tamper-proof and duplication-proof requirements, and every architectural assumption must be made explicit in the security target and justified to the certification body.
The people who can do this work are not abundant. Cryptographers who understand the ETSI standards and the Common Criteria evaluation methodology deeply enough to build certifiable infrastructure are a rare and expensive resource, and they are currently in demand across every EU member state simultaneously. You can of course train people, but that takes time too. Realistically, it takes at least six months before a newly onboarded engineer is anywhere near productive.
The same scarcity applies to the certification bodies themselves. Audit capacity in this domain is limited, and the pipeline is filling up fast as the 2027 deadline approaches with every EU member state scrambling to certify their wallet solution simultaneously. One Dutch company spent five years pursuing certification for a digital identity product, and by the time they got there the underlying technology was already outdated. They pulled the plug, and five years of investment was gone. That is not an edge case but a realistic illustration of what happens when organisations underestimate how hard it is to get a security-critical product certified, especially when the standards are still being refined in real time.
The maintenance trap that nobody puts in the business case
There is a well-documented pattern in complex IT projects where the cost and risk profile looks manageable in the project phase and then changes shape entirely in the operational phase. The consultants and specialists brought in to design and build a certifiable WSCA/WSCD will move on when the build phase ends, leaving behind a complex, security-critical system that needs ongoing expert maintenance by people who were not there when the critical design decisions were made. In security-critical infrastructure this is not merely inconvenient but a genuine liability, because the system cannot stand still while the team figures out how it works.
This dynamic becomes more acute in a domain where complexity compounds exponentially rather than linearly, and where the regulatory framework itself is deliberately evolving. The EU has explicitly embraced what might be called agile legislation, updating implementation acts on short cycles based on real-world pilot feedback, which means that a wallet built today will need to keep pace with a moving target indefinitely. An organisation that builds its own wallet infrastructure and then needs to extend it, recertify it, or adapt it to a new implementing act is not doing the same project again but a more complex version of a project that was already difficult the first time, with a team that has probably already dispersed.
Where the real value of the wallet lives
The choice between building and buying a wallet is often framed as a question about control, but control over what, exactly, is worth examining carefully.
The wallet itself, the pipe through which identity data flows, is not where the differentiated value lives. What matters is what credentials are in the wallet, which use cases it enables, and how well the organisation designs the processes around it. Rotterdam understood this when it built its ID010 initiative around a single concrete use case, using a digital income statement to streamline access to social housing. The insight was not technical. It was about picking the right problem and designing a process that worked for real people in a real situation.
An organisation that spends three years building a certifiable Remote Secure Element is an organisation that is not spending those three years on the use cases that will actually drive adoption. The EU’s 2027 deadline is not generous. The certification pipeline is already congested. The talent pool is constrained. And the regulatory framework will continue to evolve, meaning that whatever is built today will need to evolve with it.
For most organisations entering this space, the strategic question is not whether they have the capability to build a Remote Secure Element. It is whether building one is the best use of the time and expertise they have, given what is already available in the market and given how much there is still to do on the use case layer where adoption will actually be won or lost.
