ENISAs EUDI-Wallet-Zertifizierungsschema: Was Verifier wissen müssen

Ein Zertifizierungsschema mit echten Konsequenzen

Am 2. April 2026 veröffentlichte die Agentur der Europäischen Union für Cybersicherheit (ENISA) den Entwurf des EUDI Wallet Cybersecurity Certification Scheme v0.4.614 und eröffnete die öffentliche Konsultation. Die Frist für Stakeholder-Rückmeldungen endet am 30. April 2026. Ein erläuterndes Webinar hielt ENISA am 8. April 2026 ab.

Das ist keine obskure Verwaltungsübung. Nach dem geänderten eIDAS-Rahmen müssen Mitgliedstaaten ihren Bürgern bis Ende 2026 mindestens eine zertifizierte EU Digital Identity Wallet bereitstellen. Das Schema, das ENISA jetzt finalisiert, ist das Instrument, über das diese Zertifizierung tatsächlich erteilt wird. Welche Wallets es erfüllen und welche nicht, bestimmt unmittelbar, welchen Attestierungen ein Verifier zum Start vertrauen kann.

Wer einen Verifier baut oder betreibt, sollte dieses Dokument verstehen — selbst wenn Sie selbst nie etwas zertifizieren müssen.

Was ENISA zertifiziert

Der Entwurf ist eine Cybersicherheitszertifizierung für die Wallet-Software selbst, nicht für den Endnutzer, nicht für den Verifier und nicht für das gesamte Ökosystem. Er bewertet, ob eine konkrete EUDI-Wallet-Implementierung eine definierte Sicherheitslatte gegenüber einem veröffentlichten Bedrohungsmodell erfüllt.

Das Schema baut auf Europas bestehendem EUCC-Fundament (European Cybersecurity Certification scheme based on Common Criteria) auf, passt es aber an das spezifische Risikomodell einer mobilen Wallet an. Common Criteria ist in der Smartcard- und HSM-Welt gut eingeführt, jedoch schwerer als das, was Consumer-Software üblicherweise kennt. Ein reiner EUCC-Ansatz hätte einen Zertifizierungsprozess bedeutet, der in Jahren gemessen wird — viel zu langsam für die Frist im Dezember 2026. Der Entwurf wählt deshalb einen pragmatischen Mittelweg.

Drei Dinge, die der Entwurf richtig macht

Transparenz des Bedrohungsmodells. Der Entwurf beschreibt explizit, welche Angreiferklassen das Schema abwehrt, inklusive Risikobewertungen. Eine willkommene Abkehr von früheren EU-Zertifizierungsansätzen, die ihre Bedrohungsmodelle eher in internen Gremien verborgen hielten.

Differenzierte Vertrauensniveaus. Nicht jede Wallet braucht dieselbe Sicherheitslatte. Eine Wallet für grenzüberschreitende Reise-Credentials oder hochwertige Banking-Berechtigungen trägt ein anderes Risiko als eine, die nur der Altersverifikation dient. Der Entwurf erlaubt differenzierte Vertrauensniveaus, damit Mitgliedstaaten kalibrieren können.

Abstimmung mit der Wallet-Referenzarchitektur. Das Schema ist gegen die aktuell diskutierte Fassung des EUDI Wallet Architecture and Reference Framework (ARF) formuliert, wodurch die bewerteten Kontrollen direkt auf die technischen Komponenten abgebildet werden, die eine Wallet tatsächlich besitzt.

Drei Dinge, die der Entwurf offen lässt

Anforderungen an Remote-Attestierung. Mehrere Abschnitte verweisen darauf, dass die Wallet ihre Integrität gegenüber dem Verifier nachweisen muss — etwa über Android Key Attestation oder iOS DeviceCheck — ohne vollständig zu definieren, welche Belege akzeptabel sind. In diesem Stadium teils unvermeidbar, schafft das aber Unsicherheit für Verifier-Implementierer, die entscheiden müssen, welche Attestierungssignale sie prüfen.

Die Frage der Open-Source-Kompatibilität. Der Entwurf adressiert nicht direkt, wie eine vollständig quelloffene Wallet mit reproduzierbaren Builds zertifiziert werden kann. Mehrere Community-Stellungnahmen in der Konsultation drängen auf klarere Formulierungen. Die jüngste Offenlegung rund um die EU-Altersverifikations-App hat diese Debatte zugespitzt: Sollen Open-Source-Implementierungen im großen Stil zulässig sein, muss das Zertifizierungsschema sie berücksichtigen, ohne Zertifizierungsrituale pro Build zu erzwingen.

Zusammenspiel mit nationalen Schemata. Jeder Mitgliedstaat hat eine eigene nationale Zertifizierungsstelle. Wie das ENISA-Schema mit nationalen Zertifizierungen interagiert — ob es sie ablöst, parallel läuft oder gegenseitige Anerkennung verlangt — wird angesprochen, aber nicht vollständig ausbuchstabiert.

Was Verifier tun sollten

Das Zertifizierungsschema richtet sich an Wallet-Aussteller, nicht an Verifier. Sie müssen sich nicht zertifizieren lassen, um darauf aufzubauen. Trotzdem prägt das Schema Ihre Verifier-Logik in zweierlei Hinsicht konkret.

