TRUSTTECH / BLOG

Wat zijn de regels voor gebruikerstoestemming onder eIDAS 2.0?

Hand hovering over a European digital identity card beside a small padlock on a white desk, symbolizing data consent and control.

Onder eIDAS 2.0, de informele benaming voor Verordening (EU) 2024/1183 die Verordening (EU) 910/2014 wijzigt, is gebruikerstoestemming gebaseerd op het principe dat individuen volledige controle moeten hebben over welke persoonsgegevens ze delen, met wie en wanneer. De verordening vereist dat gegevensdeling via de EUDI-wallet altijd bewust en geïnformeerd plaatsvindt. Gebruikers kiezen actief wat ze openbaar maken. Dit artikel beantwoordt de belangrijkste vragen die organisaties moeten begrijpen over de toestemmingsregels van eIDAS 2.0, inclusief de relatie met de AVG, de verplichtingen voor relying parties en de praktische voorbereiding.

Hoe definieert eIDAS 2.0 gebruikerstoestemming voor gegevensdeling?

Onder eIDAS 2.0 betekent gebruikerstoestemming voor gegevensdeling dat individuen expliciet en actief moeten instemmen met het delen van specifieke identiteitsattributen voordat gegevens worden verzonden. Toestemming moet geïnformeerd, granulair en vrijelijk gegeven zijn. Gebruikers worden nooit verplicht meer informatie te delen dan strikt noodzakelijk is voor een bepaalde interactie, en delen kan niet plaatsvinden zonder een duidelijke, bewuste actie van de gebruiker.

Deze uitgangspunten zijn ingebed in de architectuur van de EUDI-wallet zelf. De wallet is zo ontworpen dat elke gegevensverstrekking een bewuste beslissing van de gebruiker vereist. Wanneer een relying party identiteitsattributen opvraagt, toont de wallet de gebruiker een overzicht van precies wat wordt gevraagd en voor welk doel. De gebruiker kan de aanvraag vervolgens goedkeuren, aanpassen of weigeren.

Deze aanpak wordt selective disclosure genoemd. In plaats van een volledig identiteitsdocument te delen, kan een gebruiker alleen de specifieke attributen delen die nodig zijn. Het maken van een afspraak bij een zorgverlener vereist mogelijk alleen een naam en geboortedatum, geen volledig nationaal identiteitsrecord. De verordening stelt uitdrukkelijk dat niet meer dan noodzakelijk mag worden gedeeld. Dat principe van gegevensminimalisatie geldt zowel voor de wallet-architectuur als voor de AVG-verplichtingen van de ontvangende organisatie.

Belangrijk onderscheid: de goedkeuring die een gebruiker in de wallet geeft voor het delen van gegevens, is geen toestemming als rechtsgrond onder artikel 6, lid 1, onder a, van de AVG. De ontvangende organisatie heeft een zelfstandige AVG-grondslag nodig voor de verdere verwerking van die gegevens.

Welke specifieke rechten hebben gebruikers onder de toestemmingsregels van eIDAS 2.0?

eIDAS 2.0 geeft gebruikers een duidelijke set rechten met betrekking tot hun identiteitsgegevens en hoe deze worden gedeeld. Onder de verordening hebben gebruikers het recht om:

  • Te kiezen welke attributen ze delen en welke ze achterhouden
  • Per interactie te beslissen, in plaats van een algemene goedkeuring te geven
  • Een transactieoverzicht te raadplegen van welke gegevens zijn gedeeld, met wie en wanneer. Dit overzicht is een functionaliteit voor de gebruiker, geen loggingvoorziening voor de relying party of wallet provider.
  • Een gegevensdeling te stoppen door een volgend verzoek niet goed te keuren
  • Digitale diensten te gebruiken zonder gedwongen te worden onnodige persoonsgegevens te delen
  • Toegang te krijgen tot de EUDI-wallet en digitale identiteitsdiensten zonder via privéplatforms te gaan die aanvullende gegevens verzamelen

