Die EUDI-Wallet und die Relying-Party-Sicht

Problem in der Praxis

Viele Organisationen behandeln die EUDI-Wallet als reines IT- oder Produktthema und unterschätzen, dass sie als Relying Party selbst zum regulierten Teilnehmer wird. Die Erwartung "einmal eine Schnittstelle bauen, dann weisen sich Kunden aus" greift zu kurz.

Es stellen sich Fragen, die nicht die Entwicklung, sondern Sicherheit und Governance beantworten müssen: Welche Attribute darf der Dienst anfragen, und wie wird Datenminimierung erzwungen? Wie registriert er sich als vertrauende Stelle? Wie wird geprüft, ob ein Nachweis echt, gültig und nicht widerrufen ist? Wer das erst zur Einführung klärt, baut eine Insellösung neben dem ISMS und erzeugt später Nachweis- und Aufsichtsprobleme.

CISO-Einordnung

Die EUDI-Wallet verschiebt Verantwortung auf die vertrauende Seite. Der CISO sollte die Relying-Party-Rolle entlang weniger Leitfragen einordnen, nicht entlang einzelner Normparagraphen:

• Welche Prozesse sollen Wallet-gestützte Identitäten oder Attribute akzeptieren?
• Welche Attribute sind je Zweck wirklich erforderlich, und welche nicht?
• Wie werden Echtheit und Gültigkeit der Nachweise verlässlich geprüft?
• Welche Registrierungs- und Transparenzpflichten treffen den Dienst?
• Was ist die Rückfalloption bei Ausfall oder Nicht-Verifizierbarkeit?

Die Zuständigkeiten sind klar abzugrenzen: Die Aufsicht über (qualifizierte) Vertrauensdiensteanbieter liegt in Deutschland bei der Bundesnetzagentur, die auch die Deutsche Vertrauensliste führt; die Sicherheitszertifizierung der Wallet ist beim BSI vorgesehen, amtlich benannt ist die Stelle bislang nicht; verbindliche Grundlage der Zertifizierung ist die Durchführungsverordnung (EU) 2024/2981, die Schemata des Cybersecurity Act einbezieht, soweit verfügbar und relevant, während das Architecture and Reference Framework (ARF) informativ bleibt und keine Zertifizierungsgrundlage ist. Die Wallet ersetzt die bekannten Vertrauensdienste nicht, sondern ergänzt sie um geregelten Attributnachweis und starke Authentifizierung.

Umsetzungsperspektive

Empfehlenswert ist ein schrittweiser Aufbau, der die Relying-Party-Fähigkeit als kontrollierten ISMS-Baustein verankert. Am Anfang steht die Bedarfsklärung: Wo entsteht echter Nutzen, etwa bei Onboarding, starker Authentifizierung oder Altersnachweis? Daraus leitet sich die Attributliste ab; Datenminimierung ist dabei Designprinzip, kein Nachgedanke. Anschließend ist die formale Rolle zu klären, denn die Wallet-Nutzung ist an eine Registrierung als Relying Party und an Transparenz gegenüber den Nutzern geknüpft; das Registrierungsverfahren regelt die Durchführungsverordnung (EU) 2025/848, die ab dem 24. Dezember 2026 gilt, und es gehört früh eingeplant.

Im Betrieb steht die Verifikationslogik (Echtheit, Gültigkeit, Widerruf, Vertrauensanker), versioniert und überwacht statt als Einmalintegration. Den Rahmen liefert ein ISMS: ISO/IEC 27001 oder, gleichwertig, der IT-Grundschutz des BSI. Soweit die eigene Organisation unter NIS2 fällt (Vertrauensdiensteanbieter zählen dort zur digitalen Infrastruktur, andere Stellen je nach Sektor), sollte man diese Themen mit der NIS2-Umsetzung verzahnen statt parallele Strukturen aufzubauen.

Typische Fehler

1. Die Wallet wird als reines Entwicklungsthema behandelt, ohne Datenschutz, ISMS und Aufsicht einzubinden.
2. Es werden mehr Attribute angefragt als der Zweck braucht, weil Datenminimierung nicht im Design verankert ist.
3. Registrierungs- und Transparenzpflichten werden zu spät geklärt, sodass die Vorlaufzeit fehlt.
4. Verifikation wird als Einmalintegration gebaut statt als überwachter Betriebsbaustein.
5. Zuständigkeiten werden verwechselt: Wallet-Zertifizierung (beim BSI vorgesehen) und Vertrauensdiensteaufsicht (Bundesnetzagentur).

Risiken und Trade-offs

Die Wallet verspricht starke, EU-weit anerkannte Identitäten, verlagert aber Pflichten und Haftungsfragen auf die vertrauende Seite. Wer zu früh und zu breit akzeptiert, riskiert unklare Prozesse und Datenschutzfragen; wer zu spät startet, erfüllt kommende Akzeptanzerwartungen nicht.

Ein Trade-off liegt zwischen Komfort und Datenminimierung: Attribute "auf Vorrat" abzufragen erhöht Datenschutzrisiko und Angriffsfläche. Hinzu kommt die Abhängigkeit von einer jungen Infrastruktur; die Stichtage sind bestimmbar (Bereitstellungspflicht errechnet zum 24. Dezember 2026, Akzeptanzpflicht bestimmter privater Dienste errechnet spätestens zum 24. Dezember 2027), eine belastbare Planung braucht dennoch eine Rückfalloption für Ausfälle und Verzögerungen.

Entscheidungspunkte

• In welchen Prozessen soll der Dienst die Wallet akzeptieren, und in welchen bewusst nicht?
• Welche Attribute sind je Anwendungsfall erforderlich, und wie wird Datenminimierung erzwungen?
• Wer verantwortet die Relying-Party-Rolle inklusive Registrierung und Transparenzpflichten?
• Wird die Sicherheitssteuerung über ISO/IEC 27001 oder über den IT-Grundschutz aufgehängt?
• Welche Rückfalloption gilt bei Ausfall oder Nicht-Verifizierbarkeit eines Nachweises?

Praktische Empfehlungen

1. Behandeln Sie die Relying-Party-Rolle als ISMS-Baustein mit klarem Owner, nicht als isoliertes IT-Projekt.
2. Definieren Sie je Anwendungsfall eine minimale Attributliste und erzwingen Sie Datenminimierung im Design.
3. Klären Sie Registrierungs- und Transparenzpflichten früh und an der Primärquelle.
4. Bauen Sie Verifikation (Echtheit, Gültigkeit, Widerruf) als überwachten Betriebsbaustein und halten Sie eine Rückfalloption vor.
5. Halten Sie die Zuständigkeiten auseinander: Wallet-Zertifizierung beim BSI vorgesehen, Vertrauensdiensteaufsicht bei der Bundesnetzagentur.

Relevante Normreferenzen

• Verordnung (EU) Nr. 910/2014 (eIDAS) i.d.F. der Verordnung (EU) 2024/1183: EU-Rechtsrahmen für eID, Vertrauensdienste und EUDI-Wallet; öffentlich zugänglich und zitierfähig.
• ETSI-Normenfamilie EN 319 4xx: Referenz für die Struktur von Sicherheits- und Betriebsanforderungen; lizenziert, daher nur Strukturverweis, kein Volltext.
• ISO/IEC 27001: Referenz für das ISMS, in dem die Relying-Party-Fähigkeit gesteuert wird.