POTENTIAL-Pilot: Endergebnisse, 6 Use Cases und 5 Lehren für jeden Verifier

Was POTENTIAL tatsächlich war

POTENTIAL war der größte der vier EU Large Scale Pilots zur European Digital Identity Wallet. Das Projekt lief von April 2023 bis September 2025, endete planmäßig und legte im November 2025 seine konsolidierten Endergebnisse vor. Die Zahlen sind für ein EU-Programm ungewöhnlich klar: 140 Organisationen, 19 EU-Mitgliedstaaten plus Ukraine, sechs Use Cases und ein einzelner Koordinator – Frankreichs nationale Agentur für digitale Identität. Projektkoordinator Florent Tournois prägte den Satz, der seither weiter gereist ist als der Rest des Berichts: gemeinsame Standards müssten "rigoros angewendet" werden (Biometric Update, 28. November 2025). Jeder Verifier, der einen 2027-Launch plant, sollte diesen Satz als Scope verstehen – und für den deutschen Markt heißt das: als Scope für den 2. Januar 2027.

Warum POTENTIAL mehr Gewicht hat als die anderen Piloten

Die vier Large-Scale Pilots – POTENTIAL, EWC, NOBID und DC4EU – waren nie gleichwertig. POTENTIAL war der größte nach Organisationszahl, der breiteste nach Use-Case-Abdeckung und der heterogenste nach Mitgliedstaaten-Beteiligung. Im Konsortium saßen unter anderem die deutsche Bundesdruckerei, die Deutsche Telekom, Frankreichs Idemia, Amadeus sowie eine lange Reihe nationaler Identity Provider, Banken, Telekommunikationsanbieter, Gesundheitsbehörden und Verwaltungseinrichtungen (POTENTIAL-Konsortium). Während EWC sich auf Reise und Zahlung konzentrierte und NOBID auf nordische Zahlungsflüsse, testete POTENTIAL bewusst das härtere Problem: Würde dieselbe Wallet, ausgestellt in einem Mitgliedstaat, sauber bei einem Verifier in einem anderen funktionieren – über sechs unzusammenhängende Geschäftsfelder hinweg, mit Implementierungen, die unabhängig voneinander von konkurrierenden Anbietern gebaut wurden.

Genau das ist die eigentliche Bedeutung des Piloten. Das Launch-Problem – eine nationale Wallet mit einem nationalen Verifier zum Reden zu bringen – ist vergleichsweise einfach, und viele Mitgliedstaaten haben es längst gelöst. Das harte Problem ist grenzüberschreitende, anbieterübergreifende, use-case-übergreifende Interoperabilität, und POTENTIAL war der einzige Pilot, der gezielt auf den Stellen aufgesetzt wurde, an denen das bricht. Die deutsche Beteiligung war dabei nicht nur Symbol: Bundesdruckerei und Telekom haben Befunde geliefert, die für jeden deutschen Verifier in den nächsten zwölf Monaten unmittelbar relevant werden.

Die sechs getesteten Use Cases

eGov – Online-Verwaltungsdienste. Bürgerinnen und Bürger meldeten sich grenzüberschreitend mit ihrer Wallet an nationalen E-Government-Portalen an: eine belgische Wallet an einem spanischen kommunalen Dienst, eine italienische an einem deutschen Bundesportal. Innerhalb gut abgestimmter bilateraler Paare lief der Flow sauber, an den Rändern produzierte er konsistente Fehler – insbesondere dort, wo nationale Vertrauensniveaus nicht eins zu eins auf das eIDAS-LoA-Modell abgebildet werden konnten. eGov ist der Use Case, den die meisten Verifier am ehesten verstehen, und POTENTIAL bestätigte, dass das das einfache Ende des Spektrums ist.

Bankkontoeröffnung. Remote-KYC gegen eine Wallet anstelle von Video-Ident oder Filialbesuch. Der technische Flow ist überschaubar; der regulatorische ist es nicht. POTENTIAL legte die immer noch ungelöste Spannung zwischen GwG-/AMLD-Anforderungen und Selective Disclosure offen: Banken wollen alles, die Wallet ist auf das Minimum ausgelegt, und die rechtliche Akzeptanz von attributbasiertem KYC unterscheidet sich je nach nationaler Aufsicht. Mehrere Pilotbanken berichteten, dass parallele Dokumenten-Upload-Strecken nötig blieben, um Compliance abzudecken, selbst wenn der Wallet-Flow technisch durchlief. Für deutsche Häuser unter BaFin-Aufsicht ist das die unmittelbar relevante Lehre.

