EUDI-wallet en uw klantportaal: wat regelt u nu?
De EUDI-wallet komt eind 2026 beschikbaar. Wat betekent dat voor uw klantportaal, zakelijke bevoegdheden en leveranciers?
Bram SuurdCo-founder / DeveloperDe EUDI-wallet komt eraan, maar dat betekent niet dat ieder klantportaal dit jaar een nieuwe inlogknop nodig heeft. Voor veel mkb-bedrijven is de nuttigste stap minder spectaculair: vastleggen waar een processtap echt een identiteit, bevoegdheid of controleerbaar bewijs nodig heeft.
Dat voorkomt twee dure missers. U bouwt niet te vroeg aan een koppeling die niet aansluit op de Nederlandse praktijk. En u merkt niet pas bij een kritieke klantreis dat uw portal, identityprovider of autorisatiemodel een gat heeft.
Wat komt er eind 2026 beschikbaar?
De European Digital Identity Wallet, meestal EUDI-wallet genoemd, hoort bij de gewijzigde eIDAS-verordening, ook wel eIDAS 2.0 genoemd. Lidstaten moeten uiterlijk eind 2026 ten minste één wallet beschikbaar stellen. Daarmee kunnen mensen zich digitaal identificeren en gerichte digitale verklaringen tonen, bijvoorbeeld dat zij boven een bepaalde leeftijd zijn of, als zo'n verklaring beschikbaar is, een adresgegeven.
Die deadline gaat over de beschikbaarheid van een wallet. Hij betekent niet dat alle Nederlandse gegevensbronnen, zakelijke bevoegdheden en klantportalen dan al op elkaar aansluiten. De komst van de wallet betekent ook niet dat DigiD, eHerkenning, bestaande single sign-on of multi-factor-authenticatie op één datum verdwijnen. Per klantreis moet u bepalen welke methode waarvoor nodig blijft en hoe die naast of met een wallet werkt.
Zie de wallet dus niet als een nieuw wachtwoord. Het idee is dat een gebruiker gericht een digitale verklaring kan tonen, zonder standaard een volledige kopie van zijn identiteit af te geven.
Wanneer is een EUDI-wallet relevant voor uw portaal?
Een gewone website of webshop hoeft niet automatisch walletacceptatie toe te voegen. Voor overheidsinstanties en voor sommige private dienstverleners kan onder eIDAS een acceptatieplicht gelden. Bij private partijen hangt dit onder meer samen met elektronische dienstverlening op afstand en een identificatie- of authenticatie-eis uit Europees, nationaal of contractueel recht. De gebruiker kiest vrijwillig voor de wallet.
Of en vanaf wanneer dit voor uw dienst geldt, vraagt toetsing aan de eIDAS-regels en de regels voor uw sector. Dit artikel is geen juridisch advies. Technisch kunt u wel nu al goed bepalen op welke momenten een fout duur is:
- een klant vraagt een account aan voor een financieel, zorg- of contractueel proces;
- iemand wijzigt namens een organisatie een bestelling, contract of betalingsgegeven;
- een leeftijds-, adres- of bevoegdheidscontrole vraagt nu veel handwerk;
- u moet later kunnen aantonen wie een digitale handeling heeft uitgevoerd.
Een nieuwsbriefaanmelding heeft deze zwaarte niet. Een portaal waarin iemand contractgegevens wijzigt of een order accordeert, mogelijk wel.
Identiteit is niet hetzelfde als bevoegdheid
Bij B2B-portalen gaat het vaak mis op een simpele vraag: weet u wie de persoon is, of weet u ook wat die persoon namens het bedrijf mag doen? Dat zijn verschillende dingen.
Iemand kan zich betrouwbaar identificeren en toch niet bevoegd zijn om een contract te tekenen, factuurgegevens te wijzigen of toegang aan collega's te geven. Leg daarom per kritieke actie vast wat u nodig heeft:
- identificatie van een natuurlijke persoon;
- authenticatie bij het inloggen;
- een rol of mandaat namens een organisatie;
- bewijs dat u later moet kunnen controleren;
- een elektronische handtekening met een passend juridisch niveau.
Deze functies zijn niet uitwisselbaar. Een walletpresentatie is bijvoorbeeld niet automatisch een gekwalificeerde elektronische handtekening. Bij een handtekening hangt het juridische niveau af van de ondertekenmethode, het certificaat en de betrokken vertrouwensdienstverlener. De walletpresentatie alleen bepaalt dat niet.
Maak eerst een lijst van kritieke processtappen
Voor de meeste mkb-bedrijven is een korte inventarisatie nu nuttiger dan direct een koppeling bouwen. Kies één klantreis met een duidelijk risico, bijvoorbeeld het wijzigen van bankgegevens of het tekenen namens een klant, en werk deze vijf punten uit.
- Noteer elke gevoelige stap: accountaanmaak, inloggen, wachtwoordherstel, MFA, onboarding, ondertekenen, rollenbeheer en handelen namens een organisatie.
- Bepaal welk minimum aan gegevens of bewijs u per stap nodig heeft. Misschien hoeft u alleen te weten dat iemand ouder is dan 18, een geverifieerd adres heeft of een bepaalde rol mag vervullen.
- Bepaal welk bewijs u van de actie nodig hebt, wie dat later moet kunnen beoordelen en op welke grond u het bewaart. Richt logging, toegangsrechten en bewaartermijnen daarop in.
- Beschrijf uw fallback. Wat gebeurt er als een klant geen wallet gebruikt, of als een relevante digitale verklaring nog niet beschikbaar is?
- Leg de uitkomst naast de mogelijkheden van uw portal- en identiteitsleveranciers.
In Europese technische profielen speelt OpenID4VP een rol bij het tonen van digitale verklaringen. Voor de meeste mkb-bedrijven is de relevante vraag niet hoe zij dat protocol zelf bouwen. Vraag liever of uw leverancier de toepasselijke EUDI-profielen aantoonbaar ondersteunt.
Vier leveranciersvragen die een bruikbaar antwoord opleveren
- Welke EUDI-profielen ondersteunt u, vanaf welke versie en datum? Is die ondersteuning al beschikbaar, gepland of alleen onderzocht?
- Welke gegevens ontvangen en bewaren wij bij een presentatie, en welke gegevens blijven uitsluitend in de wallet van de gebruiker?
- Welke Nederlandse registratie-, vertrouwens- of aansluitstappen verwacht u van ons als ontvangende dienstverlener?
- Welke fallback blijft beschikbaar voor klanten zonder wallet, en hoe houdt u die route even veilig?
Vraag ook hoe de leverancier de geldigheid controleert en, waar het gebruikte profiel dat ondersteunt, status- of intrekkingsinformatie verwerkt. Een bruikbaar antwoord noemt voorwaarden, planning en bekende beperkingen. Een algemene belofte dat een product "wallet-ready" is, vertelt u nog niets over uw klantreis.
Privacy blijft onderdeel van het ontwerp
De wallet kan helpen om alleen de informatie te vragen die nodig is. Hij geeft geen vrijbrief om meer klantdata te verzamelen. Als u alleen een leeftijdsgrens hoeft vast te stellen, toets dan of een volledige identiteitskopie noodzakelijk en proportioneel is. Soms vraagt wet- of regelgeving om meer gegevens. Leg die afweging per processtap vast.
Beschrijf ook het doel, de grondslag, wie binnen uw organisatie toegang heeft en hoe lang u gegevens bewaart. Dat werk is niet alleen relevant voor een walletkoppeling. Het maakt iedere koppeling met eHerkenning, een identityprovider of een ander bewijsmechanisme beter beheersbaar.
Wat u in de komende 90 dagen kunt doen
Heeft u vooral een informatieve site of een eenvoudige webshop? Volg de ontwikkelingen, maar bouw niet uit angst voor een deadline. Heeft u een klantportaal met gevoelige wijzigingen, zakelijke rollen of een gereguleerde dienst? Kies dan één processtap waarin identiteit, bevoegdheid of bewijs aantoonbaar nodig is. Breng die stap in kaart, bespreek de uitkomst met de proceseigenaar en laat uw technische leverancier concreet reageren.
Wilt u een bestaande klantreis laten toetsen? Begin met één processtap waarin identiteit, bevoegdheid of bewijs aantoonbaar nodig is.