Walletgebruik is vrijwillig. Artikel 5a van de verordening beschermt gebruikers uitdrukkelijk tegen benadeling wanneer zij ervoor kiezen geen wallet te gebruiken. Deze rechten gelden voor zowel interacties in de publieke als de private sector. Of een gebruiker nu een overheidsdienst raadpleegt, een bankrekening opent of zijn leeftijd verifieert voor een onlineplatform, dezelfde principes zijn van toepassing. De verordening is bedoeld om situaties te voorkomen waarbij gebruikers zich gedwongen voelen meer te delen dan nodig om toegang te krijgen tot een dienst.

Zijn organisaties verplicht elke keer expliciete goedkeuring te verkrijgen?

In de meeste gevallen wel. eIDAS 2.0 vereist dat goedkeuring wordt verkregen op het moment van elke gegevensdeling, niet opgeslagen als een algemene instelling die alle toekomstige verzoeken dekt. Elke keer dat een relying party identiteitsattributen opvraagt via de EUDI-wallet, moet de gebruiker actief bevestigen wat hij bereid is te delen in die specifieke context.

Er is een belangrijk onderscheid tussen authenticatie en gegevensdeling. Een gebruiker kan een vertrouwde relatie opzetten met een dienstverlener, maar dat geeft de aanbieder geen doorlopende toegang tot de identiteitsgegevens van de gebruiker. Elk nieuw verzoek vereist nog steeds een actieve goedkeuring van de gebruiker. Dit verschilt van hoe veel huidige digitale identiteitssystemen werken, waarbij een eenmalige handeling vaak leidt tot blijvende gegevenstoegang.

Relying parties moeten zich bovendien registreren bij de bevoegde nationale autoriteit van de lidstaat van vestiging onder CIR (EU) 2025/848 van 6 mei 2025 voordat zij walletdata kunnen opvragen. Bij die registratie leggen zij per intended use vast welke attributen en attestaties worden opgevraagd. Een verzoek buiten deze geregistreerde scope kan door de wallet worden gesignaleerd en kan gevolgen hebben voor de registratie. Een leverancier die walletdata technisch namens een klant verwerkt, wordt daardoor niet automatisch zelf relying party. De registratieplicht ligt bij de organisatie die de dienst aan de eindgebruiker levert.

Organisaties die actief zijn in de financiële dienstverlening of andere gereguleerde sectoren moeten hier goed op letten. Bestaande onboardingprocessen die vertrouwen op brede of doorlopende goedkeuring moeten mogelijk worden herontworpen om te voldoen aan het per-interactiemodel dat eIDAS 2.0 introduceert.

Wat gebeurt er als een gebruiker een verzoek weigert?

Als een gebruiker een gegevensdeling weigert onder eIDAS 2.0, mogen organisaties de toegang tot een dienst niet uitsluitend op die basis weigeren, mits de gevraagde gegevens niet strikt noodzakelijk zijn voor de betreffende dienst. Gebruikers mogen niet worden gestraft voor het uitoefenen van hun recht op gegevensminimalisatie. Als een organisatie meer gegevens opvraagt dan werkelijk vereist is, heeft de gebruiker het recht te weigeren zonder de toegang te verliezen.

Omdat de gebruiker elk verzoek afzonderlijk goedkeurt, stopt gegevensdeling zodra de gebruiker een volgend verzoek niet bevestigt. Organisaties moeten hun processen zo inrichten dat zij hier zonder vertraging op kunnen reageren. Dit heeft praktische gevolgen voor systemen die identiteitsgegevens opslaan of hergebruiken: gegevens die zijn gedeeld op basis van een eerdere goedkeuring mogen niet buiten de oorspronkelijke doelbinding worden gebruikt.