Metadaten, denen Sie vertrauen können. Sobald das Schema in Kraft ist, enthalten Wallet-Attestierungen signierte Metadaten, die ausweisen, welche Zertifizierung eine Wallet besitzt. Ihr Verifikationscode kann darauf basierend Vertrauensentscheidungen treffen — etwa wertvolle Abläufe von Wallets ablehnen, die nur auf der Basisstufe zertifiziert sind.

Bedrohungsszenarien, die Sie einplanen sollten. Das Bedrohungsmodell im Entwurf ist eine gute Leseliste für defensive Codierung auf Verifier-Seite. Auch wenn Sie für die Wallet-Seite nicht verantwortlich sind: Zu wissen, wogegen die Wallet schützt, zeigt Ihnen, welche Angriffe Ihr Verifier nicht auf die Wallet abwälzen darf. Wie diese Schichten zusammenwirken, zeigt unser technischer Tiefgang zur eIDAS-Verifikation.

Wie man die Konsultation liest

Wer sich selbst an der Konsultation beteiligen will, findet die Rückmeldekanäle auf der Zertifizierungsseite von ENISA. Nützliche Rückmeldungen kommen typischerweise von:

• Verifier-Betreibern mit praktischer Erfahrung, welche Attestierungs-Metadaten sinnvoll auswertbar sind.
• Open-Source-Implementierern, die zu Reproducible-Build-Anliegen sprechen können.
• Behörden der Mitgliedstaaten mit Positionen zur Abstimmung mit nationalen Schemata.

Ein kursorisches Lesen des Entwurfs dauert wenige Stunden. Eine fundierte Stellungnahme kostet Tage. Wer nicht antworten möchte, profitiert trotzdem davon, das Bedrohungsmodell und den Abschnitt zu differenzierten Vertrauensniveaus sorgfältig zu lesen.

Der Finanzierungskontext

Am Rande bemerkenswert: Hinter der Zertifizierungsarbeit von ENISA steht eine Beitragsvereinbarung über 1,6 Millionen Euro, die im Februar 2026 mit der Europäischen Kommission geschlossen wurde und über zwei Jahre läuft. Die Vereinbarung liegt unter dem Digital Europe Work Programme 2025–2027 und finanziert sowohl die zentrale Schema-Entwicklung als auch den nationalen Kapazitätsaufbau zur Unterstützung der Zertifizierungsstellen der Mitgliedstaaten.

Die Beitragsvereinbarung ist deshalb wichtig, weil sie die Erwartung der Kommission signalisiert, dass Zertifizierung eine kontinuierliche Tätigkeit ist — keine einmalige Zeremonie vor dem Dezember 2026. Wallets werden rezertifiziert, neue Versionen werden bewertet, und verifierseitige Metadaten-Prüfungen bleiben auch lange nach dem Start relevant.

Die Zeitachse von hier an

• 30. April 2026 — Konsultation endet.
• Q2 2026 — ENISA konsolidiert Rückmeldungen und veröffentlicht den nächsten Entwurf.
• Q3 2026 — Erwartete formelle Annahme des Schemas.
• Q4 2026 — Erste Wallet-Zertifizierungen starten; nationale Zertifizierungen richten sich darauf aus.
• Ende Dezember 2026 — Jeder Mitgliedstaat muss mindestens eine zertifizierte Wallet live haben.

Das ist ambitioniert. Realistisch wird die erste Welle der Zertifizierungen die Sandbox-Wallets der Stufe 1 aus Frankreich, Deutschland und voraussichtlich Dänemark und Irland abdecken. Den aktuellen Stand jedes nationalen Projekts zeigt unser Rollout-Tracker für April 2026.

Wie das die Verifier-Strategie berührt

Wer die Verifier-Seite seiner Integration plant, sollte drei praktische Implikationen beachten.

Zertifizierungs-Metadaten als First-Class-Eingabe behandeln. Hartkodieren Sie kein Vertrauen in bestimmte Wallet-Aussteller. Ihr Verifier sollte bei jeder Präsentation die signierten Zertifizierungs-Metadaten konsultieren und seine Logik entsprechend verzweigen. Unser OpenEUDI SDK exponiert diese Metadaten genau deshalb über eine Standardschnittstelle, weil sie tragend sein werden.

Einplanen, dass Rezertifizierungen anfallen. Eine heute zertifizierte Wallet kann morgen ihren Status verlieren, wenn ein Vorfall ihn ändert. Ihr Verifier sollte Wallets mit widerrufener Zertifizierung graziös behandeln, statt abzustürzen oder jeglichen Traffic abzulehnen.

Verstehen, wofür Sie nicht verantwortlich sind. Das Zertifizierungsschema nimmt eine ganze Klasse von Verifikationssorgen — Wallet-seitiges Tampering, Schlüsselextraktion, Attestierungsfälschung — von Ihrer Liste. Zu wissen, was die Wallet-Seite garantiert, erlaubt es, das eigene Hardening auf das zu konzentrieren, was sie nicht garantiert.

Den regulatorischen Rahmen dazu liefert unser Durchgang der Durchführungsverordnung 2026/798 zur Wallet-Einschreibung. Ein Meinungsbeitrag dazu, wie der jüngste Offenlegungszyklus den Open-Source-Ansatz der EU validiert, findet sich unter Das erste echte Audit quelloffener Wallets.

---

Der Managed Verifier von eIDAS Pro verarbeitet Zertifizierungs-Metadaten automatisch und aktualisiert seine Vertrauenskette, sobald Wallets zertifiziert oder dezertifiziert werden. Wenn Sie diese Logik abgenommen haben möchten, siehe unsere Managed Plans.