TRUSTTECH / BLOG

Wat is het verschil tussen authenticatie en autorisatie in eIDAS 2.0?

European digital identity card on glass surface beside a brass padlock and open door latch, symbolizing secure digital access.

Authenticatie en autorisatie zijn twee afzonderlijke stappen in digitale identiteit: authenticatie bevestigt wie je bent, terwijl autorisatie bepaalt wat je mag doen. Onder Verordening (EU) 2024/1183, informeel aangeduid als eIDAS 2.0, wordt dit onderscheid bijzonder belangrijk. De verordening wijzigt Verordening (EU) 910/2014 en stelt bindende normen voor hoe identiteit wordt geverifieerd binnen de EU, terwijl toegangsbeslissingen de verantwoordelijkheid blijven van individuele diensten en organisaties. De onderstaande secties lichten elk concept toe, leggen uit hoe ze samenhangen binnen het EUDI-wallet-ecosysteem en tonen waarom een correcte toepassing ervan van belang is voor naleving.

Hoe verschilt authenticatie van autorisatie in digitale identiteit?

Authenticatie is het proces waarbij wordt geverifieerd dat een persoon of entiteit is wie hij beweert te zijn. Autorisatie is het proces waarbij wordt bepaald waartoe die geverifieerde persoon of entiteit toegang heeft of wat hij mag doen. De twee zijn opeenvolgend: authenticatie komt altijd eerst, en autorisatie is afhankelijk van de uitkomst daarvan. De twee verwarren of als uitwisselbaar beschouwen leidt tot hiaten in zowel beveiliging als naleving.

Denk er zo over na: authenticatie is het moment waarop je jouw paspoort toont aan de grens. De ambtenaar controleert of het document echt is en of het gezicht overeenkomt. Dat is identiteitsverificatie. Autorisatie is de beslissing of je het land mag binnenkomen op basis van jouw visum, nationaliteit of andere criteria. Het paspoort verleent je op zichzelf geen toegang.

In digitale identiteitssystemen omvat authenticatie doorgaans een eID-schema, een biometrische controle of een door de overheid uitgegeven digitale attestatie. Autorisatie past vervolgens regels, rollen of beleidsregels toe om te bepalen tot welke bronnen of diensten de geauthenticeerde gebruiker toegang heeft. Beide stappen zijn noodzakelijk, maar dienen fundamenteel verschillende doelen en worden beheerst door verschillende mechanismen.

Hoe gaat eIDAS 2.0 specifiek om met authenticatie?

eIDAS 2.0 richt zich voornamelijk op authenticatie. De verordening stelt een kader vast voor de manier waarop elektronische identificatieschema’s worden erkend door EU-lidstaten, en definieert betrouwbaarheidsniveaus die bepalen hoe betrouwbaar de identiteit van een persoon is geverifieerd. Deze betrouwbaarheidsniveaus, laag, substantieel en hoog, beschrijven de mate van vertrouwen die kan worden gesteld in een authenticatieclaim.

Onder eIDAS 2.0 is elke EU-lidstaat verplicht uiterlijk op 24 december 2026 een gecertificeerde EUDI-wallet beschikbaar te stellen aan burgers, inwoners en bedrijven. Deze wallet maakt EUDI-wallet-authenticatie mogelijk voor zowel publieke als private digitale diensten in de hele EU. Wanneer een gebruiker zich authenticeert met zijn wallet, ontvangt de relying party cryptografisch geverifieerde identiteitsattributen in de vorm van attestaties, geen token of wachtwoord.

Wat eIDAS 2.0-authenticatie onderscheidend maakt, is de combinatie van portabiliteit en betrouwbaarheid. Een persoon die op het hoge betrouwbaarheidsniveau is geverifieerd in één lidstaat, kan diezelfde geverifieerde identiteit gebruiken om zich in een andere lidstaat te authenticeren. Deze grensoverschrijdende erkenning was een kernleemte in de oorspronkelijke eIDAS-verordening, en het herziene kader pakt dit direct aan door erkenning verplicht te maken in plaats van vrijwillig.

eIDAS 2.0 schrijft geen autorisatiebeslissingen voor. Zodra een dienst een geverifieerde authenticatie heeft ontvangen van een wallet of eID-schema, valt wat die dienst met het resultaat doet, welke functies worden ontgrendeld, welke gegevens worden gedeeld, welke acties worden toegestaan, volledig buiten het toepassingsgebied van de verordening. Dat is een organisatorische en technische verantwoordelijkheid.

