EUDI Wallets kommen bis Ende 2026: Welche 5 Vorarbeiten IAM- und Service-Teams jetzt beginnen sollten

Die European Digital Identity Wallet, kurz EUDI Wallet, ist kein fernes EU-Zukunftsprojekt mehr. Mit der Verordnung (EU) 2024/1183 steht der Rahmen, und die Europäische Kommission beschreibt das Zielbild klar: Die Mitgliedstaaten müssen ihren Bürgern und Unternehmen bis Ende 2026 digitale Wallets bereitstellen. Für IT-Organisationen ist das keine abstrakte Regulierung, sondern eine konkrete Veränderung an der Grenze zwischen Identität, Onboarding, Nachweisführung und digitalem Service.

Gerade im Unternehmensumfeld wird die EUDI Wallet oft vorschnell als „neues Login-Verfahren“ gelesen. Das greift zu kurz. Der größere Hebel liegt dort, wo Organisationen heute mit Medienbrüchen, PDF-Nachweisen, manueller Identitätsprüfung oder länderspezifischen Sonderprozessen kämpfen. Die Wallet soll Identitäten und Attribute wie berufliche Nachweise, Organisationsbezug oder andere elektronische Bescheinigungen standardisiert, selektiv und grenzüberschreitend nutzbar machen. Für IAM, Service-Management und digitale Produktteams heißt das: Jetzt ist der richtige Zeitpunkt, die betroffenen Prozesse auseinanderzunehmen.

Die Kommission verknüpft die Wallet ausdrücklich mit einer gemeinsamen Architecture and Reference Framework, offenen Referenzkomponenten und großen Pilotprogrammen in Bereichen wie Finanzdienstleistungen, Bildung, Mobilität, Zahlungen und organisatorischen Identitäten. Wer erst reagiert, wenn nationale Wallets in der Fläche auftauchen, wird im Betrieb unter Zeitdruck Integrations-, Rechts- und Supportfragen gleichzeitig lösen müssen. Sinnvoller ist es, die Vorarbeit jetzt strukturiert zu beginnen.

Besonders diese fünf Punkte sollten Unternehmen 2026 nicht länger vertagen.

1. Zuerst die betroffenen Geschäftsprozesse identifizieren, nicht zuerst eine Wallet-Demo bauen

Die erste Fehlannahme lautet oft: Sobald Wallets verfügbar sind, werden sie einfach an das bestehende SSO angeschlossen. In der Praxis ist der wertvollere Startpunkt aber das Prozessinventar. Wo muss eine Organisation Personen oder Unternehmen heute eindeutig identifizieren? Wo werden Nachweise geprüft, die aus unterschiedlichen Ländern oder Institutionen stammen? Und an welchen Stellen entstehen Wartezeiten, Fehler oder Compliance-Risiken, weil Identitätsdaten manuell verarbeitet werden?

Typische Kandidaten sind digitale Kontoeröffnungen, B2B-Onboarding, Lieferantenportale, qualifizierte Freigaben, Zugang zu regulierten Services, Personal- und Berechtigungsprozesse mit externen Nachweisen sowie Szenarien, in denen Organisationen vertretungsberechtigte Personen prüfen müssen. Genau hier entfaltet die Wallet mehr Nutzen als bei einem gewöhnlichen Mitarbeiterlogin in ein Intranet. Die EU-Pilotprojekte zeigen das deutlich: Dort geht es nicht nur um Anmeldung, sondern um Zahlungen, Vertragsunterzeichnung, Mobilitätsnachweise, Bildungsnachweise und organisatorische Identitäten.

Für die Praxis bedeutet das: IAM-Teams sollten gemeinsam mit Fachbereichen, Recht, Compliance und Service-Ownern eine Liste der Prozesse erstellen, in denen verlässliche digitale Nachweise echten Aufwand oder Risiko reduzieren. Erst wenn diese Liste steht, lohnt sich ein technischer Integrationspilot. Sonst wird aus der Wallet schnell ein Technologiethema ohne belastbaren Business Case.

