Portale mit EUDI Wallet brauchen ein Betriebsmodell für Attribute, Fehlerfälle und Nachweise

Die EU Digital Identity Wallet, kurz EUDI Wallet, ist kein kosmetisches Login-Upgrade, sondern ein neuer Rahmen für digitale Identitäten, Nachweise und vertrauenswürdige Online-Transaktionen in Europa. Seit der europäischen Digital-Identity-Regelung von 2024 steht fest: Jeder Mitgliedstaat muss mindestens eine Wallet bereitstellen, die Bürger, Einwohner und auch Unternehmen für digitale Dienste nutzen können. Relevant wird das nicht erst im Rechtsbereich, sondern direkt im Betrieb von Portalen, Self-Services, Onboarding-Strecken und Supportprozessen.

Die neueren Durchführungsrechtsakte der EU verschieben den Fokus nun sichtbar von der Vision zur Umsetzung. Die Kommission hat weitere Regeln für Registrierung und Zertifizierung von Wallets sowie von sogenannten Relying Parties verabschiedet. Parallel legt die Durchführungsverordnung (EU) 2026/798 Referenzstandards für das Remote-Onboarding von Wallet-Nutzern fest. Zusammen mit Vorgaben zu Protokollen, Schnittstellen und dem Lebenszyklus elektronischer Attribute entsteht damit ein Bild, das für IT-Service-Organisationen sehr klar ist: Wer Wallet-fähige Portale betreiben will, braucht mehr als einen zusätzlichen Button im Frontend.

Aus dem Identitätsprojekt wird eine Betriebsaufgabe

Viele Organisationen lesen die EUDI Wallet noch immer primär als Thema für IAM-Architekten oder für ein späteres Digitalprodukt-Projekt. Das greift zu kurz. Portale, die künftig Wallet-Nachweise anfordern oder akzeptieren, bewegen sich in einem geregelten Ökosystem aus Wallets, ausstellenden Stellen, elektronischen Attributnachweisen, nationalen Registern und vertrauenden Diensten. Genau diese Rollen erzeugen im Alltag neue Fragen: Wer fordert welches Attribut an? Wer begründet die fachliche Erforderlichkeit? Wer verantwortet Fehlerbilder zwischen Wallet, Vertrauensdienst, Fachverfahren und Benutzeroberfläche? Und wer entscheidet, welcher Fallback im Störfall zulässig ist?

In klassischen Portalprojekten landen diese Fragen oft zu spät auf dem Tisch. Zuerst wird die Nutzerreise entworfen, dann die technische Integration diskutiert, und Support, Nachweisprüfung oder Widerrufslagen folgen irgendwann vor dem Go-live. Bei der Wallet ist diese Reihenfolge riskant. Denn die europäische Logik setzt gerade darauf, dass Nachweise vertrauenswürdig, selektiv und interoperabel genutzt werden. Wenn ein Fachverfahren intern weiterhin Vollabfragen, manuelle Dokumentenprüfungen oder unscharfe Rollenmodelle erzwingt, wird aus der Wallet schnell nur ein weiteres Integrationsstück ohne echten Betriebsvorteil.

Relying Parties brauchen Governance, nicht nur Registrierung

Besonders wichtig ist der Blick auf die Rolle der Relying Party, also des Dienstes, der Informationen aus einer Wallet anfordert und verarbeitet. Die EU hat hierzu inzwischen eigene Umsetzungsregeln verabschiedet. Das ist keine Nebensache. Sobald Portale sich in diese Logik einfügen, reicht es organisatorisch nicht mehr, wenn ein Produktteam einfach entscheidet, welche Daten es gern sehen würde. Die Anforderung von Attributen muss fachlich sauber begründet, datensparsam gestaltet und technisch nachvollziehbar umgesetzt werden.