SIM- und eSIM-Registrierung – Multi-Wallet bei der Deutschen Telekom. Der operativ interessanteste Zweig. Die Telekom testete SIM-Aktivierung parallel gegen mehrere Wallet-Implementierungen aus unterschiedlichen Mitgliedstaaten – exakt die Produktionsrealität, die ein deutscher Telco 2027 vorfinden wird. Die Befunde sind ernüchternd: Selbst innerhalb von POTENTIAL, wo jede Wallet gegen dieselbe Architekturreferenz gebaut wurde, wich das Verhalten auf Protokollebene weit genug ab, um in der Verifier-Codebasis pro Wallet konditionale Logik zu erfordern.

Mobile Driving Licence (mDL). Der Use Case mit dem reifsten internationalen Standard (ISO/IEC 18013-5) und – wenig überraschend – mit dem saubersten grenzüberschreitenden Verhalten. mDL-Implementierungen interoperierten vergleichsweise gut, besonders für die Offline-Flows nach ISO/IEC 18013-5. Schwieriger blieb die Online-Präsentation über OpenID4VP, wo das mdoc-over-OpenID4VP-Profil sich während des Piloten erst noch konsolidierte. Für deutsche Verkehrsbehörden und Versicherer bleibt der mDL aber der Use Case mit dem absehbarsten Reifegrad zum Launch.

Qualifizierte elektronische Signatur (QES). Wallet-vermittelte QES gegen ein remote QSCD, ausgerichtet an ETSI TS 119 475. Der kryptografische Flow funktionierte. Der rechtsbindende Flow legte nationale Varianz offen: wie unterschiedlich QTSPs die wallet-bestätigte Authentifizierung des Unterzeichnenden akzeptieren. QES ist für die meisten Verifier eher ein 2027-Problem als eines für 2026.

E-Rezept. Grenzüberschreitende Verschreibungen gegen Apotheken in einem anderen Mitgliedstaat. Der Attribut-Set im Gesundheitskontext ist sensibler als jeder andere im Pilot und prallt auf nationale Gesundheitsdaten-Regulierungen, die sich Harmonisierung widersetzen. Technisch tragfähig, rechtlich eingehegt, und abhängig von der Parallelarbeit im European Health Data Space – nicht vom Wallet-Stack allein. Für die deutsche eRP-Strecke heißt das, dass der Wallet-Anschluss eher Anfang 2028 als Anfang 2027 produktionsreif sein wird.

Quer über die sechs Use Cases zeigt sich dasselbe Muster: Die technische Schicht reift schneller als die rechtliche und operative Schicht um sie herum. Verifier, die einen 2027-Launch scopen, sollten das regulatorische Mapping als parallelen Workstream zur Integration einplanen – nicht als Sign-off danach. Für den deutschen Markt verschärft sich dieser Punkt zusätzlich, weil der ARS-Plan und die nationale Wallet-Roadmap die operativen Vorlauffristen ohnehin eng halten. Wer erst nach Abschluss der Integration die juristische Abnahme aufsetzt, riskiert in Q4 2026 genau die Rückwürfe, die in POTENTIAL die langsamen Verifier identifizierbar gemacht haben.

Lehre 1 – Standards sind nicht optional

Tournois sagte nicht, Standards seien wichtig. Er sagte, sie müssten "rigoros" angewendet werden. Diese Unterscheidung trägt. In POTENTIAL waren die dominanten Interop-Fehler nicht fehlende Standards – das OpenID4VP-Profil, ISO/IEC 18013-5, ETSI TS 119 475 und das EU Architecture and Reference Framework existierten alle vor Pilotbeginn. Die Fehler entstanden aus Implementierungen, die die Standards locker gelesen haben – und aus Verifier-Codebasen, die noch lockerer dagegen integriert haben.