2. Authentifizierung, Attributnachweise und Organisationsvertretung sauber trennen

Die EUDI Wallet zwingt Organisationen zu einer Architekturfrage, die in vielen heutigen Portalen unsauber gelöst ist: Wofür genau braucht der Service eigentlich welchen Nachweis? Nicht jeder Prozess benötigt eine starke persönliche Identifikation. Manche Abläufe brauchen nur eine Altersbestätigung, andere einen Ausbildungsnachweis, wieder andere den Nachweis, dass eine Person für ein Unternehmen handeln darf. Die Wallet-Logik begünstigt gerade diese feinere Trennung, weil Nutzer nur die jeweils notwendigen Informationen teilen sollen.

Das ist mehr als Datenschutz-Rhetorik. Wer seine digitalen Services heute auf ein grobes Prinzip wie „vollständige Identifikation oder gar nichts“ gebaut hat, wird die Vorteile der Wallet verschenken. Dann werden weiterhin zu viele Daten erhoben, obwohl der eigentliche Prozess nur zwei oder drei Attribute braucht. Gleichzeitig müssen Unternehmen dort, wo es um Vertragsabschlüsse, sensible Freigaben oder Organisationsrollen geht, genauer definieren, welche Kombination aus Person, Attribut und Vertretungsrecht nötig ist.

Ein belastbares Zielbild unterscheidet deshalb mindestens drei Ebenen: Erstens die Authentifizierung der Person, zweitens die Vorlage qualifizierter oder vertrauenswürdiger Attribute und drittens den Nachweis einer organisatorischen Rolle oder Vertretungsbefugnis. Wer diese Ebenen früh im Daten- und Prozessmodell trennt, kann Wallet-Funktionen später gezielt nutzen, statt sie krampfhaft auf alte Formulare zu kleben.

3. Relying-Party- und Vertrauensprozesse organisatorisch vorbereiten

Die Wallet-Einführung ist kein reines SDK-Projekt. Die europäische Architektur beschreibt ein Ökosystem aus Issuern, Wallets, Relying Parties, Vertrauenslisten, Zertifizierungen und festgelegten Protokollen. Für Unternehmen bedeutet das: Wer Wallet-Nachweise akzeptieren will, braucht nicht nur eine Schnittstelle, sondern einen geregelten Aufnahmeprozess in die eigene Service-Governance.

Praktische Fragen sind zum Beispiel: Welcher digitale Service darf welche Wallet-Nachweise anfordern? Wer prüft, ob die angeforderten Attribute fachlich wirklich erforderlich sind? Wer verantwortet die Registrierung des Dienstes als vertrauender Akteur, wenn nationale oder europäische Vorgaben dies verlangen? Und wie wird dokumentiert, auf welcher Rechts- oder Prozessgrundlage ein bestimmter Nachweis akzeptiert oder abgelehnt wird?

Genau hier sollten IT-Management und Governance früh Standards festziehen. Sinnvoll sind ein kleines Wallet-Control-Framework, ein Freigabeprozess für neue Anwendungsfälle, klare Vorgaben für Datenminimierung und eine technische Referenzarchitektur für vertrauende Dienste. Wenn diese Steuerung fehlt, droht Wildwuchs: einzelne Produktteams bauen Wallet-Funktionen unterschiedlich ein, fordern unnötige Attribute an und erzeugen damit neue Audit- und Datenschutzprobleme.

4. Service Desk, Lifecycle und Fallbacks neu denken

Auch wenn die Wallet in vielen Präsentationen elegant wirkt, endet ihre Einführung nicht bei der erfolgreichen Demo. Im Betrieb stellen sich sofort Fragen zu Support und Ausnahmefällen. Was passiert, wenn ein Nachweis abgelaufen ist? Wie wird ein Prozess fortgesetzt, wenn ein Nutzer noch keine kompatible Wallet hat? Wie erkennt der Service Desk, ob ein Fehler auf Wallet-Seite, beim ausstellenden Nachweis, in der Vertrauenskette oder im eigenen Fachverfahren liegt?

