- Insights
3 things slipping under QTSPs’ radar before the 2027 eIDAS deadlines
QTSPs know what’s coming in 2027. The problem isn’t awareness. It’s operational readiness.
Across the market, technical literacy around EUDI Wallets, notified eIDs, and the updated Article 24 regime is already high. Most teams understand the direction of travel.
What many still underestimate is the amount of operational work required to get there on time.
The timelines are tighter than they look. For QTSPs not already close to ETSI TS119-461 LoIP Extended alignment, recertification can take more than 20 months. Even teams that are already relatively mature should still expect six to nine months of work.
That means the window for starting is upon us.
Three issues in particular remain underestimated by many teams:
1. Document-based identity proofing is being squeezed from two sides
Much QTSP identity proofing today still relies on document verification combined with biometrics.
That model now faces pressure from two directions simultaneously.
The first is regulatory.
The updated Article 24(1a) requirements require audited conformity under ETSI TS119-461. Many existing document-based identity proofing methods do not meet the updated version of the standard today, and recertification timelines are substantial.
The second pressure is technical.
Generative AI has dramatically reduced the cost of producing convincing fake documents and injecting them into onboarding flows. So at the same moment that conformity requirements are becoming stricter, document-based verification is becoming easier to attack.
Document-based methods are not disappearing under eIDAS 2.0. They remain a legitimate Article 24(1a) path, and in many markets they will remain an important fallback while wallet and LoA High eID coverage matures.
But there is a common assumption in the market that document-based fallback methods can simply be modernized later.
That assumption is risky.
Fallback methods still require the same conformity work as primary methods. A fallback stack that is not already aligned with ETSI TS119-461 is still exposed to the same deadline pressure.
2. Cross-border wallet and notified eID acceptance is not just a tech project. It’s an ongoing operational function.
Every Member State will issue its own EUDI Wallet and most will continue to maintain notified eID schemes that feed into those wallets and operate alongside them. For a QTSP, accepting identification across the EU means integrating with both multiple wallets and multiple notified eIDs, each with its own implementation.
The wallets share a common architecture under the ARF, but national implementations still introduce differences:
-trusted issuers,
-registration requirements,
and feeder eID schemes.
For QTSPs, this is not a simple one-to-one integration exercise.
As for eIDs, supporting a single provider already involves:
-provider registration,
-integration work,
-testing,
-monitoring,
-incident handling,
and ongoing adaptation as national implementations evolve.
In some cases, registration may also require a local legal presence.
Multiply that operational workload across every wallet and notified eID a cross-border QTSP may need to support, and the challenge is less a technical project than a permanent interoperability operation.
This matters because the value of the qualified framework is fundamentally cross-border.
QTSPs focusing only on domestic wallet acceptance are missing the core reason qualified trust services exist in the first place: portability across Member States.
A QTSP that only accepts the French wallet is offering portability that effectively stops at the border — and users from Belgium, Italy, or Poland will notice that quickly.
3. Many QTSPs are making the build-versus-partner decision by default
Over the next eighteen months, every QTSP will make a decision about wallet and eID acceptance infrastructure.
Some will build internally.
Others will rely on intermediaries or infrastructure partners.
The problem is that many organizations are not making that decision strategically.
Instead, they begin with a small internal integration project, discover the operational complexity halfway through, and then either:
-continue because too much effort has already been invested,
-or look for a partner later under deadline pressure.
Both paths are expensive.
The more useful question is where the QTSP’s actual differentiation lives.
The qualified service itself: certificate issuance, signature creation, supervisory relationships, audit posture, is where most QTSPs create long-term value.
Wallet and eID acceptance infrastructure is different.
Every provider ultimately integrates into the same national wallet and eID ecosystem. The work is operationally heavy, continuously maintained, and largely undifferentiated across the market.
Most QTSPs can build it.
The more important question is whether building and maintaining that infrastructure internally is the best use of the next 12–18 months of engineering, product, compliance, and operational capacity.
For many organizations, that answer becomes less attractive the more the operational workload is understood.
What QTSPs should consider this quarter
Here’s a non-solicited but useful suggestion for your team: one cross-functional meeting.
Product, compliance, and engineering in the same room.
And clear answers to three questions:
Where does our document-based fallback sit on the ETSI TS119-461 recertification curve?
What is our cross-Member-State wallet and eID acceptance plan, and who owns the ongoing operational workload?
Are we building or partnering for wallet and eID acceptance, and is that decision based on strategic differentiation, or simply on the direction we drifted into first?
If the answers are still vague, the problem is probably not technical.
It’s operational.
And operational gaps are much harder to close in the final six months before a regulatory deadline.
QTSPs that move early are also moving toward identity methods designed for digital use cases which bring:
-faster onboarding,
-better conversion,
-lower fraud exposure,
and significantly better user experience than document-based identity proofing.
The deadline is a forcing function and the competitive advantage is what comes after it.
Learn about Hopae Connect, the infrastructure QTSPs use to accept EUDI Wallet credentials and notified eIDs across Member States through a single integration.