Voor organisaties in de gezondheidszorg of overheidsdiensten, waar identiteitsverificatie vaak een wettelijke vereiste is, geldt meer nuance. In deze gevallen kunnen bepaalde gegevens wettelijk verplicht zijn, wat een andere rechtsgrondslag voor verwerking creëert dan toestemming. Voor gezondheidsgegevens moet daarnaast een toepasselijke grond uit artikel 9, lid 2, van de AVG bestaan. Maar ook in deze contexten blijven de principes van gegevensminimalisatie van toepassing.

Hoe verhouden de toestemmingsregels van eIDAS 2.0 zich tot de AVG?

De toestemmingsregels van eIDAS 2.0 en de AVG werken naast elkaar en zijn ontworpen om complementair te zijn. De AVG stelt het overkoepelende kader voor de verwerking van persoonsgegevens in de EU, inclusief de voorwaarden waaronder toestemming geldig is. eIDAS 2.0 verankert gegevensminimalisatie en gebruikerscontrole rechtstreeks in de technische architectuur van de EUDI-wallet.

In de praktijk betekent dit dat wanneer een gebruiker identiteitsattributen deelt via de EUDI-wallet, de organisatie die deze gegevens ontvangt nog steeds moet voldoen aan de AVG-verplichtingen. Dit omvat het hebben van een rechtmatige grondslag voor verwerking, het respecteren van bewaartermijnen en het honoreren van rechten van betrokkenen zoals toegang en verwijdering. De goedkeuring die een gebruiker in de wallet geeft, is daarvoor niet voldoende. De relying party heeft een zelfstandige AVG-grondslag nodig, bijvoorbeeld een wettelijke verplichting bij KYC-processen.

Een gebied waar de twee kaders nauw met elkaar samenhangen, is het concept van doelbinding. Onder de AVG mogen gegevens die voor één doel zijn verzameld niet vrijelijk voor een ander doel worden hergebruikt. eIDAS 2.0 versterkt dit door te vereisen dat goedkeuring specifiek is voor elke interactie en elk vermeld doel. Een organisatie kan identiteitsgegevens die tijdens de onboarding zijn gedeeld niet voor een ander proces gebruiken zonder een nieuwe goedkeuring of een andere rechtmatige grondslag.

Organisaties moeten eIDAS 2.0-naleving en AVG-naleving behandelen als verbonden werkstromen. Een gestructureerde implementatieaanpak die gegevensstromen, goedkeuringsmechanismen en rechtsgrondslagen in beide kaders in kaart brengt, vermindert dubbel werk en sluit nalevingsleemten efficiënter.

Wat moeten organisaties nu doen om zich voor te bereiden op deze vereisten?

Organisaties moeten beginnen met het auditeren van hun huidige identiteits- en gegevensdeling processen om te begrijpen waar ze wel en niet overeenkomen met de principes van eIDAS 2.0. De belangrijkste vragen die gesteld moeten worden zijn: welke gegevens vragen we momenteel op, hebben we al die gegevens echt nodig, en hoe verkrijgen en registreren we goedkeuring vandaag?

Vervolgens moet een praktisch voorbereidingsplan de volgende stappen omvatten:

  1. Breng je gegevensverzoeken in kaart: Identificeer elk punt in je klant- of gebruikersreis waar identiteitsgegevens worden verzameld of gedeeld, en beoordeel of elk gegevenspunt strikt noodzakelijk is.
  2. Beoordeel goedkeuringsmechanismen: Controleer of je huidige processen granulair, per interactie en duidelijk gedocumenteerd zijn in overeenstemming met zowel de eIDAS 2.0- als AVG-vereisten. Houd daarbij rekening met het onderscheid tussen goedkeuring in de wallet en toestemming als AVG-rechtsgrond.
  3. Bereid je voor op EUDI-wallet-integratie: Begrijp hoe registratie als relying party werkt onder CIR (EU) 2025/848 en welke technische vereisten gelden voor organisaties die op wallet gebaseerde attestaties willen accepteren. Publieke instanties zijn verplicht genotificeerde wallets te accepteren vanaf 24 december 2026. Voor gereguleerde private partijen in sectoren zoals financiële dienstverlening, zorg, telecom en onderwijs geldt de acceptatieplicht onder artikel 5f vanaf 24 december 2027, binnen de context waarin sterke gebruikersauthenticatie wettelijk of contractueel vereist is. Voor zeer grote onlineplatforms (VLOP’s) geldt een afzonderlijke bepaling van artikel 5f: de verplichting geldt waar het platform gebruikersauthenticatie vereist, op vrijwillig verzoek van de gebruiker en voor de minimaal noodzakelijke gegevens. Micro- en kleine ondernemingen met minder dan 50 medewerkers en een jaaromzet of balanstotaal van maximaal €10 miljoen zijn van de acceptatieplicht uitgezonderd.
  4. Update intern beleid: Zorg ervoor dat jouw gegevensbeschermingsbeleid, privacyverklaringen en interne procedures het nieuwe model en de rechten die gebruikers hebben onder eIDAS 2.0 weerspiegelen.
  5. Train relevante teams: Compliance-, juridische, IT- en productteams moeten allemaal de implicaties van de eIDAS 2.0-vereisten voor hun specifieke verantwoordelijkheden begrijpen.