Belangrijk om te vermelden: 24 december 2026 is de deadline voor notificatie en uitgifte. Publieke instanties moeten vanaf die datum genotificeerde wallets accepteren voor onlinediensten waarvoor elektronische identificatie vereist is. Voor private relying parties in de relevante gereguleerde sectoren is 24 december 2027 de datum waarop de acceptatieplicht onder artikel 5f van de verordening van toepassing wordt.

Welke rol speelt autorisatie in het EUDI-wallet-ecosysteem?

Autorisatie in het EUDI-wallet-ecosysteem is de laag die bovenop de geverifieerde identiteit zit. Nadat een gebruiker zich heeft geauthenticeerd met zijn wallet, gebruikt de relying party de geverifieerde attributen om toegangsbeslissingen te nemen. De wallet zelf verleent geen rechten; hij levert betrouwbare, geverifieerde attestaties die diensten kunnen gebruiken om hun eigen autorisatielogica toe te passen.

De EUDI-wallet kan een breed scala aan geverifieerde attributen bevatten naast een basisidentiteit, waaronder beroepskwalificaties, leeftijdsverificatie, gezondheidsgegevens en arbeidsgegevens. Elk van deze attributen kan bijdragen aan verschillende autorisatiebeslissingen, afhankelijk van de dienst:

  • Een bank kan een geverifieerd leeftijdsattribuut gebruiken om toegang tot bepaalde financiële producten te autoriseren
  • Een zorgverlener kan een geverifieerde beroepskwalificatie gebruiken om toegang tot klinische systemen te autoriseren
  • Een overheidsportaal kan een geverifieerd staatsburgerschapsattribuut gebruiken om toegang tot specifieke publieke diensten te autoriseren
  • Een werkgever kan geverifieerde kwalificatiegegevens gebruiken om toegang tot gereguleerde werkstromen te autoriseren

Deze scheiding is bewust van ontwerp. De wallet beheert de identiteitskant; de dienst beheert de toegangskant. Gebruikers behouden controle over welke attributen zij delen via selective disclosure, en zij delen alleen wat noodzakelijk is voor de specifieke interactie. Dit principe is een van de kernprivacybeschermingen die zijn ingebouwd in het EUDI-wallet-kader.

Een relying party die walletdata wil opvragen, moet zich vooraf registreren bij de bevoegde nationale autoriteit van de lidstaat van vestiging op grond van CIR (EU) 2025/848 van 6 mei 2025. Bij registratie legt de relying party per intended use vast welke attributen en attestaties worden opgevraagd. Een verzoek buiten deze geregistreerde scope kan door de wallet worden geweigerd en kan gevolgen hebben voor de registratie. De wallet is daarmee ook een technisch handhavingsmechanisme voor de grenzen van autorisatie.

Waarom brengt het verwarren van authenticatie en autorisatie nalevingsrisico’s met zich mee?

Het verwarren van authenticatie en autorisatie brengt nalevingsrisico’s met zich mee, omdat het organisaties ertoe brengt ofwel te veel te vertrouwen op identiteitsverificatie als vervanging voor goede toegangscontrole, ofwel toegangsbeslissingen toe te passen voordat de identiteit correct is bevestigd. Beide scenario’s introduceren kwetsbaarheden die toezichthouders en auditors zullen signaleren.

Onder eIDAS 2.0 moeten organisaties die elektronische identificatie accepteren het betrouwbaarheidsniveau van het gebruikte schema respecteren. Als een organisatie een authenticatie met laag betrouwbaarheidsniveau als voldoende beschouwt voor een hoogrisicotransactie, voldoet zij niet aan de norm die de verordening vereist. Omgekeerd, als een organisatie autorisatieregels toepast voordat de authenticatie is voltooid, kan zij gevoelige bronnen blootstellen aan niet-geverifieerde gebruikers.

Er zijn ook indirecte risico’s in verband met andere regelgeving. De AVG vereist dat persoonsgegevens alleen worden geraadpleegd door degenen met een rechtmatige grondslag. Goedkeuring van een dataverzoek in de wallet staat daarbij niet gelijk aan toestemming als rechtsgrond onder artikel 6, lid 1, onder a, AVG: de relying party heeft een eigen AVG-grondslag nodig voor de verwerking. AML- en KYC-kaders vereisen dat de identiteit van de klant correct is vastgesteld voordat bepaalde diensten worden verleend. PSD2 vereist sterke klantauthenticatie voor betalingsinitiatief. Als de authenticatiestap zwak, onvolledig of vermengd is met toegangscontrole, worden ook de daarop gebaseerde nalevingsvereisten in gevaar gebracht.

