A certification scheme with real consequences
On 2 April 2026, the European Union Agency for Cybersecurity (ENISA) published the draft EUDI Wallet Cybersecurity Certification Scheme v0.4.614 and opened a public consultation. Stakeholder feedback closes on 30 April 2026. ENISA held an explanatory webinar on 8 April 2026.
This is not an obscure administrative exercise. Under the amended eIDAS framework, member states must provide at least one certified EU Digital Identity Wallet to their citizens by the end of 2026. The scheme ENISA is finalising right now is the instrument through which that certification is actually granted. Which wallets meet it, and which do not, will directly shape what attestations a verifier can trust at launch.
If you are building or operating a verifier, this is a document to understand — even if you never have to certify anything yourself.
What ENISA is certifying
The draft scheme is a cybersecurity certification for the wallet software itself, not for the end user, not for the verifier, and not for the overall ecosystem. It assesses whether a given EUDI Wallet implementation meets a defined security bar against a published set of threats.
The scheme builds on Europe's existing EUCC (European Cybersecurity Certification scheme based on Common Criteria) foundation while adapting it for the specific risk model of a mobile wallet. Common Criteria is well understood in the smart-card and HSM worlds but is heavier than most consumer software is used to. A pure EUCC approach would have meant a certification process measured in years — far too slow for the December 2026 deadline. The draft scheme therefore takes a pragmatic middle path.
Three things the draft gets right
Threat-model transparency. The draft spells out what classes of attacker the scheme defends against, with explicit risk ratings. This is a welcome departure from earlier EU certification approaches that tended to hide their threat models behind internal committee deliberations.
Differentiated assurance levels. Not every wallet needs the same security bar. A wallet authorising cross-border travel or high-value banking credentials carries different risk from one used only for age verification. The draft permits differentiated assurance levels so that member states can calibrate.
Alignment with the wallet reference architecture. The scheme is written against the EUDI Wallet Architecture and Reference Framework (ARF) version currently under discussion, which means the controls being assessed map directly onto the technical components a wallet actually has.
Three things the draft leaves ambiguous
Remote attestation requirements. Several sections reference the need for the wallet to prove its own integrity to the verifier — for example via Android Key Attestation or iOS DeviceCheck — without fully defining what evidence is acceptable. This is partly unavoidable at the current stage, but it creates uncertainty for verifier-side implementers who need to decide what attestation signals to check.
The open-source compatibility question. The draft does not directly address how a fully open-source wallet, with reproducible builds, can be certified. Several community responses in the consultation are pushing for clearer language here. The recent disclosure around the EU age verification app has sharpened this debate: if open-source implementations are to be allowed at scale, the certification scheme has to accommodate them without requiring per-build certification ceremonies.
National scheme interaction. Each member state has its own national certification body. How ENISA's scheme interacts with national certifications — whether it supersedes them, runs alongside them, or requires mutual recognition — is referenced but not fully detailed.
What verifiers should do
The certification scheme governs wallet issuers, not verifiers. You do not need to get certified to build against it. But the scheme still shapes your verifier logic in two concrete ways.
Metadata you can trust. Once the scheme is in force, wallet attestations will include signed metadata identifying which certification a given wallet holds. Your verifier code can make trust decisions based on this metadata — for example, declining high-value flows from wallets certified only at the basic assurance level.
Threat scenarios you should plan for. The threat model in the draft is a good reading list for verifier defensive coding. Even if you are not responsible for the wallet side, knowing what attacks the wallet defends against tells you what attacks your verifier cannot assume the wallet has handled. See our technical deep dive on eIDAS verification for how these layers interact.
How to read the consultation
If you want to engage with the consultation itself, ENISA publishes response mechanisms on their certification page. Useful responses typically come from:
- Verifier operators with practical experience of what attestation metadata is useful to consume.
- Open-source implementers who can speak to reproducible-build concerns.
- Member-state authorities with views on national scheme alignment.
A light read of the draft takes a few hours. A detailed response takes days. If you do not plan to respond, you can still benefit by reading the threat model and the differentiated-assurance section carefully.
The funding context
Worth noting: ENISA's certification work is backed by a €1.6 million contribution agreement signed with the European Commission in February 2026, running for two years. The agreement sits under the Digital Europe Work Programme 2025–2027. This funds both the central scheme development and national capacity-building to support member-state certification bodies.
The contribution agreement matters because it signals the Commission's expectation that certification is a live, ongoing activity — not a one-time ceremony before the December 2026 deadline. Wallets will be recertified, new versions will be assessed, and verifier-side metadata checks will stay relevant long after launch.
The timeline from here
- 30 April 2026 — Consultation closes.
- Q2 2026 — ENISA consolidates feedback, publishes next draft.
- Q3 2026 — Expected formal adoption of the scheme.
- Q4 2026 — First wallet certifications begin; national certifications align.
- End of December 2026 — Member states must have at least one certified wallet live.
This is aggressive. Realistically, the first wave of certifications will cover the Tier 1 sandbox wallets from France, Germany, and likely Denmark and Ireland. See our April 2026 member state rollout tracker for the current state of each national project.
How this connects to verifier strategy
If you are planning the verifier side of your integration, three practical implications.
Treat certification metadata as a first-class input. Do not hardcode trust in specific wallet issuers. Your verifier should consult the signed certification metadata on every presentation and branch its logic accordingly. Our OpenEUDI SDK exposes this metadata through a standard interface precisely because it will be load-bearing.
Plan for recertification churn. A wallet certified today may be uncertified tomorrow if a breach changes its status. Your verifier should handle certification-revoked wallets gracefully, not crash or reject all traffic.
Understand what you are not responsible for. The certification scheme takes a whole class of verification concerns — wallet-side tampering, key extraction, attestation forgery — off your plate. Knowing what the wallet side guarantees means you can focus your own hardening on what it does not.
For the regulatory context that frames all of this, see our walk-through of Implementing Regulation 2026/798 on wallet enrolment. For an opinion piece on how the recent disclosure cycle validates the open-source approach the EU has taken, see Open-source wallets' first real audit.
eIDAS Pro's managed verifier consumes certification metadata automatically and updates its trust chain as wallets are certified or decertified. If you want that logic handled for you, see our managed plans.
Share this article
Help others learn about eIDAS verification