ubiqu

The first national EUDI Wallet tenders are out, which means the architecture decisions that wallet providers and signing services make in the coming months will largely determine who passes certification and who has to start over. Most of these decisions come down to the secure component underneath the wallet or the qualified signature, and the requirements for that component under eIDAS 2.0 are stricter than many teams expect when they first map out their architecture. On Tuesday November 10, I will be joined by Dick Dekkers for a webinar in which we explain what eIDAS 2.0 technically requires. We will cover: ✅ the difference between a QSCD and a WSCA ✅ five common ways of running a remote WSCA ✅ why only one of them can pass an AVA_VAN.5 evaluation ✅ what the build, buy and platform routes cost in time and control Sign up now via Ubiqu's website: https://lnkd.in/eNrQdVfb

The first national EUDI Wallet tenders are out, and for wallet providers this means the architecture behind your bid is being judged right now. Whether your wallet eventually reaches certification depends to a large extent on the secure component underneath it, the WSCA that binds the wallet to its user. Many teams only discover during evaluation that the way they run their remote WSCA cannot meet the required assurance level. Of the five common ways to run a remote WSCA, only one can pass an AVA_VAN.5 evaluation, which makes this one of the most important choices to get right before a bid is submitted. In this webinar, Boris Goranov and Dick Dekkers, independent digital identity and trust consultant, explain what eIDAS 2.0 requires from the WSCA, which architecture holds up under evaluation and which four questions you should put to any provider.

Every wallet provider preparing for the EUDI Wallet has to decide how to source the secure component behind the wallet, whether that means building it in-house, buying it from a provider or building on an existing platform. Each of these routes leads to very different outcomes in terms of time to market, certification effort and control over your own architecture, and switching routes halfway through a tender process is costly. Boris Goranov and Dick Dekkers compare the build, buy and platform routes side by side, explain what eIDAS 2.0 requires from a remote WSCA and close with one concrete next step for wallet providers.

For QTSPs, the question is no longer whether to expand into eIDAS 2.0 services but how quickly you can launch them without giving up control over your infrastructure. Building your own secure component, buying one or building on a platform each comes with different trade-offs in time, cost and control, and the right choice depends on the services you want to offer and how fast you want to bring them to market. Boris Goranov and Dick Dekkers compare these routes, share four questions to put to any provider and close with one concrete next step for QTSPs.

eIDAS 2.0 gives QTSPs the opportunity to expand into new qualified services, and the speed at which you can launch them depends largely on the remote QSCD behind your signatures and seals. Since the requirements for that secure component are strict, the architecture you choose now determines whether your new services reach certification smoothly or get stuck in a long evaluation track. It also helps to understand how the QSCD relates to the WSCA used in wallets, since both play a role in the same ecosystem but are evaluated against different requirements. In this webinar, Boris Goranov and Dick Dekkers, independent digital identity and trust consultant, explain what eIDAS 2.0 requires from the secure component behind every qualified signature and what that means for QTSPs planning their next service.

Hi, we are Ubiqu. Provider of compliant, remote WSCAs and QSCDs for the EUDI wallet and trust services. Our core product is the Remote Secure Element (RSE), a hardware-independent component that functions as a Wallet Secure Cryptographic Application and Qualified Signature Creation Device under eIDAS 2.0. Since the RSE runs remotely rather than depending on a specific device or secure hardware chip, it can be integrated into existing infrastructure without the constraints that come with hardware-bound solutions. Ubiqu completed the AVA_VAN.5 assessment through an accredited Common Criteria lab, which is the vulnerability resistance level required for QSCDs under the regulation. We build the component, not the trust service itself. That means we work with organizations becoming QTSPs, existing QTSPs upgrading for eIDAS 2.0, and wallet ecosystem players such as banks and credential issuers, supplying the certified cryptographic infrastructure their services are built on. This lets our partners focus on their product and their customers, while the compliance layer underneath is already in place.