Hoe kunnen enterprises EUDI Wallet-acceptatie schalen over meerdere business units?

EUDI-wallet-acceptatie uitrollen over meerdere business units betekent dat je de klantgerichte processen van elke unit verbindt met één conforme integratie die elke gecertificeerde Europese wallet accepteert, trust management afhandelt en geverifieerde identiteitsgegevens hergebruikt over interacties heen. De grootste uitdaging zit niet in de technologie zelf, maar in de coördinatie: governance, registratiescope en procesafstemming tussen teams die vaak onafhankelijk van elkaar werken. Dit artikel behandelt de praktische vragen waar grote organisaties mee te maken krijgen bij het grootschalig uitrollen van EUDI-wallet-acceptatie.

Wat houdt het grootschalig uitrollen van EUDI-wallet-acceptatie in voor grote organisaties?

EUDI-wallet-acceptatie op schaal brengen betekent dat elk klantgericht proces in je organisatie in staat is een gecertificeerde EUDI-wallet te accepteren als geldig identiteitsinstrument — voor identificatie, inloggen en gekwalificeerd ondertekenen — ongeacht welke EU-lidstaat de wallet heeft uitgegeven. Voor grote organisaties gaat dit verder dan één technische integratie: het vereist afstemming tussen meerdere business units, registratie van de juiste attributenscope per beoogd gebruik, en het opzetten van een governancemodel dat alle units binnen hun geregistreerde grenzen houdt.

Onder eIDAS 2.0 moeten gereguleerde private organisaties in sectoren zoals financiële dienstverlening, zorg, telecom en energie EUDI-wallets accepteren vóór 24 december 2027, overal waar sterke gebruikersauthenticatie wettelijk of contractueel verplicht is. Publieke instanties hebben een eerdere deadline: 24 december 2026. Voor ondernemingen die actief zijn in meerdere sectoren of dienstverlening, begint het praktische werk ruim vóór die data.

Drie elementen bepalen wat grootschalig uitrollen in de praktijk inhoudt:

• Registratie per beoogd gebruik: Op grond van CIR (EU) 2025/848 van 6 mei 2025 moeten relying parties zich registreren bij een nationale autoriteit voordat ze wallet-gegevens mogen opvragen. Elke registratie legt exact vast welke attributen en attestations mogen worden opgevraagd voor een bepaalde use case. De wallet toetst elk verzoek aan die geregistreerde scope en blokkeert de presentatie als het verzoek die scope overschrijdt.
• Een gedeelde integratielaag: In plaats van dat elke business unit zijn eigen wallet-verbinding bouwt, vermindert een gedeelde interface duplicatie en houdt trust management consistent binnen de organisatie.
• Hergebruik van gegevens tussen units: Geverifieerde identiteitsgegevens die eenmaal zijn vastgesteld in één interactie, kunnen worden hergebruikt in volgende interacties. Zo wordt de drempel voor terugkerende gebruikers verlaagd zonder dat dezelfde attributen opnieuw worden opgevraagd.

Welke business units profiteren als eerste van EUDI-wallet-integratie?

Business units die al afhankelijk zijn van sterke gebruikersauthenticatie of formele identiteitsverificatie zijn de meest directe kandidaten voor EUDI-wallet-integratie. Dit zijn de units waar de wettelijke verplichting op grond van artikel 5f van eIDAS 2.0 als eerste van toepassing is, en waar het operationele voordeel van wallet-gebaseerde identificatie het duidelijkst is.

In de financiële dienstverlening zijn onboarding- en KYC-processen het logische startpunt. Identiteitsattributen komen cryptografisch ondertekend aan van de uitgevende partij, waardoor de gegevens tamper-evident zijn op het moment dat ze je bedrijfsproces bereiken. Dit vervangt je AML-verplichtingen niet: of je organisatie mag steunen op een identiteitscontrole die elders is uitgevoerd, wordt bepaald door de AMLR en sectorspecifieke regels, niet door eIDAS zelf.

In de zorg en farmacie profiteren patiëntidentificatie en receptworkflows van wallet-gebaseerd inloggen op het hoogste betrouwbaarheidsniveau. De wallet wordt uitgegeven op betrouwbaarheidsniveau hoog, wat de meeste bestaande verificatiemethoden standaard niet halen.

Bij overheidsgerichte dienstverlening krijgen units die communiceren met publieke registers of officiële documenten uitgeven waarschijnlijk te maken met de deadline van 24 december 2026 voor de publieke sector — als ze als publieke instantie opereren — of met de deadline van 24 december 2027 voor de private sector als ze gereguleerde sectoren bedienen.

Units die gekwalificeerd ondertekenen afhandelen, zoals contractbeheer of documentuitwisseling, profiteren ook vroeg. Wanneer de identiteit van een gebruiker al is vastgesteld via wallet-gebaseerde identificatie, kan een gekwalificeerde handtekening in dezelfde sessie worden gezet zonder een aparte identiteitscontrole.

Wat zijn de belangrijkste technische uitdagingen bij uitrol over meerdere business units?