Een praktisch voorbeeld: een organisatie die toegang verleent tot een gereguleerde dienst uitsluitend op basis van het feit dat een gebruiker een attestatie presenteert, zonder het betrouwbaarheidsniveau van die attestatie te verifiëren of te bevestigen dat het aan de vereiste drempel voldoet, heeft de authenticatie effectief overgeslagen en is direct naar autorisatie gegaan. Die snelkoppeling creëert een nalevingshiaat dat moeilijk te verdedigen is tijdens een audit. Organisaties die actief zijn in de financiële dienstverlening of andere gereguleerde sectoren lopen hier bijzonder hoge risico’s.

Hoe moeten organisaties identiteitsstromen ontwerpen die de twee scheiden?

Organisaties moeten identiteitsstromen zo ontwerpen dat authenticatie en autorisatie worden behandeld als afzonderlijke, opeenvolgende fasen met duidelijke overdrachten daartussen. Dit betekent dat voor elke dienst of transactie moet worden vastgesteld welk niveau van identiteitszekerheid vereist is voordat de stroom wordt gebouwd, en vervolgens authenticatiemechanismen moeten worden geselecteerd die aan die vereiste voldoen voordat enige autorisatielogica wordt toegepast.

Een goed gestructureerde identiteitsstroom volgt doorgaans deze volgorde:

  1. Definieer de betrouwbaarheidsvereiste — bepaal welk niveau van identiteitszekerheid de dienst vereist op basis van het risicoprofiel en de regelgevende verplichtingen
  2. Selecteer de authenticatiemethode — kies een eID-schema, wallet-gebaseerde authenticatie of een ander mechanisme dat voldoet aan of dat betrouwbaarheidsniveau overtreft
  3. Verifieer de identiteit — voltooi de authenticatiestap en ontvang cryptografisch geverifieerde attestaties; verificatie omvat drie afzonderlijke controles: de handtekening van de uitgever tegen de relevante nationale trusted list, de intrekkingsstatus via statusinformatie van de uitgever, en de wallet unit attestation waarmee wordt vastgesteld dat de presenterende wallet op een gecertificeerde wallet solution draait
  4. Pas autorisatieregels toe — gebruik de geverifieerde attributen om toegangsbeleid, rollen en rechten te evalueren
  5. Registreer en controleer — houd een volledig overzicht bij van zowel de authenticatiegebeurtenis als de autorisatiebeslissing voor nalevingsdoeleinden

Organisaties moeten ook vermijden systemen te bouwen waarbij authenticatie en autorisatie door dezelfde component worden afgehandeld of waarbij de grens tussen beide onduidelijk is. Scheiding van verantwoordelijkheden is niet alleen goede architectuur; het maakt naleving gemakkelijker aantoonbaar en audittrails gemakkelijker te onderhouden. Voor organisaties in sectoren zoals gezondheidszorg of overheid, waar zowel identiteitszekerheid als toegangscontrole regelgevend gewicht dragen, is deze scheiding essentieel.

Herbruikbare identiteit is een ander ontwerpprincipe dat de moeite waard is om in te bouwen. Als een gebruiker al is geverifieerd op het vereiste betrouwbaarheidsniveau, kan een goed ontworpen systeem die geverifieerde attestatie accepteren in plaats van de gebruiker het proces opnieuw te laten doorlopen. Daarbij geldt dat privésleutels van attestaties het beveiligde middel niet kunnen verlaten: bij een nieuw toestel worden attestaties opnieuw uitgegeven in plaats van simpelweg gekopieerd. Dit is een van de voordelen die de EUDI-wallet mogelijk maakt, en het vermindert wrijving zonder de beveiliging te compromitteren.

Hoe de ID Connector van TrustTech authenticatie en autorisatie ondersteunt

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.

Concreet ondersteunt de ID Connector de volgende taken:

  • Verificatie van de handtekening van de uitgever tegen de relevante nationale trusted list, conform ETSI TS 119 612 en de EU List of Trusted Lists
  • Controle van de intrekkingsstatus via statusinformatie van de uitgever
  • 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 scope die onder CIR (EU) 2025/848 is vastgelegd worden gesignaleerd
  • Hergebruik van geverifieerde identiteitsattributen voor meerdere diensten, zonder het verificatieproces te herhalen
  • Gekwalificeerd tekenen via een aangesloten gekwalificeerde vertrouwensdienstverlener

De ID Connector is relevant voor organisaties in financiële dienstverlening, gezondheidszorg, farmacie en overheid, waar zowel de authenticatiestap als de autorisatielaag aan regelgevende eisen moet voldoen. Verken onze identiteitsoplossingen of neem contact op om jouw specifieke situatie te bespreken.