Welche konkreten Divergenzen ein Verifier bei der Integration mehrerer Wallets einplanen sollte, ist im anbieterübergreifenden Wallet-Engineering hinlänglich bekannt: OpenID4VP-Request-Profile, bei denen eine Wallet client_id_scheme=x509_san_dns erwartet und eine andere redirect_uri; mdoc-Encoding-Edge-Cases rund um CBOR-Kanonisierung, die in einer Bibliothek funktionieren und in einer anderen scheitern; Presentation-Definition-Strukturen, die ein Verifier als JSON-Schema akzeptiert, während ein anderer sie als nicht Presentation-Exchange-2.0-konform ablehnt; unterschiedliche Salt-Behandlung in Selective-Disclosure-Implementierungen über SD-JWT-VC. Die öffentliche POTENTIAL-Zusammenfassung listet diese nicht Punkt für Punkt auf, doch genau auf diese Fehlerklasse zielt Tournois' "rigoros" – und genau diese Art von Bruch erleben Verifier-Teams, die 2026 gegen mehr als eine Wallet testen.

Für einen Verifier übersetzt sich "rigoros" direkt in Engineering-Praxis. Es bedeutet, gegen den spezifischen OpenID4VP-Profil-Draft zu pinnen, den die eigenen Wallets ansteuern – nicht gegen "OpenID4VP" im Allgemeinen. Es bedeutet, vor Launch gegen mehrere Wallet-Implementierungen zu testen, nicht gegen eine. Es bedeutet, die Conformance Suite der OpenID Foundation als Baseline zu behandeln, nicht als Meilenstein. Und es bedeutet, das EU Reference Framework als bindenden Scope zu lesen, nicht als Anregung. Wer diesen Schritt zum Launch überspringt, erbt im Produktivbetrieb dieselben Divergenzen, die POТЕNTIAL in Testumgebungen sichtbar gemacht hat.

Lehre 2 – Cross-Border-Interop ist das ungelöste Problem

Das ist die Lehre, die 2027-Launches am direktesten bedroht. Selbst innerhalb von POTENTIAL – einem koordinierten Programm mit gemeinsamen Architekturdokumenten, gemeinsamer Testinfrastruktur und gemeinsamer Finanzierung – haben mehrere Wallets out of the box nicht sauber mit mehreren Verifiern interoperiert. Paare funktionierten. Die volle N-mal-M-Matrix nicht.

Die Konsequenz für grenzüberschreitende Händler und Diensteanbieter im Jahr 2027 ist unangenehm. Die eIDAS-2-Verordnung gibt EU-Bürgerinnen und -Bürgern das Recht, ihre Wallet bei einem Verifier in jedem Mitgliedstaat einzusetzen. Die technische Realität – nach POTENTIAL-Befunden – ist, dass universelle Akzeptanz in den ersten 12 bis 18 Monaten nach Start lückenhaft sein wird. Manche Wallet-Verifier-Paare werden ab dem 2. Januar 2027 stabil sein. Andere werden konditionale Behandlung auf Verifier-Seite erfordern, anbieterspezifische Eigenheiten oder temporäre Fallback-Strecken.

Verifier, die grenzüberschreitenden Verkehr bedienen wollen, sollten "EUDI-Wallet-Unterstützung" nicht als eine einzelne Fähigkeit annehmen. Genauer plant man "EUDI-Wallet-Unterstützung pro Issuer-Cluster" – mit einem getesteten Set nationaler Wallets zum Launch und einer expliziten Roadmap für die Erweiterung, sobald weitere Implementierungen stabilisieren. Konkret heißt das: intern und gegenüber dem Support dokumentieren, welche nationalen Wallets getestet-und-funktional sind, welche getestet-und-eingeschränkt und welche noch nicht getestet. Wer dieses Staging überspringt, übernimmt die Interop-Bug-Reports und die Support-Tickets, die ihnen folgen.

Für deutsche Verifier ist die priorisierbare Teilmenge nicht zufällig: die deutsche Wallet selbst, die niederländische, die österreichische, die belgische und die französische Implementierung dürften die häufigsten Tárcaprofile an deutschen Kassen und Online-Strecken sein. Diese fünf zum Launch sauber zu unterstützen ist ein deutlich realistischeres Versprechen als „alle 27" – und es ist auch genau die Kohorte, die intern am ehesten testbar ist, weil POTENTIAL-Befunde dafür bereits Hinweise liefern.

Lehre 3 – Attribut-Scoping zahlt sich aus