De belangrijkste technische uitdagingen bij het uitrollen van EUDI-wallet-acceptatie over meerdere business units zijn: wallet-verificatie correct uitvoeren, elke unit binnen de geregistreerde attributenscope houden, en wallet-gebaseerde flows integreren in bestaande authenticatie- en onboardingsystemen zonder die van de grond af opnieuw te bouwen.

Wallet-verificatie is geen enkelvoudige controle. Elke presentatie vereist drie afzonderlijke controles:

1. Handtekeningverificatie: De handtekening van de uitgever wordt gecontroleerd aan de hand van de nationale trusted list van de betreffende lidstaat, samengesteld in de EU List of Trusted Lists (LOTL).
2. Intrekkingsstatus: De uitgever publiceert afzonderlijke statusinformatie. Het overslaan van deze controle betekent dat je proces mogelijk ingetrokken attestations accepteert.
3. Wallet unit attestation: Dit bevestigt dat de presenterende wallet draait op een gecertificeerde wallet solution. Zonder deze controle kun je niet bevestigen dat de wallet zelf conform is.

Alleen de eerste controle werkt volledig offline. De tweede en derde vereisen actieve lookups. Organisaties die hun eigen verificatielogica bouwen, onderschatten dit vaak en implementeren alleen de handtekeningcontrole.

Een tweede uitdaging is scopebeheer. Elke business unit kan verschillende beoogde gebruiken hebben en daarmee verschillende geregistreerde attributensets. Een unit die meer attributen opvraagt dan waarvoor ze geregistreerd is, riskeert intrekking van haar registratie. Om de verzoeken van elke unit binnen de gedeclareerde scope te houden, zijn duidelijke interne controls nodig en idealiter een gedeelde integratielaag die scopegrenzen automatisch afdwingt.

Een derde uitdaging is systeemintegratie. Wallet-gebaseerd inloggen moet passen binnen de loginflow die de unit al gebruikt. Identificatiegegevens moeten ook doorstromen naar bestaande CRM-, onboarding- of zaakbeheersystemen. De credential-formaten die in het EUDI-wallet-ecosysteem worden gebruikt — mdoc (ISO/IEC 18013-5 voor nabijheid, ISO/IEC TS 18013-7 voor online) en SD-JWT VC — moeten correct worden verwerkt op het integratiepunt.

Hoe structureren ondernemingen governance voor EUDI-wallet-uitrol over meerdere units?

Ondernemingen moeten governance voor EUDI-wallet-uitrol over meerdere units opbouwen rond een centrale functie voor registratie en scopebeheer, met duidelijk eigenaarschap op het niveau van de business unit voor elk beoogd gebruik. De registratieverplichting op grond van CIR (EU) 2025/848 ligt bij de organisatie die de dienst aan de gebruiker levert, niet bij een leverancier of verwerker die namens haar handelt.

Een praktische governancestructuur omvat vier gebieden:

• Centrale registratieregie: Één team coördineert de registratie bij de nationale autoriteit en beheert het register van welke unit welke attributenscope heeft gedeclareerd voor welk beoogd gebruik. Dit team bewaakt ook de scopenaleving en verwerkt updates wanneer de use case van een unit wijzigt.
• Eigenaarschap per business unit: Elke unit is eigenaar van haar beoogde gebruiksdeclaratie en is verantwoordelijk voor het blijven binnen de geregistreerde scope. Het opvragen van attributen buiten de registratie is een expliciete grond voor intrekking.
• Privacy- en logcontroles: Relying parties dienen te loggen dat ze binnen hun geregistreerde attributenscope zijn gebleven, niet de volledige set gepresenteerde attributen. Het loggen van de volledige attributenset maakt selective disclosure aan de voorkant ongedaan in je eigen administratie.
• Grenzen voor leveranciers en verwerkers: Een leverancier die wallet-gegevens verwerkt namens je organisatie is een verwerker onder artikel 28 AVG, geen relying party. De registratieverplichting en de toegangscertificaten blijven bij je organisatie.

Governance moet ook rekening houden met wallet unit-identifiers. Omdat een gebruiker die van apparaat wisselt terugkeert met een andere wallet unit en vers uitgegeven attestations, mogen klantrecords nooit worden gekoppeld aan een wallet unit-identifier. Koppel records in plaats daarvan aan stabiele identiteitsattributen of pseudoniemen.

Welke rol speelt het trust framework bij wallet-acceptatie over meerdere units?

Het trust framework maakt wallet-acceptatie over meerdere units betrouwbaar. Het bepaalt welke wallets gecertificeerd zijn, welke uitgevers vertrouwd zijn en welke relying parties geregistreerd zijn, zodat elke unit in je organisatie een wallet-presentatie kan verifiëren aan de hand van dezelfde gezaghebbende bronnen, zonder een eigen trustinfrastructuur te hoeven bouwen.

Het framework steunt op twee soorten lijsten. Nationale trusted lists (ETSI TS 119 612) registreren gekwalificeerde trust services per lidstaat en worden samengevoegd in de EU List of Trusted Lists (LOTL). ARF versie 3.0.0 voegt Lists of Trusted Entities (LoTE, ETSI TS 119 602) toe naast de trusted lists, met aanvullende trustankers zoals wallet-aanbieders en PID-uitgevers. Wanneer een business unit een wallet-presentatie verifieert, controleert ze de handtekening van de uitgever aan de hand van deze lijsten.

