Die Deadline für Relying Parties: was sich ändert und was offen ist
Die Verordnung (EU) 2024/1183, besser bekannt als eIDAS 2.0, ist im Mai 2024 in Kraft getreten. Sie verpflichtet die Mitgliedstaaten, ihren Bürgerinnen und Bürgern eine EU Digital Identity Wallet (EUDI Wallet) bereitzustellen, mit der sie sich ausweisen, Attribute nachweisen und qualifiziert signieren können. Die Wallets sollen in den Mitgliedstaaten bis Ende 2026 verfügbar sein, abhängig vom Erlass der Durchführungsrechtsakte, die technische Details festlegen. Für SaaS-Anbieter ist diese Frist aus einem anderen Grund relevant: Sie sind in der Sprache der Verordnung Relying Parties, also Dienste, die Wallet-Nachweise annehmen und darauf Entscheidungen stützen.
Was genau auf Relying Parties zukommt, hängt vom Sektor ab. Die Verordnung sieht vor, dass bestimmte private Dienste, die starke Nutzerauthentifizierung verlangen müssen, etwa im Bank- und Finanzwesen, im Verkehr, in der Energie, im Gesundheitswesen und in der Telekommunikation, die Wallet akzeptieren müssen, wenn Nutzer sie verwenden wollen. Sehr große Online-Plattformen werden ebenfalls einbezogen. Für viele B2B-SaaS-Anbieter gilt keine unmittelbare Annahmepflicht, aber ihre Kunden aus regulierten Branchen geben die Erwartung weiter. Wer in diesen Märkten verkauft, wird in Ausschreibungen nach Wallet-Fähigkeit gefragt werden, lange bevor eine Pflicht greift.
Wir legen Wert auf eine nüchterne Einordnung, denn in diesem Thema kursieren viele Behauptungen. Erstens sind die Fristen und Details abhängig von Durchführungsrechtsakten und nationaler Umsetzung. Zweitens ist der Reifegrad der Wallets heute nicht einheitlich. Drittens ändert sich das Bild laufend. Prüfen Sie deshalb den aktuellen Stand regelmäßig, etwa über den Architecture and Reference Framework der EUDI Wallet, und verlassen Sie sich nicht auf Zusagen von Anbietern, die Wallet-Readiness als abgeschlossen darstellen. Wir sagen es klar: Sign2x bereitet vor, ist aber nicht „EUDI-ready“. Wer das behauptet, ohne ein produktives Wallet-Ökosystem zu haben, verspricht etwas, das niemand halten kann.
Für SaaS-Teams heißt das: Die Deadline ist weniger ein Stichtag für einen Schalter, den Sie umlegen, als ein Zeitraum, in dem Erwartungen entstehen. Kunden werden fragen, ob Ihr Produkt Wallet-Nachweise verarbeiten kann, ob Sie Attribute wie Alter oder Berufsqualifikation annehmen und ob Sie eine Wallet-basierte Signatur unterstützen. Die ehrliche Antwort heute lautet bei den meisten Anbietern: „Wir bereiten die Architektur vor.“ Das ist besser als ein Versprechen, aber nur dann glaubwürdig, wenn Sie konkret erklären können, was Vorbereitung bedeutet.
Hinzu kommt die Rolle der Wallet bei der Signatur. Die Verordnung sieht vor, dass die Wallet das Erstellen qualifizierter elektronischer Signaturen ermöglicht, und zwar für nicht berufliche Zwecke kostenlos. Für Anbieter von Signaturstrecken ist das eine Chance und eine Unsicherheit zugleich: Nutzer könnten künftig mit ihrer Wallet qualifiziert unterzeichnen, ohne eine separate Identifikationsstrecke zu durchlaufen. Wie sich diese Möglichkeit in Ihre Prozesse einfügt, hängt davon ab, welche Wallets in Ihren Märkten verfügbar sind und wie Qualifizierte Vertrauensdiensteanbieter sie anbinden. Den Hintergrund zu den Stufen finden Sie im Beitrag SES, AES und QES in SaaS.
Warum Sie die Wallet-Anbindung nicht selbst bauen sollten
Der erste Reflex vieler Entwicklungsteams lautet: „Das ist ein Protokoll, das bauen wir.“ Bei der EUDI Wallet ist das eine riskante Entscheidung. Die Spezifikation bewegt sich, die Anforderungen an Relying Parties umfassen Registrierung, Zertifikate, Datenminimierung und Protokolle zur Präsentation und Prüfung von Nachweisen, und die Implementierungen der Mitgliedstaaten unterscheiden sich in Details. Wer heute eine eigene Anbindung baut, baut auf einem Fundament, das sich in den nächsten Monaten noch verschieben kann.
Hinzu kommt die Frage der Verantwortung. Als Relying Party tragen Sie Pflichten bei der Annahme von Nachweisen: Sie dürfen nur die Daten anfordern, die Sie für den Zweck brauchen, müssen sich registrieren und sich gegenüber der Wallet authentifizieren. Fehler in der Prüfung eines Nachweises sind keine Schönheitsfehler, sondern Sicherheitslücken. Die Pflege dieser Logik gehört in die Hände von Teams, die sie als Kernaufgabe betreiben, und nicht in einen Nebenstrang Ihres Produktteams.
Auch aus Kostensicht spricht wenig für Eigenbau. Die Wallet-Anbindung ist kein Alleinstellungsmerkmal Ihres Produkts. Kein Kunde kauft Ihre Software, weil Sie das Präsentationsprotokoll besonders elegant implementiert haben. Sie kaufen sie, weil sie ein Fachproblem löst, und die Wallet ist ein Kanal, über den Nutzer künftig Identität und Attribute einbringen. Behandeln Sie sie wie Zahlungsabwicklung: Man kann sie selbst bauen, aber die meisten sollten es nicht.
Ein weiterer Punkt ist die Betriebslast. Zertifikate laufen ab, Vertrauenslisten ändern sich, Spezifikationen werden aktualisiert. Wer eine eigene Anbindung betreibt, übernimmt eine laufende Wartungspflicht, die schwer zu planen ist. Das gilt besonders für ISVs mit vielen Mandanten, bei denen jede Änderung mehrfach wirkt. Der Aufwand skaliert mit der Zahl der Kunden, nicht mit dem Nutzen für sie.
Eine pragmatische Haltung lautet daher: Beobachten Sie die Entwicklung, verstehen Sie die Begriffe, ordnen Sie Ihre Anwendungsfälle ein, aber bauen Sie das Protokoll nicht selbst. Welche Anwendungsfälle realistisch sind, hängt von Ihrem Geschäft ab. Typische Kandidaten sind Altersnachweise, Identifikation bei der Kontoeröffnung, Berufsqualifikationen im Personalumfeld und Signaturen mit hohem Beweiswert. Für jeden dieser Fälle sollten Sie festhalten, welche Daten Sie wirklich brauchen, denn Datenminimierung ist in der Wallet-Logik ein Kernprinzip.
API-Abstraktion: Wallet als ein Identitätskanal unter mehreren
Der robuste Weg ist eine Abstraktion. Ihr Produkt spricht nicht mit der Wallet, sondern mit einer Schicht, die verschiedene Identifikations- und Signaturkanäle hinter einer stabilen Schnittstelle bündelt. Welche Kanäle dahinter stehen, ob Videoident, eID, Bank-Ident, Wallet oder etwas, das erst entsteht, bleibt austauschbar, ohne dass Ihr Produktcode sich ändert. Das ist das alte Prinzip der losen Kopplung, angewendet auf Identität.
Wie sieht das in der Praxis aus? Ihr Produkt legt einen Signaturvorgang an und gibt an, welche Anforderungen gelten: Signaturstufe, benötigte Attribute, gegebenenfalls Identifikationsniveau. Die Schicht darunter wählt oder ermöglicht den passenden Kanal und meldet das Ergebnis per Ereignis zurück. Ihr System erfährt nur: Vorgang identifiziert, Signatur geleistet, Ergebnis mit Referenz. Die Details des Kanals, ob ein Nutzer sich per Wallet oder per anderen Weg ausgewiesen hat, sind für Ihre Fachlogik zweitrangig und für den Nachweis in den Ereignisdaten festgehalten.
Dieser Ansatz hat drei Vorteile. Erstens schützt er Ihre Investition: Wenn sich Spezifikationen ändern, passt sich die Schicht an, nicht Ihr Produkt. Zweitens erlaubt er schrittweise Einführung: Sie können Wallet-basierte Wege für ausgewählte Mandanten oder Prozesse freischalten, sobald sie verfügbar und rechtlich geklärt sind. Drittens hält er das Nachweisformat konsistent: Ihre Ereignisdaten sehen gleich aus, egal, über welchen Kanal ein Nutzer identifiziert wurde, und Ihre Auswertungen müssen nicht pro Kanal angepasst werden.
Wichtig ist, dass die Abstraktion die rechtlichen Unterschiede nicht verwischt. Eine Signatur mit AES und eine mit QES haben verschiedene Beweiswirkung, und ein Wallet-Nachweis ersetzt nicht automatisch jede andere Prüfung. Ihre Oberfläche und Ihre Verträge müssen deshalb weiter klar machen, welche Stufe gilt und welche Konsequenz sie hat. Die Rechtsgrundlagen der Stufen finden Sie in der eIDAS-Verordnung in der Grundfassung, die durch die Verordnung 2024/1183 geändert wurde.
Für ISVs, die im Rahmen von White-label arbeiten, kommt ein Mandantenaspekt hinzu. Nicht jeder Ihrer Kunden wird dieselbe Wallet-Strategie wollen. Ein Mandant aus dem Gesundheitswesen hat andere Anforderungen als ein Immobilienverwalter. Eine mandantenfähige Abstraktion erlaubt, Kanäle je Mandant zu konfigurieren, statt eine globale Entscheidung zu erzwingen. Wie Ereignisse dabei sauber in Ihr System laufen, erklärt der Beitrag Webhook State Management.
Partner-QTSP: wer die Qualifikation trägt
Die qualifizierte elektronische Signatur setzt einen qualifizierten Vertrauensdiensteanbieter (QTSP) voraus, der von der Aufsicht zugelassen ist und die Anforderungen der eIDAS-Verordnung erfüllt. Das gilt auch in der Wallet-Welt: Die Wallet kann Identität und Signaturinitiierung liefern, die qualifizierte Signatur selbst entsteht bei einem Anbieter mit entsprechendem Status. Für SaaS-Anbieter bedeutet das, dass die Wahl des QTSP-Partners eine strategische Entscheidung bleibt.
Sign2x ist kein QTSP. Wir sind die API-Schicht, die Signaturstufen SES, AES und QES in Ihr Produkt bringt. Für QES arbeiten wir mit Partner-QTSPs, etwa Sign8, zusammen. Diese Rollenteilung ist nicht nur eine rechtliche Notwendigkeit, sondern ein Vorteil für Sie: Die Qualifikation bleibt dort, wo sie reguliert und geprüft wird, und Ihre Integration bleibt auf der API-Ebene, die Sie gestalten können. Wie Sie mit der Rolle von Partnern umgehen sollten, vertieft der Beitrag QTSP-Partner für ISVs.
Für die Wallet-Zukunft folgt daraus eine nüchterne Erwartung. Ob und wann QTSPs Wallet-basierte Signaturen produktiv anbinden, entscheiden die Anbieter und die Aufsicht. Wir machen dazu keine Zusagen im Voraus. Was wir tun können, ist, die API so zu gestalten, dass neue Kanäle ohne Bruch in Ihrem Produkt hinzukommen können, sobald sie produktiv und rechtlich tragfähig sind. Das ist Vorbereitung, kein Produktversprechen.
Bei der Auswahl eines QTSP-Partners sollten Sie ein paar Fragen stellen. Welche Signaturniveaus und Identifikationswege sind heute produktiv? Wie ist der Fahrplan zu Wallet-Anbindungen, und wie verbindlich ist er? Wo werden Daten verarbeitet, und welches Recht gilt? Wie sehen Exit und Datenexport aus? Und wie verteilen sich Haftung und Support im Störungsfall? Diese Fragen gelten unabhängig von der Wallet, aber sie werden mit ihr dringlicher, weil die Zahl der Kanäle wächst.
Priorisierung: drei Szenarien für die nächsten zwölf Monate
Damit die Vorbereitung nicht im Allgemeinen bleibt, lohnt es, drei Szenarien durchzuspielen. Im ersten Szenario ist Ihr Produkt ein Vertragsprozess in einer regulierten Branche, etwa bei Versicherungen oder in der Vermögensverwaltung. Hier erwarten Kunden früh Aussagen zur Wallet, weil Identifikation und Signatur ohnehin Pflichtbestandteile sind. Ihr Ziel für die nächsten Monate sollte sein, die Abstraktionsschicht sauber zu halten und mit Ihrem Partner-QTSP offen über Fahrpläne zu sprechen, statt eigene Termine zu versprechen.
Im zweiten Szenario ist Ihr Produkt eine Plattform mit Nutzerkonten, die Identität nur nebenbei braucht, etwa ein Marktplatz oder ein Portal für Dienstleister. Hier ist die Wallet vor allem ein Weg, Registrierungen zu vereinfachen und Altersnachweise datensparsam zu führen. Der Druck ist geringer, die Chance ist die Reibungsminderung beim Onboarding. Planen Sie hier ein Experiment mit einem begrenzten Nutzerkreis, sobald ein verlässlicher Kanal verfügbar ist, und messen Sie, ob Abschlüsse tatsächlich steigen.
Im dritten Szenario ist Ihr Produkt ein Baustein anderer Software, etwa eine API, die ISVs in ihre Lösungen einbauen. Dann multiplizieren sich die Anforderungen mit der Zahl Ihrer Kunden, und die Abstraktion ist kein Komfort, sondern Überlebensfrage. Ihre Kunden werden wissen wollen, wie Sie Änderungen der Spezifikation auffangen, ohne dass sie ihre Integration anfassen müssen. Eine ehrliche Antwort ist hier ein Versionierungs- und Änderungskonzept mit angemessenen Vorlaufzeiten. Wir empfehlen, dieses Konzept schriftlich festzuhalten und in Ihre Vertragsunterlagen aufzunehmen: Wie lange gelten Schnittstellenversionen? Wie werden Änderungen angekündigt? Welche Testumgebung steht für neue Kanäle bereit? Mit solchen Zusagen schaffen Sie Planbarkeit für Ihre Kunden, ohne technisch etwas zu versprechen, das vom Verhalten Dritter abhängt.
In allen drei Szenarien gilt dieselbe Disziplin: Behaupten Sie nicht mehr, als Sie liefern können, und dokumentieren Sie, was Sie wissen und was nicht. Kunden aus regulierten Märkten verzeihen Unsicherheit, wenn sie offen benannt wird, aber nicht, wenn sie im Nachhinein auftaucht. Ein einseitiges Papier mit Annahmen, Abhängigkeiten und offenen Punkten wirkt in Vertriebs- und Auditgesprächen erstaunlich überzeugend, weil es zeigt, dass Sie das Thema durchdrungen haben.
Was Sign2x vorbereitet und was nicht
Zur Transparenz: Sign2x läuft auf der Open Sovereign Cloud (OSC) von T-Systems, und die Plattform ist als API-Schicht für SES, AES und QES ausgelegt. Aus dieser Architektur lassen sich Wallet-Szenarien vorbereiten, ohne dass wir sie heute als produktives Feature bewerben. Konkret bedeutet Vorbereitung für uns: stabile, kanalunabhängige Ereignismodelle, mandantenfähige Konfiguration, saubere Trennung zwischen API-Schicht und Qualifikation beim Partner-QTSP sowie Hosting unter europäischem Recht.
Was wir nicht behaupten: Wir behaupten nicht, dass die EUDI Wallet heute in Sign2x produktiv nutzbar ist. Wir behaupten nicht, dass wir eine Zertifizierung für Wallet-Relying-Parties besitzen. Und wir behaupten keine Zeitpläne, die wir nicht kontrollieren. Wer eine Wallet-Anbindung heute produktiv braucht, sollte das im Gespräch mit uns und mit den Partner-QTSPs offen klären, damit niemand auf einer falschen Annahme plant. Eine Einordnung unserer Haltung zu Souveränität bietet der Beitrag Cloud Act vs Datensouveränität.
Was Sie selbst vorbereiten können, ist erheblich. Erstens: Inventarisieren Sie, wo in Ihrem Produkt Identität oder Attribute eine Rolle spielen. Zweitens: Prüfen Sie, welche Daten Sie wirklich brauchen, und streichen Sie, was nur aus Gewohnheit erhoben wird. Drittens: Trennen Sie in Ihrem Code Identitätsprüfung von Fachlogik, damit ein neuer Kanal keine Fachlogik berührt. Viertens: Sorgen Sie für ein sauberes Ereignismodell, das den Kanal als Attribut führt. Fünftens: Beobachten Sie die Durchführungsrechtsakte und die Veröffentlichungen der Mitgliedstaaten, besonders in Ihren Zielmärkten.
Für regulierte Kunden kommt die Auditsicht hinzu. Wenn Sie später Wallet-Nachweise annehmen, müssen Sie belegen können, welche Prüfungen stattfanden. Ein Ereignisprotokoll, das Kanal, Zeitpunkt und Ergebnis festhält, ist dafür die Grundlage. Wie das im Kontext von Lieferkettenpflichten funktioniert, beschreibt der Beitrag DORA Artikel 30 und der API-Audit-Trail. Wir betonen auch hier: Das ist Evidence und keine Zertifizierung.
Zum Einstieg empfehlen wir einen kurzen Workshop mit Produkt, Recht und Technik: Welche Anwendungsfälle könnten von einer Wallet profitieren? Welche Kunden fragen bereits? Was wäre der Mindestumfang, der in zwölf Monaten sinnvoll wäre? Aus den Antworten entsteht eine Roadmap, die auf Ihre Märkte passt, statt auf allgemeine Erwartungen. Halten Sie die Ergebnisse in einem kurzen Dokument fest, das Sie quartalsweise überprüfen, denn bei einem Thema mit so vielen offenen Rechtsakten veraltet jede Planung schneller als bei gewöhnlichen Produktthemen. Benennen Sie außerdem eine verantwortliche Person, die Veröffentlichungen der Kommission und der Mitgliedstaaten verfolgt. Unterlagen und Grundlagen finden Sie im Developer Hub, Begriffe im Help Center, Beispiele unter Use Cases, und eine Selbsteinschätzung bietet das Sign2x Quiz. Weitere Fachbeiträge finden Sie im Sign2x Blog.
EUDI-Vorbereitung mit uns besprechen
Verwandte Beiträge: GwG-konforme Signatur-API: Ident-Provider, QTSP-Partner, Sign2x-Schicht und eIDAS-Signaturen in der souveränen Cloud. Informationen zur Informationssicherheit bietet das BSI.
Häufige Fragen
Bis wann müssen Mitgliedstaaten die EUDI Wallet bereitstellen?
Die Verordnung (EU) 2024/1183 sieht die Bereitstellung bis Ende 2026 vor, abhängig vom Erlass der Durchführungsrechtsakte. Prüfen Sie den aktuellen Stand in Ihren Zielmärkten.
Muss mein SaaS-Produkt die Wallet akzeptieren?
Das hängt vom Sektor ab. Bestimmte regulierte Dienste und sehr große Plattformen müssen die Wallet annehmen. Viele B2B-Anbieter trifft keine unmittelbare Pflicht, aber ihre regulierten Kunden geben Erwartungen weiter.
Ist Sign2x EUDI-ready?
Nein. Sign2x bereitet die Architektur vor, etwa mit kanalunabhängigen Ereignismodellen und mandantenfähiger Konfiguration. Eine produktive Wallet-Anbindung behaupten wir nicht.
Ersetzt die Wallet den QTSP?
Nein. Die Wallet kann Identität und Signaturinitiierung liefern. Die qualifizierte Signatur selbst entsteht bei einem QTSP. Sign2x ist kein QTSP, QES läuft über einen Partner wie Sign8.
Soll ich die Wallet-Anbindung selbst entwickeln?
In der Regel nein. Spezifikationen und Durchführungsrechtsakte bewegen sich, und die Pflichten als Relying Party sind sicherheitskritisch. Eine Abstraktionsschicht schützt Ihre Investition.