Selective Disclosure ist das Wallet-Feature, das den Realitätskontakt am besten überstanden hat. Über alle sechs Use Cases hinweg meldeten POTENTIAL-Verifier, die nur die für die Transaktion notwendigen Mindestattribute anforderten, glattere User-Flows, schnelleres Consent und niedrigere Drop-off-Raten. Verifier, die mehr verlangten – das volle Identitäts-Bundle, wenn nur das Alter relevant war, oder die Adresse, wenn nur das Wohnsitzland zählte – produzierten sichtbare Reibung in der Nutzererfahrung.

Im Pilot zeigt sich diese Reibung als reduzierter Abschluss. Im Produktivbetrieb, nach Launch 2027, wird dieselbe Über-Anforderung etwas Teureres produzieren: regulatorische Aufmerksamkeit. Sowohl der eIDAS-2-Rahmen als auch das Datenminimierungsprinzip der DSGVO binden Verifier daran, das kleinste Attribut-Set anzufordern, das den Use Case bedient. Nationale Datenschutzaufsichten – von der BfDI bis zu den Landesdatenschutzbehörden – werden den Wallet-Flow mit dieser Linse prüfen, und die über-anfordernden Verifier werden die einfachsten Ziele sein. Erste DSK-Stellungnahmen zur Wallet-Nutzung lassen sich bereits in diese Richtung lesen, und ein Verifier, der bei Launch erkennbar zu viel verlangt, liefert dem nächsten Tätigkeitsbericht der zuständigen Aufsicht das Material praktisch frei Haus.

Die praktische Konsequenz ist, Attribut-Scoping vom ersten Tag an in den Verifier-Entwurf zu bauen. Pro Flow dokumentieren, welche Attribute strikt notwendig sind; das als produktive Presentation Request ausliefern; und der Engineering-Versuchung widerstehen, "alles zu fragen, falls wir es später brauchen". Die POTENTIAL-Daten bestätigen, dass minimum-attribut-Flows besser konvertieren. Compliance-Argument und Conversion-Argument zeigen in dieselbe Richtung – und ein nachvollziehbares Scoping-Dokument pro Use Case ist außerdem die einfachste Verteidigungslinie gegenüber einer Aufsichtsanfrage, die nach Launch ohnehin kommen wird.

Lehre 4 – Age-only-Flows sind der einfachste Weg zu frühem ROI

Verborgen in den Use-Case-Ergebnissen findet sich ein Befund, der getrennt herausgezogen gehört. Über alle sechs Use Cases hinweg waren die Attributkombinationen, die anbieter- und verifierübergreifend am konsistentesten funktionierten, die einfachsten – und am konsistentesten von allen war das Alter. Alter über 18, Alter über 21, Altersbereich: Diese Flows haben die Implementierungsvielfalt zuverlässiger überstanden als volle Identität, als Name-und-Adresse, als QES.

Der Grund ist strukturell. Altersattribute haben die kürzeste Spezifikationsfläche, den kleinsten Selective-Disclosure-Scope und die längste Standardisierungsgeschichte (ISO/IEC 18013-5 trägt mDL-Altersattribute seit Jahren). Wallet-Anbieter haben sie zuerst implementiert und am intensivsten getestet. Verifier haben sie mit den wenigsten Edge-Cases verdrahtet.

Für deutsche Verifier, die einen 2027-Launch planen, ergibt sich daraus eine klare Sequenzierungsstrategie. Zuerst Alterprüfung integrieren – Alkohol, Tabak, Glücksspiel, Jugendschutz nach JuSchG, regulierte Marktplätze – und erst dann auf volle Identitätsflüsse erweitern, sobald das Wallet-Ökosystem reift. Verifier, die in dieser Reihenfolge sequenzieren, sehen echten ROI in Q1 und Q2 2027. Verifier, die direkt auf vollständiges Identity Onboarding zielen, verbringen dieselben Monate mit Debugging.

Das ist kein strategischer Kompromiss. Age-only-Flows sind ein substantieller, wachsender Markt für sich – und das Launch-Ökosystem ist real besser darauf vorbereitet, sie zu liefern. Es ist nebenbei der risikoärmste Weg, produktive Betriebserfahrung zu sammeln, bevor Scope erweitert wird. Für den deutschen Markt kommt hinzu, dass JuSchG-relevante Flows in den nächsten zwölf Monaten ohnehin Hauptthema von KJM und Landesmedienanstalten bleiben werden; ein wallet-basierter Altersnachweis, der ab Januar 2027 wirklich produktionsreif funktioniert, ist gleichzeitig Compliance-Argument und Wettbewerbsvorteil gegenüber bestehenden Schwarmverfahren.

