The Quantum-Safe Internet Started in 2025. Europe’s Financial Infrastructure Hasn’t Caught Up.

This is Part 2 of a three-part analysis. Part 1 covered the IETF standards that landed in 2025, the full eIDAS dependency chain, and the real revocation bottleneck. This part covers what QTSPs can actually issue today, what Wero’s architecture makes concrete, and the state of DSS library. Part 3 dives into what a realistic migration scenario looks like against the EU’s 2030 mandate.

What QTSPs Can Issue Right Now

The QTSP situation shows the gap between private and public certificate capability that defines the current state of PQC deployment.

Several major CAs can issue private ML-DSA certificates for internal PKI today. Public CA certificates with ML-DSA algorithms , as required for a QWAC or QSealC under eIDAS, are not available from any major European QTSP, for a structural reason: issuing eIDAS-qualified certificates requires audited operations under EN 319 411–2, with HSM infrastructure meeting FIPS 140–3 or equivalent certification. PQC-capable HSM firmware is at the very beginning of achieving those certifications. The Samsung/Thales S3SSE2A announced at CES 2026 is a meaningful hardware step , but the path to certified hardware under updated protection profiles is long, at least 12 months away.

AI interpretation of the conundrum

Closing the gap from private ML-DSA capability to public eIDAS-qualified ML-DSA QWAC issuance requires: HSM firmware upgrades to PQC-capable versions, FIPS 140–3 or Common Criteria certification of the upgrades, updated Certificate Practice Statements, and full re-audit under EN 319 411–2 once ETSI updates it. All these steps are essentials and none can be skipped.

Wero: A Practical Dependency Chain Study

Abstract dependency chains are easier to ignore than concrete platforms. Wero makes the stakes tangible, though understanding why requires getting the architecture right.

Wero is a digital wallet and account-to-account payment scheme operated by EPI Company on top of SEPA Instant Credit Transfer (SCT Inst) rails. Public EPI and Wero material describes Wero as being integrated into participating banks’ mobile applications, with EPI Central Services acting as the scheme level coordination engine. Thus the core issuer-side model looks like a “wallet and scheme integration into banks’ internal channels and payment systems.”

That does not mean open banking interfaces are necessarily absent from Wero. On the merchant and acceptor side, at least some publicly documented implementations use an Open Banking API subset between the scheme facing layer and the Acceptor PSP environment. Worldline’s Wero acquiring documentation is explicit on this point. This isbetter understood as a documented acceptor integration pattern, not as proof that the entire Wero architecture, or the bank side in particular, is always mediated through PSD2 Open Banking API.

From PQC analysis perspective it changes where the dependency chain sits. The primary Wero dependency for banks is not necessarily a PSD2 certificate chain but the direct technical and cryptographic dependency between member banks, their internal payment infrastructure, and the EPI Central Services. The issue becomes therefore scheme wide transport security, endpoint crypto agility, key management, and the ability of EPI governance to propagate technical requirements across the network. PSD2 certificate dependencies may still appear in some acceptor-side models, but they are not concerning the whole platform.

As such the immediate PQC concern sits at the transport and orchestration layers. EPI Central Services is a concentration point for transaction coordination across member banks and merchant use cases. Public rollout shows Wero already operating at large scale, more than 50 million users reachable by March 2026, with e-commerce already in progress and point-of-sale planned for 2026. The scheme’s internal transport and message flows becomes a high value target for cryptographic risk, thus HNDL.

Hybrid TLS 1.3 with ML-KEM is relevant here because it can be deployed at transport level without waiting for rework of identity certificates or trust-service regulation.

In other words, Wero’s direct bank-to-scheme integration model actually makes the first PQC step conceptually cleaner: the initial migration problem is not about PQC certificates or PSD2 QWAC dependency and more about whether EPI and its participants choose to introduce crypto-agile requirements at transport level into the scheme rulebook and technical specifications. Current internet deployment practice already shows this path is technically available in a simple and effective manner.

There is, however, a second dependency chain alongside the payment rail: identity. The EUDI wallet framework is making strides towards real financial services use, and payments are among key wallet use cases. EU member states are required to make EUDI wallet available by 2026, and regulated service providers are obliged to accept the wallet for authentication. In the real world, legal and industry analysis now points to financial institutions and payment service providers needing to be ready for wallet acceptance by December 2027.

The EUDI wallet model is fundamentally an identity-and-authentication model built around wallet control and high-assurance user authentication, typically expressed in two factor terms. PSD2 SCA, by contrast, is not satisfied by two factors alone: for payment initiation it also requires dynamic linking, meaning the authentication must be cryptographically bound to the specific amount and payee. Therefor a convergence problem: the wallet can potentially satisfy PSD2 SCA, but only if the payment-specific binding, liability model, lifecycle controls, and operational responsibilities are implemented in a way that goes further than generic wallet login. This is another dimension of the regulatory pression.

Wero is likely to sit at an intersection. On one side, it is replacing or absorbing national payment-scheme functionality through direct bank and scheme integration. On the other side, the EU identity stack is becoming an accepted authentication layer for regulated financial interactions. So the architecture question is not only if Wero hardens its transport links with PQC, but whether it does so while also designing for an incoming wallet-based identity layer whose regulatory model is not perfectly aligned with legacy PSD2 SCA assumptions. And it is also not PQC safe.

If we look at it this way, Wero’s dependency chain is broader than a PSD2 API certificate problem. It is a scheme-governed network dependency problem with an emerging identity overlay on top.

The most important immediate PQC lever, and low hanging fruit, is the direct bank-to-scheme transport and interface layer. The most important medium term architectural risk is that Europe may succeed in introducing EUDI wallet acceptance into payments before it has fully resolved how EUDI authentication semantics, PSD2/PSR SCA requirements, and scheme-level payment flows fit together from operational perspective.

The DSS Signal

Last week, two issues, DSS-3832 and DSS-3833, appeared in the EU Digital Signature Service tracker, the open-source reference library maintained by the European Commission’s DIGIT team that underpins QWAC and QSealC validation across the eIDAS ecosystem.

Both issues request PQC support: one for CMS signatures referencing RFC 9881, 9882, 9814 and 9909 by name, and one for JAdES signatures, and both are lowest priority.

DSS is not just some library but the reference implementation that systems across the eIDAS ecosystem builds on for qualified certificate validation. If DSS adds ML-DSA support, every system built on DSS inherits that capability with a library update, bank API gateways, hub platforms, QTSP validation services, national eID systems — assuming of course that they did not build custom code for this purpose, which would be a very very bad idea in itself, for too many reasons to count.

Now lowest priority for the PQC issues in DSS backlog means propbably exactly what it says. The issues exist as placeholders, there is no active development branch, no sprint assignment, no target release. The DSS team is just noting that implementation will eventually be needed and that IETF dependencies are resolved.

The DSS issues are a trace indicator: the ecosystem has begun to register that the IETF standards layer is done. The implementation response is, as of the moment of writing, a note to self at the bottom of a backlog.

The author tracks post-quantum cryptography migration in European financial infrastructure and digital identity. Corrections and technical additions are welcome.