Organisaties in sectoren zoals overheidsdiensten of onderwijs kunnen ook de uitkomsten van de grootschalige EU-pilotprogramma’s raadplegen. De eerste vier Large Scale Pilots liepen van april 2023 tot 2025 en zijn afgerond. POTENTIAL richtte zich op overheidsdiensten, het openen van een bankrekening, SIM-registratie, mobiel rijbewijs, gekwalificeerde handtekening op afstand en e-recepten. DC4EU had betrekking op onderwijs en sociale zekerheid. EWC piloteerde Digital Travel Credentials, betalingen en organisational digital identity. NOBID richtte zich op betalingen. Deze pilots hebben praktijkgerichte inzichten opgeleverd die de implementatieplanning kunnen informeren. Meer achtergrondinformatie en begeleiding is beschikbaar via de resources van TrustTech.

Hoe ondersteunt de ID Connector van TrustTech eIDAS 2.0-naleving

De ID Connector van TrustTech is een integratie waarmee relying parties elke gecertificeerde Europese wallet accepteren, ongeacht de lidstaat van uitgifte, voor identificatie, login en gekwalificeerd tekenen. Acceptatie van de EUDI-wallet staat voorop; via dezelfde koppeling lopen ook andere identiteitsmiddelen, zoals nationale eID’s, bank-ID’s en identiteitsdocumenten, binnen en buiten de EU.

Voor het onderwerp van dit artikel ondersteunt de ID Connector concreet:

  • Verificatie van attestaties tegen nationale trusted lists volgens ETSI TS 119 612 en de EU List of Trusted Lists, zodat de herkomst van gedeelde identiteitsattributen aantoonbaar is
  • Controle van de intrekkingsstatus van attestaties via statusinformatie van de uitgever, als onderdeel van een volledige verificatieprocedure
  • Validatie van de wallet unit attestation, waarmee wordt vastgesteld dat de presenterende wallet op een gecertificeerde wallet solution draait
  • Bewaking van de geregistreerde attributenscope, zodat verzoeken buiten de onder CIR (EU) 2025/848 geregistreerde scope worden gesignaleerd
  • Hergebruik van geverifieerde identiteitsdata binnen de grenzen van de doelbinding en de toepasselijke AVG-grondslag
  • Gekwalificeerd tekenen via een aangesloten QTSP, voor processen waarbij een gekwalificeerde elektronische handtekening vereist is. De QES wordt uitgegeven door de QTSP, niet door TrustTech.

De ID Connector is relevant voor relying parties in financiële dienstverlening, gezondheidszorg, farmaceutica en overheid, waar goedkeurings- en gegevensdeling vereisten het meest complex zijn en waar de deadlines van 24 december 2026 en 24 december 2027 directe operationele gevolgen hebben.

Neem contact op met TrustTech om te bespreken wat de ID Connector concreet doet voor jouw organisatie.