Qualified trust service providers (QTSPs) are under no illusions about what 2027 will bring. Awareness of the eIDAS 2.0 deadlines is not the issue. The real danger lies in operational readiness, and it is here that many organisations are quietly falling behind.
According to Hopae, Technical literacy across the market is already high. Most teams have a firm grasp of EUDI Wallets, notified eIDs and the revamped Article 24 regime. What is routinely underestimated, however, is the sheer scale of operational work needed to be compliant on time.
Hopae recently detailed the 3 things slipping under QTSPs’ radar before the 2027 eIDAS deadlines.
For QTSPs not already close to ETSI TS119-461 LoIP Extended alignment, recertification can stretch beyond 20 months, while even mature teams should budget six to nine months of effort. In other words, the window to begin is now.
The first underestimated issue is that document-based identity proofing is being squeezed from two sides at once. Much of today’s QTSP identity proofing still leans on document verification paired with biometrics, but that model faces simultaneous regulatory and technical pressure. On the regulatory front, the updated Article 24(1a) requirements demand audited conformity under ETSI TS119-461, and many existing document-based methods fall short of the updated standard today.
On the technical front, generative AI has slashed the cost of producing convincing fake documents and injecting them into onboarding flows. Document-based methods are not vanishing under eIDAS 2.0 and will remain a legitimate fallback in many markets, but the widespread assumption that fallback stacks can simply be modernised later is a risky one. Fallback methods require the same conformity work as primary methods and face the same deadline pressure.
The second blind spot is cross-border wallet and notified eID acceptance, which is less a technology project than a permanent operational function. Every Member State will issue its own EUDI Wallet, and most will maintain notified eID schemes alongside them. Although wallets share a common architecture under the ARF, national implementations differ on trusted issuers, registration requirements and feeder eID schemes.
Supporting a single eID provider already involves registration, integration, testing, monitoring, incident handling and continual adaptation, and in some cases a local legal presence. Multiplied across every wallet and eID a cross-border QTSP must support, the workload becomes an ongoing interoperability operation. Crucially, the value of the qualified framework is fundamentally cross-border; a QTSP accepting only the French wallet offers portability that stops at the border, something users in Belgium, Italy or Poland will notice quickly.
The third issue is that many QTSPs are making the build-versus-partner decision by default rather than by design. Organisations often begin with a small internal integration project, discover the operational complexity midway, and then either press on because of sunk effort or scramble for a partner under deadline pressure.
Both routes are costly. The sharper question is where genuine differentiation lives. Certificate issuance, signature creation, supervisory relationships and audit posture are where most QTSPs create long-term value, whereas wallet and eID acceptance infrastructure is operationally heavy, continuously maintained and largely undifferentiated across the market.
The recommended step this quarter is a single cross-functional meeting bringing product, compliance and engineering together to answer three questions: where the document-based fallback sits on the ETSI TS119-461 recertification curve, who owns the cross-Member-State acceptance workload, and whether the build-or-partner choice reflects strategy or drift. QTSPs that move early gain faster onboarding, better conversion, lower fraud exposure and a superior user experience. The deadline is a forcing function; the competitive advantage is what comes after it.
Read the full Hopae post here.
Copyright © 2026 FinTech Global