Diese Fragen sind für ITSM-Teams entscheidend. Die EUDI Wallet bringt neue Störungsklassen und neue Übergänge zwischen First-Level-Support, IAM, Fachverfahren, Datenschutz und externen Vertrauensdiensten. Organisationen sollten deshalb vor einem Livegang Betriebsbausteine definieren: Supportleitfäden, Eskalationspfade, Monitoring auf Integrationsfehler, Regeln für Nachweisablauf und Widerruf sowie dokumentierte Fallbacks für Nutzer, die vorübergehend nicht per Wallet weiterkommen.

Wichtig ist dabei, Fallback nicht als Einladung zu dauerhaften Schattenprozessen zu missverstehen. Ein manueller Alternativweg kann für Übergangsphasen nötig sein, darf aber nicht dazu führen, dass das eigentliche Wallet-Verfahren im Alltag umgangen wird. Gute Betriebsmodelle messen deshalb explizit, wie oft Fallbacks genutzt werden, warum sie ausgelöst wurden und an welcher Stelle die Prozesskette noch nicht tragfähig ist.

5. Grenzüberschreitende Tests und Referenzimplementierungen früh nutzen

Die Kommission und die Mitgliedstaaten haben nicht ohne Grund eine gemeinsame Architecture and Reference Framework, eine Referenzimplementierung und mehrere groß angelegte Piloten aufgebaut. Der Mehrwert der Wallet entsteht gerade durch Interoperabilität, nicht durch einen isolierten nationalen Sonderweg. Unternehmen sollten diese Vorarbeit aktiv nutzen, statt nur auf lokale Produktankündigungen einzelner Anbieter zu warten.

Für technische und fachliche Teams heißt das konkret: Testen Sie nicht nur, ob ein Wallet-Login in einer Demo funktioniert. Testen Sie komplette Prozessketten. Dazu gehören Attributanfragen, Einwilligungs- und Offenlegungslogik, Fehlerbilder bei unvollständigen Nachweisen, Logging ohne übermäßige Datenspeicherung, länderspezifische Unterschiede sowie die Frage, wie ein Fachprozess mit grenzüberschreitenden Identitäten umgeht. Gerade B2B-Portale, Bildungs- und Zertifizierungsplattformen, Versicherungen, Finanzdienstleister und stark regulierte Self-Service-Strecken sollten hier früh Erfahrungswerte sammeln.

Der entscheidende Punkt ist: Die Wallet wird nicht mit einem Schlag alle Identitätsprobleme lösen. Aber sie wird sehr wahrscheinlich einzelne hoch relevante Prozessketten verändern, in denen heute viel Reibung steckt. Wer diese Ketten mit echten Testfällen gegen Referenzkomponenten und Pilotmuster prüft, wird beim Markthochlauf deutlich schneller und sauberer integrieren können.

Fazit

Die EUDI Wallet ist für Unternehmen 2026 vor allem ein Vorbereitungs- und Architekturthema. Nicht jedes Portal muss sofort wallet-fähig werden. Aber jede Organisation mit digitalem Onboarding, regulierten Nachweispflichten, grenzüberschreitenden Services oder organisationsbezogenen Identitäten sollte jetzt prüfen, wo die Wallet echte Vereinfachung bringen kann. Der beste Start ist kein hektischer Frontend-Prototyp, sondern saubere Vorarbeit bei Prozessen, Attributlogik, Vertrauenssteuerung, Supportmodell und Interoperabilitätstests. Wer das jetzt angeht, wird die Wallet später als geordneten Betriebsbaustein einführen, nicht als nächstes Sonderprojekt unter Zeitdruck.

Quellen

• European Commission: European Digital Identity (EUDI) Regulation
• European Commission: EU Digital Identity Wallet Toolbox process
• European Commission: EU Digital Identity Wallet Pilot implementation
• European Commission: eIDAS Regulation
• GitHub: EU Digital Identity Wallet Architecture and Reference Framework