Voor uitrol over meerdere units betekent het trust framework dat een wallet uitgegeven in Denemarken, Oostenrijk of Nederland verifieerbaar is door elke business unit met dezelfde verificatielogica, omdat alle gecertificeerde wallets teruggaan op dezelfde trusted lists. Je organisatie hoeft geen aparte trustconfiguraties bij te houden per land of per unit.

Een belangrijke grens: de nationale registers van wallet relying parties op grond van CIR (EU) 2025/848 staan los van de trusted lists. Het relying party-register legt vast welke organisaties wallet-gegevens mogen opvragen en welke scope ze hebben gedeclareerd. De trusted lists leggen vast welke aanbieders en uitgevers gekwalificeerd zijn. Het door elkaar halen van deze twee registers leidt tot onjuiste complianceaannames.

Hoe kunnen ondernemingen het succes van EUDI-wallet-adoptie meten over units heen?

Ondernemingen kunnen het succes van EUDI-wallet-adoptie over business units meten door het bijhouden van voltooiingspercentages van wallet-gebaseerde verificatie, scopenaleving en het hergebruik van geverifieerde identiteitsgegevens over interacties heen. Deze metrics weerspiegelen zowel technische prestaties als operationele afstemming op de registratievereisten.

Nuttige indicatoren op unitniveau zijn:

• Voltooiingspercentage verificatie: Het aandeel wallet-geïnitieerde identiteitsverzoeken waarbij alle drie de verificatiecontroles succesvol worden doorlopen — de handtekening van de uitgever, de intrekkingsstatus en de wallet unit attestation.
• Scopenalevingspercentage: Of de attributenverzoeken van elke unit binnen de geregistreerde scope blijven. Elk verzoek dat de wallet afwijst vanwege scopeoverschrijding is een compliancesignaal dat onderzocht moet worden.
• Hergebruik van identiteitsgegevens: Hoe vaak geverifieerde identiteitsgegevens die in één interactie zijn vastgesteld, worden hergebruikt in een volgende interactie, waardoor dezelfde attributen niet opnieuw bij de gebruiker hoeven te worden opgevraagd.
• Doorlooptijd van identiteitsafhankelijke workflows: Voor processen zoals onboarding, contractondertekening of het openen van een account zou wallet-gebaseerde identificatie op betrouwbaarheidsniveau hoog handmatige stappen en heen-en-weerverkeer moeten verminderen.

Op organisatieniveau: houd bij hoeveel business units hun registratie onder CIR (EU) 2025/848 hebben afgerond en hoeveel beoogde gebruiken live zijn versus gepland. Dit geeft een helder beeld van de uitrolvoortgang ten opzichte van de deadline van 24 december 2027 voor gereguleerde private relying parties.

Gebruik wallet-transactielogboeken niet als monitoringtool voor individueel gebruikersgedrag. Het transactieoverzicht in het wallet-dashboard bestaat voor de gebruiker, die kan zien welke partij welke gegevens heeft ontvangen en bij die relying party een verwijderingsverzoek kan indienen. Je interne logging moet scopenaleving bevestigen, niet de attributengegevens repliceren die selective disclosure juist beoogt te minimaliseren.

Hoe ondersteunt de ID Connector EUDI-wallet-acceptatie voor de hele organisatie

De ID Connector is een integratie waarmee relying parties elke gecertificeerde Europese wallet kunnen accepteren — ongeacht welke lidstaat deze heeft uitgegeven — voor identificatie, inloggen en gekwalificeerd ondertekenen. EUDI-wallet-acceptatie staat centraal; dezelfde interface ondersteunt ook andere ID’s, zoals nationale eID’s, bank-ID’s en identiteitsdocumenten, binnen en buiten de EU.

Voor ondernemingen die uitrollen over meerdere business units, handelt de ID Connector de technische vereisten af die het moeilijkst consistent te beheren zijn op schaal:

• Alle drie de verificatiecontroles — inclusief de handtekening van de uitgever aan de hand van de trusted lists, de intrekkingsstatus en de wallet unit attestation — worden per presentatie uitgevoerd.
• Geverifieerde identiteitsgegevens zijn herbruikbaar over interacties heen, zodat terugkerende gebruikers niet bij elke sessie opnieuw dezelfde attributen hoeven te presenteren.
• Wallet-gebaseerd inloggen verloopt binnen de authenticatieflow die je al gebruikt, op betrouwbaarheidsniveau hoog.
• Gekwalificeerd ondertekenen is beschikbaar in dezelfde sessie zodra de identiteit is vastgesteld, via een gekoppelde gekwalificeerde trust service provider.

De ID Connector wordt gebruikt door organisaties in financiële dienstverlening, zorg, overheid en farmacie. Neem contact op met TrustTech om te zien hoe de ID Connector aansluit op je bestaande systemen en je registratieverplichtingen ondersteunt.