Zurück zum Blog

EUDI Wallet für Softwareunternehmen: Integration statt Login-Feature

ComplianceSoftware ArchitectureBackend DevelopmentPrivacy

Die EUDI Wallet wird Ende 2026 für Softwareunternehmen praktisch relevant. EU-Mitgliedstaaten müssen digitale Wallets bereitstellen, mit denen Menschen Identitätsdaten und Nachweise kontrolliert vorzeigen können. Für Produktverantwortliche ist das kein weiteres Login-Feature, sondern eine neue Schnittstelle zwischen Identität, Datenschutz und Geschäftsprozess.

Was die EUDI Wallet technisch verändert

Die EUDI Wallet folgt nicht dem üblichen Modell eines zentralen Identity Providers. Nutzer erhalten digital signierte Person Identification Data (PID) und elektronische Attributnachweise von vertrauenswürdigen Ausstellern. Sie speichern diese in ihrer Wallet und präsentieren ausgewählte Daten an einen Relying Party, etwa einen Online-Dienst.

Damit verlagert sich Verantwortung in das Backend. Der Dienst muss nicht nur eine Session eröffnen, sondern Nachweise, Aussteller, Gültigkeit und Bindung an Nutzer oder Gerät prüfen. Das aktuelle Architecture and Reference Framework sieht dafür unter anderem OpenID4VP für entfernte Präsentationen sowie Formate wie SD-JWT VC vor.

Vier Architekturfragen werden dadurch geschäftskritisch:

  • Rolle: Ist das Unternehmen nur Relying Party oder stellt es selbst Nachweise aus?
  • Datenminimierung: Reicht die Bestätigung „über 18“, oder wird unnötig das vollständige Geburtsdatum angefordert?
  • Vertrauen: Welche Aussteller, Zertifikate, Statusinformationen und Widerrufe akzeptiert das Backend?
  • Kontenmodell: Wie wird ein Wallet-Nachweis mit bestehenden Kundenkonten verknüpft, ohne Duplikate oder Account-Takeover-Risiken zu erzeugen?

Wer die Wallet wie Social Login behandelt, unterschätzt Prüfpfade, Datenschutz und Fehlerfälle. Besonders bei KYC, Altersnachweisen, Berufsqualifikationen oder Vertretungsrechten entscheidet die Architektur darüber, ob ein Nachweis fachlich verwertbar ist.

Wie Teams die EUDI Wallet integrieren sollten

Ein sinnvoller Einstieg beginnt mit einem klar begrenzten Geschäftsprozess, nicht mit der Auswahl eines Wallet-SDKs. Teams sollten zuerst festlegen, welche Entscheidung der digitale Nachweis ermöglicht und welche Daten dafür tatsächlich erforderlich sind.

  • Use Case eingrenzen: Einen Prozess wie Altersprüfung, Kunden-Onboarding oder Qualifikationsnachweis auswählen.
  • Attributanfrage modellieren: Zweck, erforderliche Attribute, Aufbewahrung und Löschung dokumentieren.
  • Verifikation kapseln: Protokolle, Signaturprüfung und Vertrauenslisten hinter einem eigenen Backend-Service isolieren.
  • Betrieb vorbereiten: Fallbacks, Audit-Logs, Widerruf, Support und Tests mit mehreren Wallet-Implementierungen einplanen.

Zusätzlich muss das Unternehmen seine Rolle als Relying Party organisatorisch klären. Dazu gehören Registrierung, Verantwortlichkeit für Attributanfragen und ein Prozess für Änderungen am Vertrauensmodell. Diese Aufgaben gehören in Produkt-, Security- und Compliance-Roadmaps, nicht allein in ein Authentifizierungs-Ticket.

Technisch lohnt sich eine entkoppelte Integrationsschicht. Wenn Fachlogik direkt von einem Credential-Format oder Wallet-Anbieter abhängt, wird jede Änderung am europäischen Rahmenwerk teuer. Eine stabile interne API kann stattdessen fachliche Aussagen wie „Identität geprüft“ oder „Volljährigkeit bestätigt“ liefern.

Warum das wichtig ist

Die EUDI Wallet kann Onboarding, Identitätsprüfung und grenzüberschreitende Prozesse vereinfachen. Der wirtschaftliche Nutzen entsteht aber nur, wenn Unternehmen weniger manuelle Prüfungen, Medienbrüche und wiederholte Datenerhebung haben. Eine schlecht integrierte Wallet fügt dagegen einen weiteren komplexen Kanal hinzu.

Für wachsende Softwareunternehmen ist der richtige Zeitpunkt zur Vorbereitung vor einer konkreten Akzeptanzpflicht oder Kundenanforderung. Dann lassen sich Kontenmodell, Datenschutz und Backend-Grenzen geplant anpassen, statt unter regulatorischem Zeitdruck.

Die zentrale Entscheidung lautet deshalb nicht, ob ein Login-Button eingebaut wird. Sie lautet, welche verifizierten Aussagen das Produkt benötigt, wie wenig Daten dafür genügen und wie diese Aussagen über Jahre zuverlässig geprüft werden.