Genau hier entsteht für IT-Management und Service-Governance eine neue Mindestdisziplin. Ein Portal braucht künftig idealerweise einen klaren Katalog, welche Attribute für welchen Prozessschritt zulässig und notwendig sind. Dazu gehört auch die Frage, auf welcher Rechts- oder Geschäftsgrundlage diese Daten wirklich gebraucht werden. Wer diese Entscheidungen nur implizit in Frontend-Formulare oder Backendlogik einbaut, handelt sich später Audit-, Datenschutz- und Supportprobleme ein. Denn dann wird im Incident-Fall niemand schnell beantworten können, ob ein Prozessfehler, ein Attributproblem oder eine falsche fachliche Anforderung vorliegt.

Ein reifes Betriebsmodell trennt deshalb zwischen drei Ebenen: der Authentisierung einer Person, dem Nachweis einzelner Attribute und dem Fachentscheid, was mit diesen Informationen im Prozess geschehen darf. Diese Trennung wirkt unspektakulär, verhindert aber viele typische Fehler. Ein Onboarding-Prozess braucht vielleicht gar keine vollständige Identitätskopie, sondern nur einen Altersnachweis oder eine verifizierte Organisationsrolle. Ein anderer Schritt braucht eine starke Identifikation, aber keine dauerhafte Speicherung sensibler Zusatzdaten. Genau solche Unterschiede müssen Portalteams vor dem Go-live festziehen.

Remote-Onboarding verändert Support und Fehleranalyse

Die Durchführungsverordnung (EU) 2026/798 zeigt zusätzlich, dass die Wallet nicht nur am Moment der Nutzung hängt, sondern schon am Onboarding. Dort werden Referenzstandards und Verfahren für die ferngestützte Aufnahme von Wallet-Nutzern in Verbindung mit elektronischen Identifizierungsmitteln definiert. Für Service-Teams ist das hoch relevant, weil damit neue Fehlerklassen entstehen, die weder klassischer Anmeldefehler noch einfacher Formularabbruch sind.

Wenn ein Nutzer seine Wallet nicht erfolgreich initialisieren kann, ein Identifizierungsmittel nicht das geforderte Vertrauensniveau erreicht oder ein Attribut nicht rechtzeitig bereitgestellt wird, landet die Friktion sehr schnell im Support. Viele Service Desks sind für solche Ketten heute noch nicht vorbereitet. Sie sehen im Ticket vielleicht nur: „Login geht nicht“ oder „Nachweis wird abgelehnt“. Die eigentliche Ursache kann aber an ganz anderer Stelle liegen: bei einem ausstellenden Vertrauensdienst, bei einem abgelaufenen Attribut, bei fehlerhafter Zuordnung im Fachverfahren oder bei zu strengen Anforderungsregeln des Portals.

Deshalb brauchen Wallet-fähige Services früh ein Incident- und Supportmodell, das diese Kette abbildet. Sinnvoll sind eigene Fehlerkategorien, sichtbare Zuständigkeiten zwischen Produktteam, IAM, Fachverfahren, Datenschutz und externen Dienstparteien sowie klare Diagnosehilfen für den First Level. Wer diese Vorarbeit auslässt, verwandelt die Wallet im Betrieb schnell in ein Black-Box-Thema, bei dem Supportteams nur Tickets weiterreichen.

Attribute und Nachweise müssen fachlich präzise bestellt werden

Der eigentliche Mehrwert der Wallet liegt nicht darin, möglichst viele Identitätsdaten auf einmal einzusammeln. Er liegt darin, selektiv genau die Informationen anzufordern, die ein digitaler Prozess wirklich braucht. Die europäischen Unterlagen betonen diese Logik ausdrücklich: Nutzer sollen Kontrolle über ihre Daten behalten, unnötige Offenlegung vermeiden und interoperable Nachweise einsetzen können. Für Portalbetreiber klingt das selbstverständlich, zwingt aber viele bestehende Prozesse zu unbequemen Fragen.

Welche Nachweise werden heute nur deshalb vollständig hochgeladen, weil der Prozess keine feinere Fachlogik kennt? Wo wird Identität mit Berechtigung verwechselt? Welche Organisations- oder Rolleninformationen sind für einen B2B- oder Behördenprozess tatsächlich erforderlich? Und welche Nachweise müssen widerrufen, erneuert oder zeitlich begrenzt berücksichtigt werden?

