EUDI Wallet Certification:
How Member States Can Kickstart the Rollout

The Certification Scheme as a Critical Path

Under eIDAS 2.0, wallets must be certified by conformity assessment bodies designated by Member States, with CIR (EU) 2024/2981 setting the ground rules. Until a European cybersecurity certification scheme for wallets is available, national schemes carry the load.

By 24 December 2026, every Member State must make at least one EU Digital Identity Wallet available to citizens and residents, whie EUDIW certificates must hold through every release, and regulated wallet-relying parties must accept wallets from late 2027. As the first deadline date closes in, many Member States are finding that the hardest open question is not the app but how the wallet will be certified, by whom, and against which certification scheme.

Certification is often planned as the last gate before go-live. However, in the special case where the product itself is not something fixed and settled, the certification scheme is the first set of decisions that fixes or at least draws rough lines for everything downstream: what gets built, what gets procured, who is accountable and how quickly the wallet can change. Programmes that settle those rules early move faster, because every later decision has something to anchor to.

Common Obstacles in Wallet Programmes

Most delays we are noticing are not technical failures but rather, decisions that nobody owned early enough, surfacing late as rework. The following list summarises the most frequent pain points across Member States:

• Waiting for a stable baseline. The ARF, technical specifications and EU-level guidance keep evolving. Teams that wait for a final version lose months, while teams that write against a snapshot without change control end up with requirements that ages quickly.
• No clear ownership. Some draft schemes never name a scheme owner. Others place system ownership, scheme ownership and supervision in one body, which blurs accountability and weakens the independence certification depends on.
• Certification treated as a process audit at the end. When the wallet is procured and built before the evaluation perimeter is fixed, evaluators may draw the boundary differently from the developers. The result may call for redesign, re-tendering or both.
• The hybrid app problem. Many governments want the wallet inside an existing e-government app. Without provisions about actively verifying non-interference/separation between certified wallet functions and everything else, the entire app can fall into the costly evaluation scope.
• Unclear composition rules for critical cryptographic components. Wallets rely on secure elements, HSMs and secure cryptographic applications that are usually certified outside the wallet scheme. If the scheme does not define how those certificates and their evaluation evidence are reused, it misses the regulatory objective: proven resistance to attackers with high attack potential. A harder case is a component with no certificate yet, whose vendor has nevertheless commissioned a vulnerability analysis at the deepest level (AVA_VAN.5) outside formal certification. The scheme should allow that evidence to be reused, and define the delta steps that close the loop to certification against high attack potential. Typical steps are matching the evaluated scope to the wallet's target of evaluation, confirming the lab's competence, checking that the evidence is current and adding platform-specific testing.
• Unrealistic accreditation requirements. In most Member States, few bodies combine accreditation with real wallet competence, and accreditation takes months. A scheme that does balance flexibility in accreditation/authorization with adequate assruance for certification bodies is not a directly operable scheme.
• Mirroring another Member State. Late adopters may reuse a wallet of another Memver State and treat the rollout as one more ICT implementation project. But a wallet is a sociotechnical system with compelx product and service certification needs, and the reused code alone does not bring a certificate with it. The Wallet provider, PID issuer, eID means issuer, onboarding, hosting and supervision all change, and each must be assessed in the national context. Reuse becomes pragmatic only with a national ecosystem around it: a scheme owner, accredited assessment bodies, a supervisory body and relying parties aware, willing and ready to connect.

Insights From Other Member States

SpearIT is engaged by ENISA to assist Member States in their efforst of developing national EUDIW certification schemes. In this context, we have been reviewing all EUDIW certification schemes published by the various MS and providing structured expert feedback. The following list provides key insights to scheme developers, elicited though the reviews so far:

• The certification scheme is a fundumental document. It defines what is evaluated, how deeply and by whom. Those choices shape the architecture far more than any feature list, so the scheme should be in-place at the earliest possible throughout the whole national EUDIW programmee.
• Pursue the right balance between prescribing architecture and being technology-agnostic and outcome-based. Requirements should state security outcomes rather than mandate technologies, keeping schemes open to different platforms and future designs. But outcomes cannot be assessed in a vacuum: evaluators need a defined target of evaluation, named components, trust boundaries and the interfaces between them. Composite evaluation of secure components, comparable results between assessment bodies and cross-border interoperability all rest on that shared model. The Architecture and Reference Framework helps but is not legally binding, so the scheme must state which parts are normative for evaluation. In practice, prescribe a reference model and a closed set of permitted deployment patterns, each with its own evaluation route, and leave implementation to vendors.
• Bind every requirement to an evaluation method and a depth. A requirement without a stated evaluation method and minimum rigour becomes a negotiation between vendor and assessor. Two bodies will then certify the same wallet differently.
• Account for CSA convergence. National cybersecurity certification schemes are a bridge to a future European scheme under the EU Cybersecurity Act. Structuring requirements so they map cleanly onto that scheme reduces re-certification cost later.
• Clear impartiality measures. It has been frequently observed that multiple different roles within a certification scheme or wallet ecosystem are held by the same public authority. Although this is a valid, deliberate choice of a Member State, clear impartiality measures across organizational units shall be applied and described.

How the Scheme Shapes Architecture & Procurement