Lehre 5 – Fallback-Design trennt Produktiv-Reife von Pilot-Reife

POTENTIALs klarster organisatorischer Befund ist der, der am leichtesten überhört wird. Über alle sechs Use Cases hinweg überlebten Verifier mit sauberen Nicht-Wallet-Fallbacks die Edge Cases – verlorene Geräte, abgelaufene Credentials, grenzüberschreitende Inhaber, Nutzer, die mittendrin aufgaben. Verifier ohne solche Fallbacks fielen bei Wallet-Fehlern in manuelle Prozesse zurück.

"Manueller Prozess" ist im Pilot-Sprech ein höflicher Begriff für eine Service-Hotline-Warteschlange, einen Filialtermin oder ein Support-Ticket. Keines davon skaliert auf produktive Volumina, und alle verschieben die Kosten eines fehlenden Fallback-Pfads still ins Operations-Budget. Verifier, die Fallback als erstklassigen Produktionspfad behandelten – ihn entwarfen, instrumentierten und Support darauf trainierten – hielten ihre Flows durch Pilot-Edge-Cases nutzbar. Diejenigen, die Fallback als nachträgliches Gerüst aufgesetzt haben, blieben an den Edge Cases stehen.

Die Lehre für Deutschland zum 2. Januar 2027 ist direkt. Ein wallet-only Flow zum Launch ist ein selbstverschuldetes Reliability-Problem. Jede Wallet-Integration sollte mit mindestens einem expliziten Nicht-Wallet-Pfad ausgeliefert werden: das vorhandene nationale eID-Verfahren (in Deutschland die Online-Ausweisfunktion des Personalausweises mit AusweisApp), eine Dokumenten-Upload-Strecke für Nicht-Residenten und Edge Cases, ein In-Filiale-Pfad, wo das Geschäftsmodell ihn trägt. Der Fallback ist kein temporäres Gerüst, das man 2028 entfernt. Er ist Teil des Produktivdesigns – und nach POTENTIAL-Evidenz das, was Verifier, die durch Q1 2027 geschmeidig laufen, von denen trennt, die es nicht tun.

Hilfreich ist hier, Fallback-Anteile bewusst zu instrumentieren. Wer monatlich misst, welcher Anteil der Verifikationen über die Wallet-Strecke, welcher über nPA und welcher über Dokumenten-Upload läuft, sieht früh, ob der Wallet-Anteil gegen die Erwartung steigt – oder ob bestimmte Wallet-Cluster strukturell auf Fallback umlenken. Das ist die Steuerungsgröße, die im Operations-Reporting 2027 fehlen wird, wenn man sie nicht von Anfang an mitführt.

Unterm Strich

POTENTIAL ist das, was die EU einem produktiven Smoke Test der EUDI Wallet am nächsten gekommen ist. Zweieinhalb Jahre Laufzeit, 140 Organisationen aus 19 Ländern, sechs unzusammenhängende Use Cases – mit Befunden, die vorliegen, bevor die regulatorischen Fristen bindend werden. Wer diese Befunde liest, sollte sie als Readiness-Checkliste behandeln, nicht als akademische Literatur. Standards-Rigorosität, Multi-Wallet-Interop-Tests, Attributminimierung, Age-First-Sequenzierung, Fallback-Pfade – das sind die fünf konkreten Verpflichtungen, gegen die jeder Verifier sein Backlog heute auditieren kann. Was davon vor Q3 2026 nicht ehrlich abgehakt werden kann, ist ein Ship-Blocker für 2027.

Für deutsche Verifier kommt eine pragmatische Schlussbemerkung dazu. Die deutsche Beteiligung in POTENTIAL – Bundesdruckerei und Telekom – war kein Marketingvehikel, sondern operative Vorarbeit. Die Erkenntnisse aus diesen beiden Strängen lassen sich in den 2027-Plänen deutscher Banken, Händler und regulierter Plattformen unmittelbar einsetzen, ohne Übersetzung. Wer jetzt nicht zugreift, bezahlt im ersten Quartal 2027 dafür, dass jemand anders es schon getan hat. Der Pilot ist vorbei. Die Fristen nicht.