Genau an dieser Stelle entscheidet sich, ob die Wallet zu weniger Reibung führt oder nur alte Übererhebung digitalisiert. Ein gutes Betriebsmodell beschreibt deshalb nicht bloß API-Aufrufe, sondern auch Attributpolitik: minimale Datennutzung, fachliche Begründung, Lebenszyklus von Nachweisen, Regeln für Widerruf und saubere Protokollierung. Erst damit wird aus einer Wallet-Integration ein belastbarer Servicebaustein.

Fachverfahren, Monitoring und Fallbacks gehören von Anfang an dazu

Wallet-Projekte scheitern selten an der Demo, sondern an den Übergängen. Ein Portal kann eine Wallet technisch korrekt ansprechen und trotzdem unbrauchbar sein, wenn das Fachverfahren dahinter Attribute nicht nachvollziehbar verarbeitet, wenn Monitoring nur den Frontend-Erfolg misst oder wenn Fallbacks ungeregelt bleiben. Gerade in regulierten oder öffentlichen Szenarien darf ein Fallback zwar nötig sein, aber er muss definiert, begrenzt und auswertbar sein.

Praktisch heißt das: Portal- und Service-Teams sollten vor dem Livegang festlegen, welche Störfälle auftreten können, welche Alternativwege erlaubt sind und wann ein manueller Prozess nur als Ausnahme gelten darf. Ebenso wichtig ist Beobachtbarkeit. Teams müssen sehen können, an welchem Schritt Nutzer abbrechen, wie oft Nachweise zurückgewiesen werden, welche Attribute überproportional Probleme verursachen und ob Fehler eher im Onboarding, in der Vertrauenskette oder im Fachverfahren entstehen. Ohne diese Sicht wird die Wallet nicht steuerbar, sondern nur ein weiterer externer Abhängigkeitspunkt.

Worauf Portal- und ITSM-Teams jetzt konkret achten sollten

• Prozessschritte mit Identitäts- und Attributbedarf inventarisieren: Nicht jeder Schritt braucht dieselbe Nachweistiefe.
• Eine Attribut- und Nachweispolitik definieren: Welche Daten sind minimal erforderlich, wer genehmigt Ausnahmen, wie werden Widerruf und Ablauf behandelt?
• Relying-Party-Governance verankern: Registrierung, Freigabe und Dokumentation dürfen kein stilles Nebenthema einzelner Produktteams bleiben.
• Supportpfade für Wallet-Fehlerbilder aufbauen: First Level, IAM, Fachverfahren und externe Trust-Komponenten brauchen klare Eskalationsgrenzen.
• Monitoring auf Prozesskette statt nur Login-Erfolg ausrichten: Relevant sind Attributannahme, Ablehnung, Abbrüche und Fallback-Nutzung.
• Fachverfahren früh testen: Eine Wallet nützt wenig, wenn dahinter weiter PDF- oder Sonderlogik dominiert.

Fazit

Mit der EUDI Wallet entsteht für Portale keine isolierte Identitätsfunktion, sondern eine neue Betriebsdisziplin an der Schnittstelle von Authentisierung, Attributnachweisen, Governance und Support. Je konkreter die EU-Regeln für Registrierung, Interoperabilität und Remote-Onboarding werden, desto weniger tragfähig ist die Vorstellung vom schnellen Frontend-Add-on.

Organisationen, die jetzt Attributlogik, Relying-Party-Governance, Fehlerpfade und Fachverfahrensintegration gemeinsam planen, verschaffen sich einen echten Startvorteil. Sie bauen Wallet-Fähigkeit dann nicht als Sonderfall ein, sondern als belastbaren Serviceprozess. Genau das entscheidet am Ende darüber, ob Nutzer weniger Reibung erleben oder nur eine neue Fehlermeldung.

Quellen

• European Commission: EU Digital Identity Wallet Home
• European Commission: The European Digital Identity Regulation
• European Commission: New round of EU Digital Identity Wallet implementing regulations
• European Commission: The legal and technical road to EU Digital Identity Wallets
• EUR-Lex: Commission Implementing Regulation (EU) 2026/798