Wallet architecture, certification, and procurement are not three independent workstreams but rather, expressions of the same decisions. Procuring against the scheme is a wise decision, even if the final scheme is settled after the tender, since the vendor's design quietly writes the certification rules and the state inherits whatever was built. Where a wallet procurement tender must go out first, incorporating the draft scheme's core decisions into it as interim requirements, with a clause obliging alignment to later versions, is a sound appraoch.

• The evaluation perimeter is an architectural decision. Where the boundary of the target of evaluation is drawn decides which code, components and hosting must withstand high attack potential, and so drives cost and timeline.
• Certifiability should be treated as a tender requirement and not as a vendor's promise. Name the acceptable deployment patterns and secure-component routes, and require evaluator access to source code, design documentation and composition evidence. Without that, the "certification-ready" claim cannot be confirmed.
• Account for chanage management. Releases, platform updates and specification changes can all trigger re-evaluation. Contracts should define maintenance obligations, re-evaluation triggers and who pays, because certification costs recur long after go-live.

Quick Wins Accelerating a National EUDIW Programme

To avoid stalling the EUDIW programme, a minimal but credible core that can start certifying on time and harden as capacity and regulatory machinery mature is key. Following is a series of actions considered quick wins for accelerating a national EUDIW programme and avoid stalling early:

1. Designate the Scheme Ownert early. Righ after, draft the scheme governance map the earliest possible, ideally aligned with the ARF ecosystem diagram. In that way, a single page demonstrates who owns the rules, who assesses, who supervises and who decides on changes.
2. Engage national stakeholders early. Hold working sessions with the supervisory body, the national accreditation body, prospective certification bodies and the first relying parties. Communicate the mandate and timeline, hear their constraints and secure buy-in before the rules are written. Each of them has its own lead times, and an early conversation starts those clocks.
3. Define the evaluation perimeter early. Specify what certification covers: the wallet solution and its secure components, the PID provision service, the wallet validation service, and the eID scheme through which is being provided. Where the EUDIW functionality co-resides with other, governmental functionality, design the non-EUDIW features so they cannot interfere with the wallet's target of evaluation (TOE). During evaluation, it will actively be verified whether non-interference is achieved, so that nothing outside the boundary undermines the security properties or assurance of the TOE. This should be captured as an architecture profile that maps components, interfaces and trust boundaries, as CIR (EU) 2024/2981 foresees. Publishing it as a short scope statement, helps providers and candidate certification bodies share one view of what certification will cover.
4. Start the accreditation track, and subcontract capacity if needed. The political leadership plays a catalytic role in mobilizing the NAB, in cases where where interest or ownership is absent. Agree the accreditation approach with the NAB while the scheme is being drafted. Competence and accreditation are among the longest lead items. Where national capacity is thin, subcontract evaluation to accredited bodies and labs in other Member States, while the NAB keeps the decision and the accountability. Where the accreditation body itself lacks capacity in this field, smarter interim routes are accepted, such as accreditation by another Member State's accreditation body under Regulation (EC) 765/2008 and the EA MLA or smarter acceditation scope arrangements, as well as technical experts supporting the national body's audits, and pre-audits that shorten formal accreditation.
5. Perform a dry-run certification. Take the draft scheme through one trial certification with an experienced assessment body, with the NAB also observing throughout the whole process: application, evaluation, decision and a non-accredited certificate. This allows testing the evaluation/certification procedures as well as the EUDIW itself. Also, findings will likely cost day rather than months to fix. Covering the ITSEF/lab fees for this first trial lowers the barrier for providers to volunteer. It is advised to consolidate the lessons into the draft scheme, ideally before it gets disseminated to the European Digital Identity Cooperation Group for review.
6. Establish and maintain a scheme change management process. Identitfy and track the specification versions the scheme relies on, and track each update's impact on the scheme and on existing certificates. Define upfront which product changes need only notification, which trigger a delta evaluation and which require re-certification.
7. Run a rollout pilot in parallel. Select the 2-3 public WRPs and pilot the wallet integration with them. This complements certification rather than being part of it: nothing surfaces integration, onboarding and user-experience issues faster. It also exercises the presentation flows that functional conformance testing will later examine.

National Stakeholders: Who to Engage & When

It should be emphasized again that the EUDI Wallet is a complex sociotechnical system, not simply a wallet app. It becomes successful only when an ecosystem drives both supply and demand: issuers providing credentials, relying parties accepting them and citizens finding reasons to use them. A ministry that builds a wallet and then tells everyone else to use it ends up with a product that might not be certifiable and might barely get adopted. That is why every vital stakeholder must be engaged early and given a real role in shaping the programme, not merely consulted.

No single institution can deliver such a product to the society. Certification, supervision, accreditation, PID issuance, data protection and service delivery each sit with a different body, under its own mandate and at its own pace. The programme succeeds only when someone orchestrates them as one system: aligning mandates, sequencing who comes in when, and resolving overlaps before they become disputes.

That orchestration is the groundwork the whole ecosystem stands on. Before the rules are finalised, each stakeholder should know its role and legal basis, what it needs from the others and when its input is due. Formal agreements and named contact points turn goodwill into commitments. With that ground prepared, certification, procurement and adoption can run in parallel.

Ecosystem Building: From Certification To Adoption

Certification alone does not create value. Value emerges when issuers, relying parties and citizens have clear reasons to use the wallet, and that requires a national ecosystem built deliberately, alongside certification rather than after it.