De afgelopen maanden zie ik één onderwerp steeds vaker terugkomen in gesprekken, beleidsstukken en technische documentatie: de digitale identiteitswallet.
Niet als een “ooit misschien”-idee, maar als een concrete verplichting vanuit Europese regelgeving. Vanaf eind 2026 moeten overheden een wallet accepteren. Een jaar later volgt een reeks private partijen in gereguleerde sectoren.
Op papier klinkt dat als een nette technologische upgrade. In de praktijk is het een fundamentele verschuiving in hoe we omgaan met identiteit, verificatie en datadeling. En dat raakt veel meer organisaties dan alleen overheid en banken. Denk aan grote dienstverleners, verzekeraars, zorgaanbieders en intermediaire ketens.
In deze blog deel ik mijn belangrijkste inzichten tot nu toe: welke risico’s zie ik, welke kansen, en welke technische keuzes gaan de komende jaren het verschil maken?
Waar draait die wallet eigenlijk om?
De kern van de Europese digitale identiteitswallet (EUDI) is verrassend simpel:
een app waarin burgers zelf digitale identiteitsgegevens, documenten en attesteringen beheren, en alleen delen wat nodig is.
Dataminimalisatie wordt daarmee de standaard. Een paar voorbeelden:
- Moet je aantonen dat je 18+ bent? Dan verstuurt de wallet niet je geboortedatum, maar alleen het feit dat je meerderjarig bent.
- Moet je inkomen bevestigd worden? Dan gaat niet je complete jaaroverzicht mee, maar een geverifieerde attestering.
In theorie is dit fantastisch. In de praktijk komt er een flinke technische én organisatorische puzzel bij kijken. En die puzzel wordt vaak onderschat.
De risico’s die we niet moeten wegwuiven
1. Wetgeving die nog in beweging is
Hoewel de verplichtingen duidelijk zijn, is de technische uitwerking (implementing acts) en nationale invulling nog volop in ontwikkeling.
Als je nu te specifiek bouwt, is de kans groot dat je straks mag refactoren. Niet omdat je slecht gebouwd hebt, maar omdat de wereld onder je voeten is verschoven.
De les: ontwerp configurabel, niet rigide.
2. Vertrouwen op trustlists — en de gevolgen daarvan
Wallets, issuers en verificatiediensten worden gevalideerd via nationale en Europese vertrouwenslijsten (trustlists).
Dat betekent dat één van deze dingen meteen impact kan hebben op je verificatieketen:
- een verlopen certificaat
- een fout in een trustlist-update
- een issuer die wordt teruggetrokken
Als je wallet-verificatie in je kritische klantproces hangt, dan is real-time monitoring geen nice-to-have, maar pure noodzaak.
3. Auditverplichtingen worden ineens serieus ingewikkeld
Wallet-verificaties kunnen juridisch bewijs vormen. Dat betekent hogere eisen aan logging en herleidbaarheid.
Niet alleen “wat is geverifieerd”, maar ook:
- via welke issuer
- onder welke trust anchor
- op welk moment
Auditlogging wordt dus geen technisch bijproduct, maar onderdeel van je compliance-ontwerp.
4. Inclusie en toegankelijkheid
Een wallet kan voor minder digivaardige mensen eerder een drempel worden dan een versnelling.
Organisaties die zwaar op wallet-verificatie gaan leunen, moeten dus altijd fallback-kanalen bieden. Anders maak je je processen “modern”, maar je klantreis vooral onnodig frustrerend.
5. De onzichtbare kosten
Er ontstaat een kostenmodel rondom verificaties. Niet schokkend per check, maar bij grote volumes wordt het snel relevant.
Denk aan:
- verificatiekosten per check
- software-aanpassingen
- governance en audit
- lifecycle-beheer van trustlists
- uitbreidingen op je IdP
Oftewel: dit vraagt om businesscases die verder gaan dan “IT regelt het wel”.
Maar: de kansen zijn minstens zo groot
1. Slimmere onboarding zonder dataverzamelwoede
Voor organisaties die afhankelijk zijn van identiteits- of inkomensverificatie kan onboarding veel sneller én betrouwbaarder worden.
Minder fouten. Minder fraude. Minder papierwerk. En vooral: minder onnodige persoonsgegevens in je systemen.
2. QES: digitaal tekenen zonder frictie
Wallets maken Qualified Electronic Signing (QES) veel toegankelijker.
Juridisch gelijkwaardig aan een fysieke handtekening, maar volledig digitaal. Dat is interessant voor processen die nu nog half analoog lopen “omdat het juridisch moet”.
3. Ketenintegratie wordt ineens realistischer
Als klanten hun geverifieerde informatie kunnen delen via een wallet, worden ketens uniformer en eenvoudiger.
Denk aan intermediairs, uitvoeringsorganisaties en ketenpartners: minder maatwerk, minder interpretatieverschillen, minder “wie heeft welke waarheid”.
4. Dataminimalisatie als concurrentievoordeel
Wallet-verificaties geven organisaties de kans om veel minder persoonsgegevens op te slaan.
Dat verkleint risico’s, helpt bij compliance en scheelt ook nog beheer- en opslagkosten.
Privacy by design wordt daarmee niet alleen “braaf”, maar ook gewoon slim.
De architectuurkeuze die straks alles bepaalt
Na het bekijken van verschillende implementaties en ontwerpen zie ik één patroon dat robuust én toekomstvast is:
Gebruik de wallet niet als directe “inlogmethode” voor elke applicatie, maar routeer alle wallet-verificaties via een centrale Identity Provider (IdP).
Waarom?
- je houdt achterliggende applicaties zo veel mogelijk onaangeroerd
- je voorkomt wildgroei van wallet-integraties
- je kunt trustlist-updates centraal afhandelen
- je houdt auditlogging op één plek
- je kunt wallet-attributen mappen naar interne claims
- je kunt fallback-kanalen parallel blijven draaien
Zie het als een “wallet-terminator”-laag: de wallet spreekt wallet-taal, en jouw applicaties krijgen vervolgens doodnormale OIDC- of SAML-claims waar ze al jaren op draaien.
Voor organisaties met meerdere portalen, legacy-ketens en documentstromen is dit in de praktijk de enige schaalbare route die niet eindigt in integratie-ellende.
Waar begin je? Mijn praktische volgorde
1. Beleid en risico’s scherpstellen
Maak expliciet wat je risico’s zijn en wie eigenaar is van welk stukje. Denk aan trustlistbeheer, monitoring en fallback-kanalen.
2. IdP-uitbreiding voorbereiden
Voeg wallet-verificatie toe via standaarden zoals OIDC4VP/VCI, maar hou het modulair. Dit is niet “even een extra login”.
3. Mapping naar interne datamodellen
Definieer een klein, helder setje canonical attributes. Hoe minder varianten je accepteert, hoe minder chaos je later krijgt.
4. Kleine PoC’s draaien (maar wel doelgericht)
Een paar voorbeelden die direct waarde opleveren:
- wallet-mandaatbewijs → rechten in een portaal
- identiteit → inlog via IdP → klantportaal
- QES → documentflow
5. Opschalen naar bredere ketens
Denk aan adviesketens, verzuimketens, schadeketens en hypotheekprocessen. Dáár zit straks de echte impact — en ook de grootste complexiteit.
Tot slot: is de wallet een revolutie?
Ja. Maar niet omdat het technisch zo “nieuw” is.
De echte omslag is dat identiteit en attesteringen bij de burger zelf komen te liggen. Organisaties kunnen daardoor processen eenvoudiger, veiliger en schaalbaarder maken…
Maar alleen als je nu begint met de fundamentele keuzes.
Zie de wallet dus niet als “nog een extra inlogmethode”, maar als een nieuwe laag in de digitale samenleving.
En zoals altijd: hoe eerder je experimenteert, hoe kleiner de verrassingen straks.