Een minimaal levensvatbare architectuur voor eIDAS 2.0-compliance bestaat uit vier kerncomponenten: een geverifieerde identiteitslaag, minimaal één geïntegreerde gekwalificeerde vertrouwensdienst, een registratiemechanisme voor relying parties en een verbindingspunt voor EUDI-wallet-interacties. Je hoeft niet elk element van het volledige raamwerk te implementeren om compliant te worden, maar deze fundamenten moeten op orde zijn voordat je juridisch gezien identiteitsgegevens kunt accepteren of uitgeven onder eIDAS 2.0. De onderstaande secties behandelen elk bouwblok, de afwegingen tussen minimale en volledige compliance, en de praktische stappen om aan de slag te gaan.
Welke componenten vormen een eIDAS 2.0-conforme architectuur?
Een eIDAS 2.0-conforme architectuur is opgebouwd rond vier onderling verbonden lagen: identiteitsverificatie en -uitgifte, integratie van vertrouwensdiensten, wallet-interoperabiliteit en een beleids- en auditlaag. Samen stellen deze lagen jouw organisatie in staat digitale identiteitsattestaties uit te geven, te ontvangen en te verifiëren op een manier die voldoet aan de wettelijke en technische vereisten van Verordening (EU) 2024/1183, die Verordening (EU) 910/2014 wijzigt.
Het Architecture and Reference Framework (ARF), ontwikkeld door de European Digital Identity Cooperation Group (EDICG) en de Europese Commissie, definieert de technische specificaties die het gehele ecosysteem ondersteunen. Deze specificaties hebben betrekking op alles, van hoe attestaties worden opgemaakt en uitgewisseld tot hoe wallet solutions worden gecertificeerd en hoe relying parties worden geregistreerd. De uitvoeringshandelingen zijn juridisch bindend; de ARF bevat de bijbehorende technische uitwerking.
In de praktijk moet een conforme architectuur het volgende kunnen afhandelen:
- Identiteitsverificatie en attestatie-uitgifte: vaststellen wie een persoon of organisatie is en cryptografisch ondertekende attestaties uitgeven
- Integratie van vertrouwensdiensten: verbinding maken met gekwalificeerde vertrouwensdiensten zoals gekwalificeerde elektronische handtekeningen (QES) of gekwalificeerde elektronische attesteringen van attributen (QEAA’s)
- Registratie van relying parties: jouw organisatie formeel registreren bij de nationale autoriteit van de lidstaat van vestiging als partij die identiteitsgegevens opvraagt en accepteert vanuit wallets, conform CIR (EU) 2025/848
- EUDI-wallet-compatibiliteit: implementeren van de protocollen en interfaces die nodig zijn voor interactie met gecertificeerde wallet solutions
- Audit- en bewijsspoor: tamper-evident registraties bijhouden van identiteitstransacties ter ondersteuning van compliancerapportage
Veel organisaties werken samen met gespecialiseerde aanbieders die al over gecertificeerde infrastructuur beschikken, wat de tijd tot productie en het compliancerisico aanzienlijk vermindert.
Wat is het verschil tussen een minimaal levensvatbare en een volledige eIDAS 2.0-architectuur?
Een minimaal levensvatbare eIDAS 2.0-architectuur omvat de componenten die nodig zijn om op juridisch geldige wijze op wallet gebaseerde identiteitsattestaties te accepteren en basisattestaties uit te geven. Een volledige architectuur breidt dit uit om alle ondersteunde gebruiksscenario’s te dekken, waaronder grensoverschrijdende identiteitsmatching, geavanceerd delen van attributen, gekwalificeerde bewaardiensten en diepgaande integratie met sectorspecifieke compliancevereisten.
Dit onderscheid is belangrijk omdat organisaties vaak de druk voelen om alles tegelijk te implementeren. Een gefaseerde aanpak is zowel praktisch als toegestaan. Een minimaal levensvatbare opzet stelt je in staat te voldoen aan jouw directe regelgevingsverplichtingen, jouw processen te testen en vertrouwen op te bouwen in het ecosysteem voordat je uitbreidt.
Een minimaal levensvatbare architectuur omvat doorgaans:
- Registratie als relying party bij de relevante nationale autoriteit conform CIR (EU) 2025/848
- Integratie met minimaal één gekwalificeerde vertrouwensdienstverlener (QTSP), voor zover jouw gebruiksscenario dat vereist
- Ondersteuning voor de kernwallet-protocollen zoals gedefinieerd in de ARF, waaronder OID4VP voor presentatie en OID4VCI voor uitgifte
- Een basisstroom voor attestatieverificatie met een tamper-evident auditspoor
Een volledige architectuur voegt lagen toe zoals grensoverschrijdende identiteitsmatching, ondersteuning voor meerdere attestatieformaten (mdoc en SD-JWT VC), integratie met sectorspecifieke attesteringsschema’s en geautomatiseerde beleidshandhaving op schaal. De meeste organisaties groeien hier geleidelijk naartoe.
Welke eIDAS 2.0-vertrouwensdiensten moeten vanaf het begin worden geïntegreerd?
Welke vertrouwensdiensten je vanaf het begin nodig hebt, hangt af van jouw gebruiksscenario. Een relying party die uitsluitend EUDI-wallets accepteert voor identificatie, heeft niet per definitie een QTSP nodig. Een QTSP wordt relevant wanneer jouw gebruik gekwalificeerd tekenen, QEAA-uitgifte of andere gekwalificeerde vertrouwensdiensten omvat.
Verordening (EU) 2024/1183 introduceert nieuwe categorieën gekwalificeerde vertrouwensdiensten naast die in Verordening (EU) 910/2014. Deze omvatten gekwalificeerde elektronische grootboeken, gekwalificeerde elektronische archiveringsservices en gekwalificeerde ondertekening en verzegeling op afstand. Niet al deze diensten zijn vanaf dag één vereist. Bepaal eerst welke vertrouwensdiensten jouw primaire complianceverplichting daadwerkelijk vereist.
Voor organisaties in de financiële dienstverlening zijn gekwalificeerde elektronische handtekeningen en integratie van sterke klantauthenticatie doorgaans het meest urgent. Voor overheidsinstanties ligt de prioriteit vaak bij het uitgeven en accepteren van persoonsidentificatiegegevens (PID) en elektronische attesteringen van attributen (EAA’s). Voor zorginstellingen zijn aan toestemming gekoppelde handtekeningen en veilig delen van attributen doorgaans de primaire focus, waarbij ook de vereisten uit artikel 9, lid 2, AVG voor gezondheidsgegevens meespelen.
Het praktische startpunt is het bepalen welke vertrouwensdiensten jouw specifieke gebruiksscenario vereist, bevestigen dat jouw gekozen QTSP op de relevante nationale trusted list staat conform ETSI TS 119 612, en ervoor zorgen dat jouw integratie voldoet aan de toepasselijke uitvoeringshandelingen.
Hoe past de EUDI-wallet in een minimaal levensvatbare architectuur?
De EUDI-wallet past in een minimaal levensvatbare architectuur als het primaire kanaal waarlangs gebruikers geverifieerde identiteitsattestaties aan jouw organisatie presenteren. In technische termen functioneert jouw systeem als een geregistreerde relying party: een dienst die attestaties kan opvragen en verifiëren vanuit een gecertificeerde wallet solution, zonder meer gegevens op te slaan dan noodzakelijk.
Lidstaten zijn op grond van artikel 5a van Verordening (EU) 2024/1183 verplicht uiterlijk op 24 december 2026 minimaal één gecertificeerde EUDI-wallet operationeel te hebben voor burgers, inwoners en bedrijven. Publieke instanties moeten genotificeerde wallets vanaf diezelfde datum accepteren als identificatiemiddel voor onlinediensten waarvoor elektronische identificatie vereist is. Voor gereguleerde private partijen, zoals banken, zorgaanbieders en telecombedrijven, geldt de acceptatieplicht op grond van artikel 5f van de verordening vanaf 24 december 2027, binnen de context waarin sterke gebruikersauthenticatie wettelijk of contractueel vereist is. Micro- en kleine ondernemingen met minder dan 50 medewerkers en een jaaromzet of balanstotaal van maximaal €10 miljoen zijn van de private acceptatieplicht uitgezonderd.
Voor jouw architectuur betekent het integreren van EUDI-wallet-ondersteuning het implementeren van de protocollen en interfaces zoals gedefinieerd in de ARF. Dit omvat ondersteuning voor OID4VP voor presentatie en OID4VCI voor uitgifte. Jouw systeem moet ook selective disclosure kunnen verwerken: de mogelijkheid van de wallet unit om alleen de specifieke attributen te delen die je nodig hebt, in plaats van een volledig identiteitsdocument.
Selective disclosure is een van de meest significante gebruikersgerichte voordelen van het wallet-model. Een gebruiker die zijn leeftijd bewijst, hoeft zijn volledige geboortedatum, adres of documentnummer niet te delen. Jouw architectuur moet zo worden ontworpen dat alleen de minimaal noodzakelijke attributen worden opgevraagd. Daarbij geldt dat een relying party onder CIR (EU) 2025/848 per intended use registreert welke attributen worden opgevraagd. Een verzoek buiten deze geregistreerde scope kan door de wallet worden geweigerd. Bekijk de beschikbare oplossingen om te zien hoe dit in de praktijk kan worden geïmplementeerd.
Wat zijn de grootste compliance-lacunes waarmee organisaties te maken krijgen bij het bouwen voor eIDAS 2.0?
De grootste compliance-lacunes bij het bouwen voor eIDAS 2.0 zijn vertragingen bij de registratie van relying parties, het onderschatten van de certificeringsvereisten voor wallet-interacties en het niet vanaf het begin opzetten van een tamper-evident auditspoor. Deze lacunes zijn niet altijd zichtbaar totdat een organisatie live wil gaan, en dat is waarom vroege architectuurkeuzes belangrijk zijn.
Registratie als relying party is een formeel proces dat wordt geregeld door CIR (EU) 2025/848. Veel organisaties gaan ervan uit dat ze dit laat in het project kunnen afhandelen, maar vertragingen bij de registratie kunnen jouw volledige go-live-planning blokkeren. Behandel dit als een parallel werktraject, geen laatste stap. Houd er ook rekening mee dat je per intended use registreert welke attributen en attestaties worden opgevraagd: een verzoek buiten de geregistreerde scope kan gevolgen hebben voor jouw registratie.
Een tweede veelvoorkomende lacune is het onderschatten van wat het betekent om wallet-ready te zijn. Ondersteuning voor de EUDI-wallet is geen kwestie van een API-verbinding toevoegen. Het vereist gecertificeerde protocollen, correcte verwerking van attestatieformaten (mdoc en SD-JWT VC) en afstemming met de ARF-specificaties. Organisaties die bouwen op niet-gecertificeerde infrastructuur lopen het risico van non-compliance, ook als hun gebruikerservaring er correct uitziet.
De derde lacune is het auditspoor. Verordening (EU) 2024/1183 vereist dat identiteitstransacties verifieerbaar zijn en dat bewijs van compliance wordt bijgehouden. Veel bestaande systemen zijn niet ontworpen met deze vereiste in gedachten. Het achteraf toevoegen van een auditlaag is aanzienlijk moeilijker dan het vanaf het begin inbouwen.
Andere lacunes die het vermelden waard zijn: onvoldoende aandacht voor vereisten voor grensoverschrijdende identiteitsmatching, onvolledige verwerking van attribuutintrekking, het verwarren van goedkeuring van een dataverzoek in de wallet met toestemming als AVG-grondslag, en een gebrek aan duidelijkheid over welk nationaal toezichthoudend orgaan jouw specifieke vertrouwensdiensten beheert.
Wanneer moeten organisaties beginnen met het bouwen van hun eIDAS 2.0-architectuur?
Organisaties moeten nu beginnen met het bouwen van hun eIDAS 2.0-architectuur. Verordening (EU) 2024/1183 trad in werking op 20 mei 2024. De eerste vijf kernuitvoeringshandelingen werden eind 2024 aangenomen en startten daarmee de relevante 24-maandentermijn voor wallet-uitgifte. In 2025 volgde een tweede golf uitvoeringshandelingen, waaronder CIR (EU) 2025/848 over registratie van wallet-relying parties, die op 6 mei 2025 werd vastgesteld. De deadline voor wallet-uitgifte en publieke acceptatie is 24 december 2026. Voor gereguleerde private partijen in sectoren zoals banken, financiële dienstverlening, zorg, telecom, energie, transport en onderwijs geldt de acceptatieplicht op grond van artikel 5f van de verordening vanaf 24 december 2027, binnen de context waarin sterke gebruikersauthenticatie wettelijk of contractueel vereist is. Organisaties die wachten totdat compliance verplicht wordt, lopen het risico op gehaaste implementaties, gemiste registraties en kostbare aanpassingen achteraf.
De technische specificaties zijn inmiddels stabiel genoeg om op te bouwen. De vier grootschalige pilotprogramma’s liepen van april 2023 tot 2025 en hebben hun kernfase van testen afgerond. De ARF is bijgewerkt om de vastgestelde uitvoeringshandelingen te weerspiegelen en lidstaten vorderen richting wallet-beschikbaarheid. Houd er daarbij rekening mee dat 24 december 2026 een uiterste datum is voor notificatie en uitgifte, geen voorspelde lanceringsdatum voor volledige functionele interoperabiliteit in de gehele EU.
Een praktisch startpunt is het in kaart brengen van jouw huidige identiteitsinfrastructuur aan de hand van de minimaal levensvatbare architectuurvereisten, het identificeren van jouw primaire gebruiksscenario en het bepalen welke vertrouwensdiensten en wallet-interacties je moet ondersteunen. Van daaruit kun je jouw bouwvolgorde prioriteren en over-engineering in de vroege fasen vermijden.
Organisaties in gereguleerde sectoren zoals financiële dienstverlening, overheid, zorg, telecom en energie ervaren extra urgentie omdat sectorspecifieke vereisten bovenop de basale verplichtingen uit Verordening (EU) 2024/1183 komen. Hoe eerder je begint, hoe meer tijd je hebt om jouw compliance-, juridische en technische teams op één lijn te brengen voordat deadlines naderen. Je kunt sectorspecifieke richtlijnen vinden voor overheidsorganisaties en andere gereguleerde sectoren om jouw planning te helpen structureren.
Hoe de ID Connector van TrustTech aansluit op eIDAS 2.0-compliance
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 de onderwerpen die in dit artikel centraal staan, ondersteunt de ID Connector de volgende technische taken:
- Verificatie tegen trusted lists: de ID Connector controleert 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 intrekkingsstatus: de ID Connector raadpleegt de statusinformatie van de uitgever om vast te stellen of een attestatie nog geldig is
- Validatie van de wallet unit attestation: de ID Connector verifieert dat de presenterende wallet instance draait op een gecertificeerde wallet solution
- Bewaking van de geregistreerde attributenscope: de ID Connector bewaakt dat alleen attributen worden opgevraagd die overeenkomen met de geregistreerde intended use onder CIR (EU) 2025/848
- Gekwalificeerd tekenen via een aangesloten QTSP: de ID Connector maakt het mogelijk een QES tot stand te brengen via een gekwalificeerde vertrouwensdienstverlener, zonder dat TrustTech zelf als QTSP optreedt
- Tamper-evident bewijsspoor: elke identiteitstransactie wordt vastgelegd in een auditspoor dat compliancerapportage en toezichtvereisten ondersteunt
De ID Connector is relevant voor organisaties in financiële dienstverlening, gezondheidszorg, farmacie en overheid, waar wallet-gebaseerde identificatie, attributendeling en gekwalificeerd tekenen een directe rol spelen in primaire processen. Neem contact op om te bespreken welke wallet-interacties jouw organisatie moet ondersteunen en hoe de ID Connector daarin aansluit.